lodestone_core icon indicating copy to clipboard operation
lodestone_core copied to clipboard

Write db migration code for breaking FSEvent change

Open CheatCod opened this issue 2 years ago • 0 comments

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:

  1. 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
  2. The old FSEvent leaves very little wiggle room for future variants that isn't breaking change.
  3. 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

CheatCod avatar May 06 '23 06:05 CheatCod