You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When adding info provider parts, Mouser sometimes reports "N/A" as the MPN.
If you add the part, there is no problem, but if you add a second part with MPN=N/A, you get the above error.
To Reproduce
Steps to reproduce the behavior:
Search for parts via Mouser info provider
Find part with MPN "N/A" and add it
Find another part and try to add it as well - the exception is raised.
Expected behavior
The part could be merged automatically to the existing ID (similar to the feature "update part from info provider"). Then the user can decide if the merge is meaningful, and if not, abort it.
Part-DB Version: 1.11.3
Additional info
I think it's a waste of time to find a feature of every possible (also future) API response that is always unique, so duplicates must be handled somehow.
The text was updated successfully, but these errors were encountered:
The problem is not the manufacturer part number.
This error occurs, when the Mouser Product ID (which should identify a product of mouser uniquely) is not unique anymore.
Without such a identifying key, it is not possible for Part-DB to know which part a user has selected.
Therefore, I am afraid that there is no real fix for it, for the underlying issue, as there is no other usable identifier.
To avoid the problem, the provider now checks, if the number looks valid and hide these which are too short. That way the problem should not occur anymore.
And the parts with such an invalid product ID are not sold by mouser anymore, so hiding them is probably not a big loss.
Describe the bug
When adding info provider parts, Mouser sometimes reports "N/A" as the MPN.
If you add the part, there is no problem, but if you add a second part with MPN=N/A, you get the above error.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The part could be merged automatically to the existing ID (similar to the feature "update part from info provider"). Then the user can decide if the merge is meaningful, and if not, abort it.
Part-DB Version: 1.11.3
Additional info
I think it's a waste of time to find a feature of every possible (also future) API response that is always unique, so duplicates must be handled somehow.
The text was updated successfully, but these errors were encountered: