-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for multiple external key configuration #17
Comments
Hi Shad, Thanks for reaching out! A possible solution that comes to mind with the current state of the library and your use case, is to add a new field on the Products module (QLI) that stores the concatenation of the two (or N) external systems unique keys and then execute lookups based on that key combination, and create an index in Sugar for lookups on that field only. Nonetheless, if you do think it is generic enough, it should be pretty easy to implement. The SQL queries would have to accept a number of parameters and those parameters need to be populated from the library and have to be passed to the request. The challenge I see, is that the more fields you need to lookup on, for every single system's entry, the more additional indexes you should add to Sugar to make the integration/data migration perform well. As those additional indexes most likely would only be valid for integration based lookups (and not to improve end user performance), I have the feeling it might be overall detrimental for the user's system performance. I am working with limited information and lots of (most likely incorrect) assumptions here, so please bear with me if I misunderstood something, but do let me know what you think about my comments. Cheers! |
Hello Enrico, Thank you for the thoughtful response and I think at the core you understand exactly the scenario I am thinking of. I had started looking into implementing this and as it often turns out although the idea is simple the actual impacts get to be quite complicated. I had not thought of the concatenated field and that suggestion is brilliant in my opinion. Perhaps I'll just add that to the documentation instead of the original idea. Thank you very much |
Although rare I've run into cases where there are more than one field used as a unique search criteria. An example of this is for Quote Line items that do not have a key but are referenced by an order ID and sequence or line number. This is usually a limitation of the external system requiring a work around.
I have made the fork and am going to take a shot at implementing this but any commentary is welcome.
The text was updated successfully, but these errors were encountered: