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

Revamp to better flow #3

Open
chez14 opened this issue Jun 18, 2020 · 4 comments
Open

Revamp to better flow #3

chez14 opened this issue Jun 18, 2020 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@chez14
Copy link
Owner

chez14 commented Jun 18, 2020

We'll move the migration status to database (and file), and adding new tracking for each migration. I think. This idea needs to be brainstormed so I'll post the updates in this issue.

@chez14 chez14 added the enhancement New feature or request label Jun 18, 2020
@chez14 chez14 self-assigned this Jun 18, 2020
@chez14
Copy link
Owner Author

chez14 commented Jan 23, 2021

Database schema:

  • ilgar_migration
    • id, int, PK
    • version, text
    • executed_on, datetime

Usecase:

  • Migration will check on latest version, eg. by sorting the version of the migration from the DB.
    • System will scan migration directories, then rule-out the one that has been migrated from the DB. We'll call this as resync migration. → Will be default behavior.
    • System will only migrate the one that are newer from the DB. The old one that are not yet migrated will be ignored. This will be the normal and default migration strategy. → Cancelled because this is not actually that normal and will not be implemented this time.
  • Revert Migration. Migration will check from DB and check what's migrated and what's not.
    • If there's migration that are listed on DB, but not present on the file system, we'll ignore them by default and send some warning. On "strict revert" strategy, this will throw an error and stop it being continued.

@chez14
Copy link
Owner Author

chez14 commented Jan 23, 2021

Potential new settings param:

  • migration_strategy, possible values normal, resync
  • revert_stategy, possible values normal, strict
  • migration_table_name, default to ilgar_migration migrations.
  • database, default to DB.
  • store, default to database, potential values database, file.

Potential shared info:

  • get migration version
  • get migration list

@chez14 chez14 mentioned this issue Nov 8, 2021
@chez14
Copy link
Owner Author

chez14 commented Nov 8, 2021

Questions:

  • Do people need "soft" fail for migration?
    e.g: things doesn't run as expected, so we can just run return false. → I think this will be bad because the return thingy should give us what makes it error. → i think we can create an helper like $this->failIfFalse(....)

chez14 added a commit that referenced this issue Nov 15, 2021
chez14 added a commit that referenced this issue Nov 15, 2021
chez14 added a commit that referenced this issue Nov 15, 2021
Context Interface will be exposed to migration classes. By creating the interface,
the API will be more stable for the future.

Ref #3
@chez14
Copy link
Owner Author

chez14 commented May 14, 2022

Next TODOs for Ilgar:

  • Turn off the web access by default.
  • Add default settings handler test
  • Add revert functionality with extra parameters for "strict revert" or not. (Strict revert means it will stop running if the original migration script is not there).
  • Add Extra API for
    • get migration version
    • get migration list
    • Revert via API

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant