sqlalchemy-bot
commented
6 years ago Michael Bayer (zzzeek) wrote:
Alembic is a very open ended tool and can be made to do these things. However this proposal is disturbing to me since my vague impression at the moment is that it implies that Alembic needs entirely new and different workflows that co-exist side-by-side with its existing workflow, and I think that would be deeply confusing to developers that Alembic would prominently and "by default" produce two entirely different means of it being used. Alembic's tutorial attempts to cover real-world application use from start to finish. So that's the first concern you'd need to address here, that is, what's wrong with Alembic's current workflow, and to what extent are you looking to augment or replace that workflow, how would it be documented, how would I know which workflow I want to use? (and also if you could please be much more specific as to the format of this "dumpfile", as there are many technical issues in that area as well that have been previously considered).
There is a feature to both Rails and Django which is that their ORM tools (noting, they have no equivalent of SQLAlchemy Core) are extremely opinionated and rigid in the kinds of schemas they can generate, including that the supported schema structures are tightly integrated to hardcoded ORM patterns and also that there is very limited support for database-specific constructs and datatypes as these don't fit into the "one size fits all" mentality of these tools. Because of this, they can make files like "schema.rb" and whatever South does and just automatically whip out the narrow range of schemas that they support.
Alembic, building on SQLAlchemy, can't take such a free-wheeling approach to things since Alembic supports any schema concept on any database. Hence, while Alembic has very strong support for schema generation and comparison, there is always the need to manually review the Python code that it generates. There is an eternal wave of desire that folks wouldn't have to do this, and can just have it "be magic" and get the schema 100% correct the first time, but Alembic can never promise this. Therefore a "schema.py" file is problematic; for very large databases it would be huge (which makes me very skeptical of the request that this be "by default") and would require manual review and editing every time its generated. Projects can of course carefully tailor Alembic's auto-generation to handle elements that might not render correctly by default however when spitting out an entire schema all at once, there's a lot that can go wrong.
I would reiterate my request to please begin with the question of workflow, how Alembic's workflow is not good enough, how this alternate workflow would be presented to developers in a non-confusing way. thanks!
Migrated issue, originally created by Sandeep Srinivasa (sandys)
reference: http://edgeguides.rubyonrails.org/active_record_migrations.html#schema-dumping-and-you and https://github.com/miguelgrinberg/Flask-Migrate/issues/31
In a lot of cases, it is more useful to load the schema from git, than to recreate the schema using a full migration run. If you are running continuous integration, then this is a god send, since schema load is much faster than running migrations.
Rails makes this absolutely convenient. After every migration, the schema dump file "schema.rb" is autogenerated/updated. This represents the current snapshot of the database and is unconnected to whether your models are in a certain way or not. schema.rb is usually commited to git.
If you want to recreate the db, then all you do is "rake schema:load" and it recreates the db from the snapshot. This is super-fast.
Alembic as it stands today, makes it very hard to do this. As mentioned in the comment here - https://github.com/miguelgrinberg/Flask-Migrate/issues/31#issuecomment-44425040 - you have to go through some hacks to make alembic generate a snapshot.
As mentioned in https://github.com/miguelgrinberg/Flask-Migrate/issues/31#issuecomment-324697866 ,
it would be great if this was made default in alembic - to have an autogenerated schema.py file generated after every migration and a way to load this directly to an empty database. This will not break any existing semantics and will be something that will be super-helpful for those who use it.