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

Support alembic check #70

Open
DanCardin opened this issue Jul 9, 2024 · 0 comments
Open

Support alembic check #70

DanCardin opened this issue Jul 9, 2024 · 0 comments

Comments

@DanCardin
Copy link
Owner

This implies all "ops" should implement a to_diff_tuple which accepts no arguments and roughly is able to return the raw sql it should generate.

The two problems here are:

  • views currently accept a dialect to the function(s) which generate sql. this can probably be massaged away by having dialect specific impl of the normalization step that postgres does (inside the postgres-specific view).
  • some of the ops' to_sql functions produce lists of strings instead of just a string. the to_diff_tuple interface seems to want a single statement. Either we concat them for this, and it doesn't exactly match the migration, or we normalize them out into separate ops (i'd rather not), or we combine the sql statements into a single execute (i'd rather not)
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