When changes like flesh2nougat are made, what are the effects on the usage of
BrickStock for uploading, parting etc?
Any thoughts?
None that we can see as log as you keep the database updated.
The way Bricklink was developed allowed them to simply type Nougat for Flesh
in the colours table and that filters all the way through the system for colours
and of course that is how Brickstock does it as well. We have used Brickstock
all day today and although we didn't list any Nougat's at all - there
it was in all its glory and no more flesh.
It is a different story, however on descriptions of elements - provided they
have enabled SQL Text search, they can do a search and replace for flesh etc,
but then again I think I remember someone saying there was spaghetti code in
there somewhere.
The way Bricklink was developed allowed them to simply type Nougat for Flesh
in the colours table and that filters all the way through the system for colours
and of course that is how Brickstock does it as well. We have used Brickstock
all day today and although we didn't list any Nougat's at all - there
it was in all its glory and no more flesh.
Bricklink colors have a number associated with them that I believe is Lego's
own number. Probably Brickstock always went by the number that didn't change.
[…]
Bricklink colors have a number associated with them that I believe is Lego's
own number.
BL’s and TLG’s numbers are different for old colours.
Probably Brickstock always went by the number that didn't change.
Simplest thing to do.
Even better: use your own IDs and have match tables so it’s easier to follow
changes (both “bla bli blo” becoming “bla bli blu” and id_01 becoming id_001),
history (keep both id_01 and id_001 pointing to your own id) and other sources.
I think that’s what BrickStock does with Part/Item IDs.
[…]
Bricklink colors have a number associated with them that I believe is Lego's
own number.
BL’s and TLG’s numbers are different for old colours.
Not just old colors. The color IDs in BrickLink are assigned as keys from the
database when new colors are added. TLG's system of numbering is completely
different.
Probably Brickstock always went by the number that didn't change.
Simplest thing to do.
Even better: use your own IDs and have match tables so it’s easier to follow
changes (both “bla bli blo” becoming “bla bli blu” and id_01 becoming id_001),
history (keep both id_01 and id_001 pointing to your own id) and other sources.
I think that’s what BrickStock does with Part/Item IDs.
Yeah, I don’t know if TLG really has a system or just a couple of dice
TLG's color IDs are vaguely chronological, but it's based on when the
color was created/added to the palette, even if they aren't actually used
in sets right away. Some colors never get used, which explains the gaps in the
IDs.
I haven't figured out the methodology behind the numbering of the first 30
or so colors, but I think it has something to do with Modulex...
Netherlands, Gelderland
United Kingdom, England
USA, Oklahoma
France, Nouvelle-Aquitaine
