sf_prematch_export() does not handle maps using the SF 'Id' field or blank match_by fields

This is committed to 6.x-2.x-dev: http://drupalcode.org/project/salesforce.git/commit/6fb78fe

Thank you!

Reopening, because I think this patch broke prematching if you don't include the SF Id field in the map.

I have a simple Contact fieldmap that I am trying to prematch on email address, and the resulting SOQL query is SELECT Email FROM Contact WHERE Email = 'user@example.com' ORDER BY CreatedDate ASC. The query works but produces the following $result:

stdClass Object
(
    [done] => 1
    [queryLocator] =>
    [records] => Array
        (
            [0] => stdClass Object
                (
                    [Id] =>
                    [Email] => user@example.com
                )
        )
    [size] => 1
)

The record exists, but as Id wasn't SELECTed, it is not returned and the prematch fails.

If I revert the first part of the patch so the query begins with SELECT Id, Email then Id is populated and the prematch is successful.

Why does the code need to build a SELECT field list anyway? $result->records[0]->Id and $result->size are the only return values used.

There is a relevant comment in the code, "If there's a salesforce field to match by, include it in the select clause", but it doesn't explain *why* this is done.

The attached patch simplifies the query building, as it seems there is no need to build a list of fields to select only to discard the results anyway. The query now always begins with just SELECT Id FROM ....

This seems like a great simplification, if indeed this is all that is necessary. I'll have to test this shortly.

Actually those fields might be relevant, since they can be used in prematching: cf. #1035810: sf_prematch doesn't handle multiple records & #1192080: Handing multiple matches (when there are multiple sf_find_match implementations).

I'm not 100% sure, though...it's too late at night here. I'll have to revisit this another time.

Just a note that #1198622: Prematch finds matches, but does not link to them has been marked as a duplicate of this issue. The problem reported there is in direct support of the details highlighted in #5

Will have to add this to sf_prematch in D7 once I get that module ported fully.

I can vouch that prematching in D6 is broken without the patch in #8. Once applied, prematching works as expected and I don't see duplicate new accounts upon login.

Thanks for the update on this. Possibly this explains why I couldn't get prematching to work in the 7.x version either.

I will try to commit this in the next few weeks, but I would like, ideally, for kostajh to confirm before I commit a change in 6.x which could potentially have implications that I'm not aware of.

It would be great if one more person can test this before it is committed.

I can confirm that the patch in #8 fixed my prematching issues. I upgraded from an old dev version to alpha8 (and subsequently alpha9), both broke prematching for me (I was just prematching on one field: uid). Drupal unnecessarily created a new record in Salesforce on export when it could have linked to an existing record. With patch #8, this issue was solved and prematching worked again like it did before. Thanks for the great work everyone!

I tested applying this on 7.x-2.x and it did not fix prematching (nodes that were set to match on "title" (i.e., node title) as primary field still got duplicated). I don't know, however, whether that is due to some other issue in that branch. I will have to test on 6.x-2.x at some point to see if it is the same way.

Tested this in 6.x, finally, and it worked.

Thanks to dpearceMN for the initial report & patch, longwave for the refinement, and everyone else for the tests.

This was just committed as http://drupalcode.org/project/salesforce.git/commit/ac7176d.

I think prematching should now be working in 6.x. Now to find out why the equivalent change in 7.x didn't seem to work.

Hi Evan,

Does this mean that prematching doesn't currently work in the 7.x branch?