Skip to content

Write db migration code for breaking FSEvent change  #151

@CheatCod

Description

@CheatCod

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions