  
| Author: | SylvainLS  | | Posted: | Apr 19, 2024 06:39 | | Subject: | Re: Variants Thread - April 16 | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, axaday writes:
| | […]
How much data space would it take to have two catalogs? One for detailed data
and one for generalized marketplace?
|
The problem isn’t space, it’s consistency and workload.
Basically, you’re doubling the workload.
If you make a change in one of the catalogues, should it be echoed on the other
one? To which extent? Can that be automatized?
In the software world, that’s called a fork (external / by another team) or a
branch (internal / by the same team).
We have tools and procedures to follow and “port” (transfer, apply) changes between
branches / versions / forks (‘diffs’ and ‘patches’ and ‘version control system’
(git, bitkeeper, mercurial…)).
And those tools are good and ‘smart.’ They can work around other changes and
differences that shouldn’t change (and (good) devs are lazy: everything that
can be automatized is automatized).
But we ALWAYS need to check the changes. The changes may apply without a hitch…
but they may break the program because they contradict an older change. That
can also be automatized, to some extent. But it’s work again and you can never
predict everything so you always need to check.
Duplicating a database and the changes on the database can be automitized in
the same way: changes are just instructions, like a program. So the same porting
solutions & problems apply: Should that change be applied? Can it be applied?
Should another change be applied instead? And you always need to check, check,
check.
Also, you first need to record these instructions. AFAIK, BrickLink’s changelogs
aren’t complete / sufficient.
TL;DR: It’s the same as the work done by Rebrickable: another catalogue, with
conversion tables, with changes to follow / apply or not, with errors or misses…,
and with a full team to manage it.
It could be a bit simpler and you could save a bit by keeping it inside BrickLink,
but that won’t remove most of the work needed.
Another possibility is to handle that in only one “catalogue,” with two (or more!)
different ways to present its info. The work would be done only once, in the
more detailed catalogue, and there would be mechanisms to hide the details to
the users. But that’s the same as the “umbrella part” solution: you need to
change the whole structure of the database and the way the site works. That
can’t be patched onto what exists now (which is already patched enough with spaghetti
and sauce as it is).
|
|
Message is in Reply To: 22 Messages in this Thread:  Msg 1 - Admin_Russell 30 days ago Apr 16, 2024 to Catalog
 Msg 2 - axaday (7302) 30 days ago Apr 16, 2024 to Catalog
 Msg 3 - rickcraine (4) 30 days ago Apr 16, 2024 to Catalog
 Msg 4 - axaday (7302) 30 days ago Apr 16, 2024 to Catalog
Msg 5 - Dhobeck (33)  30 days ago Apr 16, 2024 to Catalog
Msg 6 - axaday (7302) 30 days ago Apr 16, 2024 to Catalog
Msg 7 - Dhobeck (33) 30 days ago Apr 16, 2024 to Catalog
Msg 8 - Admin_Russell 30 days ago Apr 17, 2024 to Catalog
Msg 9 - axaday (7302) 30 days ago Apr 17, 2024 to Catalog
Msg 10 - Saitobricks.ca (37) 29 days ago Apr 17, 2024 to Catalog
Msg 11 - jennnifer (3534) 29 days ago Apr 17, 2024 to Catalog
Msg 12 - Stellar (3504) 29 days ago Apr 17, 2024 to Catalog
Msg 13 - axaday (7302) 29 days ago Apr 17, 2024 to Catalog
Msg 14 - Admin_Russell 30 days ago Apr 17, 2024 to Catalog
Msg 15 - UTLF (1267) 30 days ago Apr 16, 2024 to Catalog
Msg 16 - Saitobricks.ca (37) 29 days ago Apr 17, 2024 to Catalog
Msg 17 - UTLF (1267) 29 days ago Apr 17, 2024 to Catalog
Msg 18 - jennnifer (3534) 29 days ago Apr 17, 2024 to Catalog
Msg 19 - Saitobricks.ca (37) 29 days ago Apr 17, 2024 to Catalog
Msg 20 - Dhobeck (33) 29 days ago Apr 17, 2024 to Catalog
Msg 21 - axaday (7302) 28 days ago Apr 19, 2024 to Catalog
Msg 22 « - SylvainLS (46) 28 days ago Apr 19, 2024 to Catalog
Entire thread on one page
This message and all its replies on one page
|
|
France, Nouvelle-Aquitaine
