Is there a built-in concept of model/schema versioning?

[Matt S]

Does Alembic has the concept of versioned schemas/models? In Alembic, I need to re-define a model which matches the database table for the current migration. Becomes verbose after several migrations, redefining the same out-of-date model. So I created a "legacy_models" module where I define old models that don't match the current version. But I'm wondering if I'm reinventing the wheel?

I'm referring to the `table(...)` stuff mentioned here: https://www.georgevreilly.com/blog/2016/09/06/AlembicDataMigrations.html

I have to repeat the "table" definition in every migration.

But, for example, in Django a migration can refer to the version of the model at that point in time (when the migration was created) rather than the current version of a model which might have different columns. These model versions are automatically managed by Django.

[Mike Bayer]

On Fri, Jan 24, 2020, at 8:49 AM, Matt S wrote:

Does Alembic has the concept of versioned schemas/models? In Alembic, I need to re-define a model which matches the database table for the current migration. Becomes verbose after several migrations, redefining the same out-of-date model. So I created a "legacy_models" module where I define old models that don't match the current version. But I'm wondering if I'm reinventing the wheel?

I'm referring to the `table(...)` stuff mentioned here: https://www.georgevreilly.com/blog/2016/09/06/AlembicDataMigrations.html

I have to repeat the "table" definition in every migration.

do all of your migrations include data migrations?     This is not the usual case for most migrations.     You may note in that blog post that you only need to define the columns in the "table()" that you care about for the immediate SQL statement you need to emit, so for the typical migration that needs to move a column or a few tables around, a full blown ORM model is not necessary (nor are ORM operations that efficient for bulk operations).

But, for example, in Django a migration can refer to the version of the model at that point in time (when the migration was created) rather than the current version of a model which might have different columns. These model versions are automatically managed by Django.

yes django migrations are based around an entirely different model where their "ORM" model and schema are all one monolithic thing, so they basically maintain a structure that fully represents the complete schema at every step.     IIUC they don't use database introspection at all, they just have this moving model thing going on where changes to the model can be diffed against that structure which they have.  

Alembic is way more lightweight than that and we would not have the development / maintenance resources to keep something like that going, especially that SQLAlchemy / Alembic, unlike Django are fully open-ended as far as backend database capabilities, table structures, etc., including that migration files can have any kind of l iteral DDL or SQL in them.   It would be a huge job to design, implement and maintain such a system and Django's system was also built based on a kickstarter project that collected something like $30K (also, I can't build this system for $30K because I don't have the time resources).

Overall if you are having to build full blown ORM models for every migration that seems a little unusual, as well as that you would have data migrations that need to run from scratch forever.    Usually, production systems are only dealing with recent migrations, and development environments that start from scratch have no data to be migrated.    If you truly have production systems that need to continue migrating through many legacy versions the typical upgrade path is to have those systems install different versions of the software itself, migrating data at each turn.     For the Django-like system, someone would have to be interested in building and maintaining that (could well be an external add-on to Alembic).

--

SQLAlchemy -

The Python SQL Toolkit and Object Relational Mapper

 

http://www.sqlalchemy.org/

 

To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description.

---

You received this message because you are subscribed to the Google Groups "sqlalchemy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/515d89c3-f48c-42ba-a2ba-e54753306276%40googlegroups.com.