Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write db migration code for breaking FSEvent change #151

Open
4 tasks
CheatCod opened this issue May 6, 2023 · 0 comments
Open
4 tasks

Write db migration code for breaking FSEvent change #151

CheatCod opened this issue May 6, 2023 · 0 comments

Comments

@CheatCod
Copy link
Member

CheatCod commented May 6, 2023

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant