lodestone_core
lodestone_core copied to clipboard
Write db migration code for breaking FSEvent change
Description
This is a fun one.
The new proposed FSEvent is defined as follows:
pub enum FSEvent {
ReadFile {
source: PathBuf,
},
ReadDir {
source: PathBuf,
},
Write {
source: PathBuf,
},
Move {
source: PathBuf,
destination: PathBuf,
},
Unzip {
source: PathBuf,
unzip_option: UnzipOption,
},
Zip {
source: Vec<PathBuf>,
},
CreateFile {
source: PathBuf,
},
CreateDir {
source: PathBuf,
},
DeleteFile {
source: PathBuf,
},
DeleteDir {
source: PathBuf,
},
Upload {
source: PathBuf,
},
Download {
source: PathBuf,
},
}
The current FSEvent looks like this:
pub enum FSOperation {
Read,
Write,
Move { source: PathBuf },
Create,
Delete,
Upload,
Download,
}
#[derive(Serialize, Deserialize, Clone, Debug, TS, PartialEq)]
#[serde(tag = "type", content = "path")]
#[ts(export)]
pub enum FSTarget {
File(PathBuf),
Directory(PathBuf),
Multi(Vec<PathBuf>),
}
#[derive(Serialize, Deserialize, Clone, Debug, TS, PartialEq)]
#[ts(export)]
pub struct FSEvent {
pub operation: FSOperation,
pub target: FSTarget,
}
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
migrationmodule - [ ] Have migration code run between the appropriate versions that goes through the database and and replace any old FSEvent with the new one