Thanks Mike, Our developers use the ORM exclusively for database access. We maintain a package containing the tables, relationships, validates, etc. (*our_db.py*) which is imported in the front-end, back-end modules and utilities. Recently we added new fields to a table that are calculated by @validates functions. This "alpha" version of* our_db.p*y-v0.3 depends on a database that has been migrated to revision id "+2". Then a "beta" developer working on a database migrated to revision "+1" mistakenly imports v0.3, (not v0.2) into their venv, it will fail somewhere in the @validates function probably with 3-pages of indecipherable stack trace. We'd like to have our_db.py catch this error when the database is opened, perhaps by checking a list of revision id's that are known to be earlier migrations that are not supported by *our_db-v0.3*.
On Tuesday, January 10, 2017 at 1:02:43 PM UTC-7, Роберт Шотланд wrote: > > We have a project in active development that will have periodic alembic > migrations driven by an evolving declarative package. We are looking for a > means of automatically checking (say, at bind-=engine time?) a list of > obsolete alembic revision ids (embedded in our declarative package), that > would throw a custom exception if that declarative was used with a database > that had not been migrated to a version compatible with that declarative > package. > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.