-
-
Notifications
You must be signed in to change notification settings - Fork 268
need to associate autogen metadata w/ operations to support metadata-bound naming conventions #183
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
Comments
Michael Bayer (@zzzeek) wrote: good catch, these constraints are generated in a different context |
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote:
fixes #183 → a6b02d1 |
Changes by Michael Bayer (@zzzeek):
|
Michael Bayer (@zzzeek) wrote: OK I really had to go nuts on this one to cover the bases, and its not clear that I took the best approach. I like that an autogenerate run produces the constraints with their final name inline; this allows migration files to be independent of naming convention changes. However I balked at going as far as making it do this automatically within Boolean() and Enum(), and also, I still wanted a way to write directives in a migration script where the naming conventions do take effect. Usually, whether or not the name is None makes this easy to decide. But because i wanted this stupid "constraint_name" token (which is because that's how i was using it already at work), it's not that simple (I don't know of any other good way to give CHECK constraints a deterministic and unique name, there has to be some kind of token, unless I pull out the columns I guess, but multiple CHECK constraints on a single column is very possible). So the new feature op.f() is now used to disambiguate names that have already been tokenized vs. those that have not. It requires SQLAlchemy 0.9.4 for it to be usable. If you want to try out SQLAlchemy 0.9.4 from master and this, feel free to let me know that this improves things. |
Marek Baczyński (@imbaczek) wrote: I can confirm that using both SQLAlchemy and alembic master works as advertised. Thanks! |
Migrated issue, originally created by Marek Baczyński (@imbaczek)
DB: SQL Server 2008R2
SQLAlchemy==0.9.3
alembic==0.6.4dev (today's master and 0.6.3 too)
output:
env.py
package/db.py
The text was updated successfully, but these errors were encountered: