Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Epic: Enhance salesforce adaptor #592

Closed
mtuchi opened this issue May 30, 2024 · 8 comments
Closed

Epic: Enhance salesforce adaptor #592

mtuchi opened this issue May 30, 2024 · 8 comments
Assignees
Labels

Comments

@mtuchi
Copy link
Collaborator

mtuchi commented May 30, 2024

This is an epic to track work on Salesforce.

The high-level aim of the epic is to modernise the API.

Some bugs might be included but this is not a bug fixing epic - the idea is for equivalent functionality with a cleaner, better, more consistent API.

The epic should last over several releases.

(at the time of writing, I've added EVERYTHING to the epic, which needs prioritising and some issues removing)

@josephjclark
Copy link
Collaborator

If we update to composeNextState, this closes #509

@josephjclark
Copy link
Collaborator

Linking #644 and #509 - two priority issues

@josephjclark
Copy link
Collaborator

Looking over the docs, I can't really tell how get the result of query or bulk or anything. Does anything write to state.data or is at all references based?

@josephjclark
Copy link
Collaborator

jsforce v2 is finally out with support for bulk2.

We really ought to think about rebasing onto it

@josephjclark
Copy link
Collaborator

josephjclark commented Jun 25, 2024

Here's what I'd suggest as the total API for salesforce v5. This requires some tweaks and breaks, but no fundamental logical changes.

I think I'll suggest we DON'T update jsforce just yet, it's probably a distraction.

Having a clean API like this, with good docs and examples, feels like a really good 5.0 target to me:

bulkQuery(query, options)

bulk(operation, sObjectName, records, options) // options allow use of v2 instead

create(sObjectName, records) // use records instead of attrs. Default to batch.

describe(sObjectName)

describeAll()

destroy(sObjectName, ids, options) // rename attrs (which is wrong) to ids

insert(sObjectName, records)

query(soql, options)

relationship(name, externalId, dataSource) // should be a verb?

request(url, options)

get(url, options)

post(url, data, options)

retrieve(sObjectName, id)

update(sObjectName, records)

upsert(sObjectName, externalId, records)

Notes:

  • I want to use SObjectName instead of sObject because it's clearer
  • everything "returns" to state.data. http methods should write response but the rest should not. I've love to drop the refernences pattern but we can keep it for now to reduce the chaos of the upgrade.
  • I am generally not adding callbacks. In fact I'm removing a few! Crazy!!
  • I don't understand the relationship API, but I think it needs a verb (like createRelationship)
  • There are breaking changes all over the place here

@aleksa-krolls
Copy link
Member

Hey @josephjclark fyi I'm going to schedule this issue for next week's sprint for @mtuchi to tackle if that sounds okay to you. Also, I know you're going to be offline next week, so can you two pls sync up this week on the design/approach & next steps before you're offline?

@josephjclark
Copy link
Collaborator

This issue has been converted into an epic to track the various different bits of work

@josephjclark josephjclark changed the title Enhance salesforce adaptor Epic: Enhance salesforce adaptor Jul 5, 2024
@josephjclark
Copy link
Collaborator

To be released on Monday with #691

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants