I am proposing this change due to the following reasons:
The old FSEvent is built on the assumption that any file system API will only have 1 source and 1 file, but unzipping and zipping does not fit into this assumption
The old FSEvent leaves very little wiggle room for future variants that isn't breaking change.
We will need to make breaking changes to the events (and thus to the database) at some point, and it's best to work out a system for migration
Steps
[ ] Find a way to save lodestone_core version to disk
[ ] Figure out if the new proposed FSEvent is appropriate and future proof
[ ] Save a snapshot of the old FSEvent in the migration module
[ ] Have migration code run between the appropriate versions that goes through the database and and replace any old FSEvent with the new one
Description
This is a fun one.
The new proposed FSEvent is defined as follows:
The current FSEvent looks like this:
I am proposing this change due to the following reasons:
Steps
migration
module