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

Alembic Migrations Roadmap #2

Open
4 of 14 tasks
pmdevita opened this issue Jul 14, 2023 · 1 comment
Open
4 of 14 tasks

Alembic Migrations Roadmap #2

pmdevita opened this issue Jul 14, 2023 · 1 comment

Comments

@pmdevita
Copy link
Owner

pmdevita commented Jul 14, 2023

  • Upgrade
    • Upgrade only a specific component
    • Upgrade to a specific checkpoint
    • Improve command verbosity
  • Downgrade
    • Downgrade to a specific checkpoint
    • Improve command verbosity
  • Make Migrations
    • Detect table/column renames and ask user for input
    • Detect new non-null column being added and get a default value
    • Improve command verbosity
      • Add/Remove models
      • Add/Modify/Remove columns
  • Testing?

Some things will just need to be determined through usage:

  • Atsume Alembic currently creates migrations by simulating all previous migrations on an in memory database and then doing the diff with that, whereas vanilla Alembic expects to be running against your already in use database. Does this cause issues or result in poor performance after a lot of migrations?
@pmdevita pmdevita pinned this issue Jul 14, 2023
@pmdevita
Copy link
Owner Author

Regarding the in memory database, Prisma is an example of another ORM with migrations generating an in-memory database to detect schema differences, although they do it just for error checking (the feature is called Shadow DB). This gives me a bit more confidence in the viability of this approach

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