A tool for downloading and analysing server info from OriginsRO
King_DuckZ
ef39dee43e
Program receives the full items list periodically. I don't think they will ever remove records from there, but if they do the program should not corruct the db. So far the simple approach drop table items/create table items ensured the items list is always fresh, but it prevented foreign key constraints on shop items. Also, if an item was removed from items, any entry in shop would become orphaned or worse point to the wrong item if they recycled the id. Solution is to not use item_id at all for the relationship between shop items and items table, instead have my own internal id that is valid forever. Now records removed upstream get just marked as deleted (by adding a removal timestamp). The same item_id can be reused since the unique part now must be (item_id, removal_date), in other words there is only one non-deleted item_id, but there can be several deleted ones. Code stores the full items set into items_staging, marks records in items but not in items_staging as deleted, then adds any missing records to items from items_staging, then drops items_staging. |
||
|---|---|---|
| sample_responses | ||
| src | ||
| subprojects | ||
| .gitignore | ||
| .gitmodules | ||
| COPYING | ||
| meson.build | ||
| meson_options.txt | ||
| orotool.conf | ||