| Discussion Forum: Thread 339834 |
|
 |
| | | Author: | InanimateReason  | | Posted: | May 16, 2023 07:55 | | Subject: | API Question: How immutable are id values? | | Viewed: | 89 times | | Topic: | Technical Issues | |
|
| As I work through a client to do useful things with the Bricklink API, I'm
curious what issues other developers have experienced that may impact the robustness
any application.
One thought I just had was that there is no guarantee that the underlying data
is stable within the various catalog related resources.
An obvious example is assignment of part numbers. Clearly, they may change over
time. When they do, are new element ids assigned or would the element id be a
reliable way to ensure data integrity?
Would it be wise to preserve the old part numbers in some way either with a soft
delete or some other kind of deprecation flag?
I would like to work with the assumption that certain values are essentially
primary keys. category IDs, color IDs, really anything named xxxx ID. It seems
to me that the nomenclature in use implies that anything called 'id'
is immutable while anything else is fair game for modification during catalog
updates.
Thoughts?
|
|
|
| | | | | |
| | | | | Author: | InanimateReason | | Posted: | May 16, 2023 08:09 | | Subject: | Re: API Question: How immutable are id values? | | Viewed: | 36 times | | Topic: | Technical Issues | |
|
| Out of curiousity, I downloaded the codes mapping xml file. I guess element IDs
are only assigned to parts. I did find six minifigs in that download, but the
first one I checked was previously a PART.
https://www.bricklink.com/catalogReqList.asp?itemID=147947
So I guess element IDs may only be useful for the parts type in the catalog.
Other catalog types need some other mechanism to track changes. With no changelog
endpoint or key in the item resource, I guess this will be fun to implement.
In Technical Issues, InanimateReason writes:
| | As I work through a client to do useful things with the Bricklink API, I'm
curious what issues other developers have experienced that may impact the robustness
any application.
One thought I just had was that there is no guarantee that the underlying data
is stable within the various catalog related resources.
An obvious example is assignment of part numbers. Clearly, they may change over
time. When they do, are new element ids assigned or would the element id be a
reliable way to ensure data integrity?
Would it be wise to preserve the old part numbers in some way either with a soft
delete or some other kind of deprecation flag?
I would like to work with the assumption that certain values are essentially
primary keys. category IDs, color IDs, really anything named xxxx ID. It seems
to me that the nomenclature in use implies that anything called 'id'
is immutable while anything else is fair game for modification during catalog
updates.
Thoughts?
|
|
|
|
| | | | | |
| | | | | Author: | qwertyboy | | Posted: | May 16, 2023 11:23 | | Subject: | Re: API Question: How immutable are id values? | | Viewed: | 34 times | | Topic: | Technical Issues | |
|
| In Technical Issues, InanimateReason writes:
| | I would like to work with the assumption that certain values are essentially
primary keys. category IDs, color IDs, really anything named xxxx ID. It seems
to me that the nomenclature in use implies that anything called 'id'
is immutable while anything else is fair game for modification during catalog
updates.
|
There are precious few fields that can be considered a primary key. Part numbers
can (and do) change, people's login name can (and do) change. There is no
way for us mere mortals to access the actual primary key info for these entities.
If you are considering keeping things like parts history, be prepared to either
set up some links from old part IDs to new part IDs, or update your old data
with new IDs (finding out what the new part ID is when you only have the old
part ID is fun - what is the new part ID of "372"? - most times, the
old ID is kept as an alternative on the site, so you can search for it, but not
from the API). Some parts keep flip-flopping IDs (like 6093/x104, 41669/x346
etc).
Some things that do stay the same are order numbers, color IDs, lot IDs.
Enjoy!
Niek.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | SylvainLS | | Posted: | May 16, 2023 12:16 | | Subject: | Re: API Question: How immutable are id values? | | Viewed: | 24 times | | Topic: | Technical Issues | |
|
| In Technical Issues, qwertyboy writes:
| | […]
(finding out what the new part ID is when you only have the old
part ID is fun - what is the new part ID of "372"? - most times, the
old ID is kept as an alternative on the site, so you can search for it, but not
from the API). Some parts keep flip-flopping IDs (like 6093/x104, 41669/x346
etc).
|
If you have Id+name, you can check if an item with the exact same name exists…
provided they didn’t also change the name when they changed the Id.
What fun! 
|
|
| | | | | |
| | | | | Author: | hpoort | | Posted: | May 16, 2023 12:33 | | Subject: | Re: API Question: How immutable are id values? | | Viewed: | 28 times | | Topic: | Technical Issues | |
|
| In Technical Issues, InanimateReason writes:
| | As I work through a client to do useful things with the Bricklink API, I'm
curious what issues other developers have experienced that may impact the robustness
any application.
One thought I just had was that there is no guarantee that the underlying data
is stable within the various catalog related resources.
An obvious example is assignment of part numbers. Clearly, they may change over
time. When they do, are new element ids assigned or would the element id be a
reliable way to ensure data integrity?
Would it be wise to preserve the old part numbers in some way either with a soft
delete or some other kind of deprecation flag?
I would like to work with the assumption that certain values are essentially
primary keys. category IDs, color IDs, really anything named xxxx ID. It seems
to me that the nomenclature in use implies that anything called 'id'
is immutable while anything else is fair game for modification during catalog
updates.
Thoughts?
|
There are numeric primary keys in the database, but unfortunately, those are
not exposed through either the API or the UI. I remember vaguely that years ago
I did spot some places where the primary keys were exposed, but I don't see
any of the catalog object ID's exposed anymore. You can tell from the changelog
that there must be some immutable primary key laying under the data that we see
through the UI.
Store Items still have an exposed ID. You can tell from the hyperlinks and URL's.
Other objects that have a ID=numeric URL are supposed to have an immutable ID:
Forum Messages, Forum Threads, Direct Messages, Wanted Lists, and probably some
more.
Color IDs are immutable, although merges may occur.
You probably won't need to keep the old Part Numbers, as you could always
trace back older part number references through Bricklink's catalog change
log: https://www.bricklink.com/catalogLogs.asp
|
|
|
| | | | | | | | | |
| | | | | | | Author: | InanimateReason | | Posted: | May 16, 2023 12:39 | | Subject: | Re: API Question: How immutable are id values? | | Viewed: | 28 times | | Topic: | Technical Issues | |
|
| In Technical Issues, hpoort writes:
| | Color IDs are immutable, although merges may occur.
You probably won't need to keep the old Part Numbers, as you could always
trace back older part number references through Bricklink's catalog change
log: https://www.bricklink.com/catalogLogs.asp
|
Hmm. Hadn't considered merges. Other than an ID disappearing, how would one
know?
For the catalog change log, I know you can see it on the site but the data is
not exposed through the API so it would have to be scraped with dates turned
on.
Definitely an interesting problem!
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | Stellar | | Posted: | May 16, 2023 15:39 | | Subject: | Re: API Question: How immutable are id values? | | Viewed: | 33 times | | Topic: | Technical Issues | |
|
| In Technical Issues, InanimateReason writes:
| | In Technical Issues, hpoort writes:
| | Color IDs are immutable, although merges may occur.
You probably won't need to keep the old Part Numbers, as you could always
trace back older part number references through Bricklink's catalog change
log: https://www.bricklink.com/catalogLogs.asp
|
Hmm. Hadn't considered merges. Other than an ID disappearing, how would one
know?
For the catalog change log, I know you can see it on the site but the data is
not exposed through the API so it would have to be scraped with dates turned
on.
Definitely an interesting problem!
|
This can help: https://www.bricklink.com/btchglog.asp?viewHelp=Y
|
|
|
|
|
|
USA, Georgia
Canada, Alberta
France, Nouvelle-Aquitaine
Netherlands, Groningen
Spain, Comunidad Valenciana