Multiple mapping for the same drupal entity

This looks like a great solution to me, but is a pretty significant change.
I'd like to get at least one more review before RTBC

This patch is a bit outdated and doesn't apply, so for reference on this task I redid the changes with the newest 7.x-3.x. I do think it needs some improvements, so I'll post those afterwards.

my mistake, posted the wrong patch.

Ok I have what I think might be a little more complete solution. In my opinion I also think the code should be refactored a bit to make it easier to test one item at a time, (although obviously this has its complications). I also think with this much changing we'll need some hook_update scripts, so I've added them too.

- New function to get mappings keyed by mapping_name, as redoing the current function (salesforce_get_mapped_objects) would leave it making no sense.
- Rename the queue callback as what it's really doing is processing one queue item, '_process_records' is a bit misleading
- Add mapping_name to queue items (also in above patch)
- Re-save current queue items to make sure they now have the mapping_name
- Delete variables no longer used because of the mapping_name switch
- Simplify salesforce_pull_get_query as this doesn't really need to look through all mappings
- Create two new functions salesforce_pull_create_record, and salesforce_pull_update_record that can then be used for testing and drush scripts.

I'll make a sandbox project too, this is just a first draft. I didn't really add any comments in.

This patch conflicts with https://www.drupal.org/node/2199951 in drush make - so I've rolled them both into one patch to alleviate this issue.

Just an update on this - I've thought more about my solution and the previous solution by gaborpeter. I actually think the current code in place is the better solution. In the case that there are multiple mappings for the same salesforce object type, querying the object twice (which would happen when looping over mappings instead of salesforce mapped objects) could result in a few undesirable consequences.

- queue items could actually be duplicate salesforce ids
- previous values could be overridden
- the update date would be invalid for the subsequent queries to the same object type

I'm going to rescind my patch and leave this as needs work, but in my opinion it should probably be "closed works as designed". I have however kept the refactoring in my patch and am moving that to another issue, I forked the repo in hopes to create a pull request:
https://github.com/FreeflowDigital/salesforce/tree/refactor-salesforce-pull

Updating to cross-reference a recent change in #2857080: Given multiple mappings for the same Salesforce Object with different record type settings, only one mapping record type setting is respected on pull which is related here.

Resolving that bug does not fully address the issue in this thread, but could ease the pain slightly.

I am having a similar issue but with salesforce_push. I am syncing Drupal Commerce with Salesforce and I need to be able to create Product objects but also PriceBookEntry objects. My plan was to simply map Commerce Product to both, however, while the Product will sync, the Pricebookentry will fail because salesforce_mapping_object doesn't store the ID of the mapping so the product mapping object is loaded when the pricebookentry mapping needs to run.

I'm not sure the best solution around this. I think the simplest solution would be that the salesforce_mapping_object stores the mapping id so when we lookup existing objects or save new ones, we know which mapping that object is for. As long as we prevent the exact same entity type, bundle, object combination more than once, then it will allow the same drupal entity to different salesforce objects.

Unless there is some alternative I'm missing..

This would be a killer feature for sure. I'm working on a integration with this module, and it would be super to be able to map one Drupal entity type, to two Salesforce objects...and be able to choose programmatically which salesforce object a entity of each type would push-sync to.

Does anyone here have any success stories of trying that, with the patches here, or otherwise...
using v3.3-beta3

@mrconnerton I'm trying to solve the exact same issue. Were you able to come up with a solution?

7.x is no longer supported