Split services

[demianbrecht]

There's currently a mix of services implemented directly in simple_salesforce.Salesforce (i.e. apex and sobjects). This should be changed such that simple_salesforce.Salesforce contains references to service implementations, such as Salesforce.bulk, Salesforce.sobjects, Salesforce.reports, Salesforce.apex, etc.

As a part of this, the existing APIs should be deprecated (use warnings.warn(..., DeprecationWarning)) and removed in a future version.

[nickcatal]

When you say sobject are you saying the record management functionality currently done via attributes?

What do you see as the future way of changing and updating records? sf.Contacts.update() seems pretty straightforward.

Thanks

[demianbrecht]

What do you see as the future way of changing and updating records? sf.Contacts.update() seems pretty straightforward.

It's straightforward when you only consider the force.com API, but starts to get a little unclear when you consider adding support for other services (https://help.salesforce.com/HTViewHelpDoc?id=integrate_what_is_api.htm).

What I'm proposing is simply something like this:

sf.force.Contacts.update()
sf.chatter.do_something()
sf.tooling.do_something()
sf.apex.do_something()
sf.bulk.do_something()

It's much more representative of the backend services that they're implementing and allows for modularity between services. It would also allow for overridden per-service specialized implementations if needed. In a nutshell, it's the separation of concerns I'm after with this change. Salesforce should manage connectivity and any common aspects (error handling, serialization and deserialization, etc), but the actual service implementation can be (and should be) independent of one another.

[nickcatal]

This looks great! And I think writing the relevant depreciation warnings would be rather easy as well, which is nice.

[ddow]

Is there any update on this? I'm about a medium level in Python but I use it every day to access salesforce in any number of ways so if you need someone to be a guinea pig any run your code I'd be more than willing and you get a lot of feedback. I really need this and I can't find a way to do it with Python 3. I use beatbox in Python 2, but it does not seem that it is being developed anymore.

[colemanja91]

I also would be willing to contribute development/testing time.

[demianbrecht]

@colemanja91, @ddow would be more than happy to get and review PRs related to this change. I've been on a bit of a hiatus, but will be more active going forward.

[demianbrecht]

@colemanja91, @ddow: Before I pick this up myself, have either of you spent any time on this at all?

[ddow]

@demianbrecht Sorry, I'd love to beta test his code, but I didn't write any of it so I'm not sure I'm the one to make changes. I'm pretty much noob at this. I do use simple-salesforce every day most days, though, so I'm a good test rat once you guys decide to beta or even alpha this.

[colemanja91]

@demianbrecht getting around to some of this now - will probably work on it over the next couple of holidays, and have an upcoming sprint dedicated to knocking out some work on it.

[colemanja91]

@demianbrecht do you have any preference between the following?

Mimic SFType functionality with a bulk class:

sf.bulk.Lead.do_something()

or explicitly pass the object type as a parameter:

sf.bulk.do_something(object='Lead', ...)

My preference is for the first, as it continues the convention already established, but wanted to see if anyone had an opinion.

[andscoop]

Looks like this was knocked out in #143 . Can always re-open if not everything was covered

[demianbrecht]

I totally dropped the ball on this as my focus has shifted. At any rate, what was implemented in #143 does match what I was after. However, the idea here was to split up /all/ services, not just newly implemented ones. So auth would be done through Salesforce().login.<method>, general sobject queries through Salesforce().sobjects.<whatever>. Because I'm not contributing I'll just leave the clarification without re-opening. I'll leave that to y'all maintaining the project should you find it useful.