-
Notifications
You must be signed in to change notification settings - Fork 5
Open
Description
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
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels