Hi Fulminis,
No problem
I'll try and explain.
It has two "modes" a simple copy, and an extraction. I'll take the simplest first, the copy. It is done in steps 5 and 8.
The tables that are nominated in the config file are, in step 8, simply copied, structure and all, to tables elsewhere. Straightforward enough, and step 2 checks the structures, notes down any columns which are different from the new datapack loaded, so that you can take action before restoring the tables to the database.
When the backup is made, the backup table is dropped and the live table copied. When the backup is replayed, however, the live table is truncated, rather than dropped, so that any new structure remains intact, and then the rows are copied over, specifically by column reference.
The merge system treats the tables in the same way, so that any new datapack structure is left intact, and not simply written over with the backup. However, the merged tables work like this ...
When you load your first datapack, you take a reference point. That simply sits in the backup database while you play on and make your changes.
When you are ready to transfer, you run an extraction - and that is what takes the time. The system runs a comparison of live against the reference point. Whatever is found in the live table, but not in the reference table, is noted as something you have added to the table. Anything found in the reference but not in the live, is presumed to be something that you removed from the tables during your configuration. Thus, two tables are created, one for additions and one for deletions.
You then replace the live tables with the new datapack, and then make that the new reference point. Once the new data is in, you simply replace the additions and deletions against the new datapack.
Again, the additions and deletions take note of changes in fields when replaying. Obviously, when you take your reference points and your backups, the new structures are used.
The comparisons are complete across a tables colums, so only completely exact rows are acted upon. You could change the order of some items in a shop, for example, and it will show up as additions and deletions.
Any additions which fail, for example they may have been put in the datapack as standard, are recorded in an "error" table in the knightback database, as a record of the SQL statement it tried to execute, and the error that came back. You can then go through these at your leisure.
Sometime tomorrow, I'll try and re-explain anything that you'd like me to go in to more detail on ... I just need some sleep first
My friend is a paranoid schizophrenic ... she'll take over the world, as long as nobody minds.
