Skip to content
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

Closed
ShadMickelberry opened this issue Oct 25, 2018 · 2 comments
Closed

Support for multiple external key configuration #17

ShadMickelberry opened this issue Oct 25, 2018 · 2 comments

Comments

@ShadMickelberry
Copy link
Contributor

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.

@esimonetti
Copy link
Collaborator

esimonetti commented Nov 4, 2018

Hi Shad,

Thanks for reaching out!
As a first though, I believe this scenario can definitely happen, but it might not be so common after all, and eventually it could be solved with some data processing.

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!

@ShadMickelberry
Copy link
Contributor Author

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

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

No branches or pull requests

2 participants