The next step is to include the "source DAT name" in the dupe field instead of just "false". It will still be changed to "true" on merging, however. This will allow for multi-dat AB output since each unique source can have the non-dupe roms outputted. This will require a change in WriteToDat2 as well to enable "AB" mode, or at least a field called source that is default empty. If it's not empty, it tries to write out ONLY things that match that source. Maybe merge it in to the "diff" mechanic. Actually, if it's a flag, it will just output every variant: All in A, All in B, All in both, All not in both. Pretty easy.
This change makes it mostly functional, having a way to both parse and merge in one step and output from the database. The issue is that the output from Parse2 doesn't match Parse OR Parse + Merge. Duplicates don't seem to be added in the first case and there are a differing number of roms in the second.
The new merging process is both parse and merge in one step using an in-memory database. The next steps are to get the data in this database and write it out properly.
Basically, this will output the information that's in each DAT but not in the merged and also the data that's only in every DAT. This needs testing, but it's a good start.
This code can be enabled for local testing by uncommenting and running it in place of the current code. This is the first of few commits with similar theme
The current format of the database is good for small amounts of data. The truth is that the hashes and sizes of the files are what really determine if a file is different or not. After chatting with Obiwantje about this, I'm beginning some code tests with a hash-centric database model, instead of the game/rom centric. This means that each hash can have mutliple roms attached to it, similarly a given game can have multiple sources or systems attached. It's a much cleaner system, but demands a total rewrite and new databae structure.
