-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Create table and dependent view on same Alembic migration #49
Comments
I'm guessing this lib will largely have similar issues, generally, to alembic_utils for certain kinds of entities. Views in particular are difficult because postgres will internally normalize the SQL you give it, which makes actually attempting to create the view (and roll back the creation) somewhat necessary in many cases. With that said, I think for this usecase, I can probably help. For a pure creation, we know it's being created ahead of time and dont need the complex live-database comparison. I suspect that it's really only for updates that it becomes important |
That would be awesome! Let me know if you need help testing. |
Sure, if you want/are able to test out I'll wait a few hours, or until you respond affirmative and merge it anyways :P |
Amazing! Many thanks for the speedy response. 🚀 I did test it after pip installed this branch straight from github. On the first attempt I got a dependency missing After installing this package migration worked without any issues! 🥳 Here is an edited version of the migration: op.create_table('foo',
sa.Column('id', sa.Integer(), autoincrement=True, nullable=False),
sa.Column('created_at', sa.DateTime(), nullable=False),
sa.PrimaryKeyConstraint('id', name=op.f('pk_foo')),
schema='test'
)
op.create_index(op.f('ix_foo_id'), 'foo', ['id'], unique=False, schema='test') # I had this index on my Mixin table_args
op.execute("""CREATE VIEW high_foo AS SELECT [test.foo.id](http://test.foo.id/), test.foo.created_at FROM test.foo WHERE [test.foo.id](http://test.foo.id/) >= 10;""")
op.execute("""DROP VIEW <ALL MY CURRENT PGView/PGMaterializedViews ARE DROPPED>""") Stack trace from first run of running pytest_alembic:
|
Ah yes, the dep is on the poetry lock. So probably something on my setup. |
sqlglot is behind the Also, fwiw, you can register alembic_utils views in the same way you do normal ones, as a compatibility layer: https://github.com/DanCardin/sqlalchemy-declarative-extensions/blob/main/tests/view/test_alembic_utils.py I originally wrote this library for...a variety of reasons, but the fact that alembic_utils embeds its own imports into your migrations makes it quite difficult to remove after the fact, so it seemed prudent to include this ^, as a measure against all your views being force dropped on you. Although with that said, I'm not sure I can guarantee all the same things through that layer, so ymmv. |
Should be released in 0.7.2 momentarily! |
Awesome, many thanks for the PR and explanation :) |
Hi there,
First of all, great work on this library. Really convenient for creating views/materialised views.
The problem I am facing is the same as this one described in the
alembic_utils
package:olirice/alembic_utils#79
Specifically, I would like to, for each new table I create, generate an accompanying view. And for that I would like migrations to be able to introspect and find the dependencies from view->table. This because my tables are append-only, and I would like to have a latest view of those.
Then with
register_alembic_events
I register those in my alembicenv.py
Is this something solvable with the approach you've taken in this package? Am I missing something on my end?
The text was updated successfully, but these errors were encountered: