SQLAlchemy weekly dev meetings: https://docs.google.com/document/d/1WuzZwV_aIV_ltDR3cJ-bXxXMZ9zCfr5pFSXZGZOSSQw/edit?usp=sharing
as always the gigantic raging fire in alembic is the enum thing :)
never seen such a small area get so many requests for improvement
they suck
but also to add elements, you have to turn autocommit on
i have notions of migration files getting big conditioanl structures in them
that raise by default until the user goes in and gives the green light they are OK entering autocommit
Basically the use case is: user set a parameter, like increment to 2; creates the table; reset the increment to None.
in my view, if someone put an Identity() in their model with specific defaults, then created the DB, then removed the arguments from the Identity and made it blank, then ran autogen, I would not expect it to know whether or not the database should change. if the user model lacks specificity then it follows they should not expect alembic to recreate that specificity
this is the same as what we do when comparing types
and the DB that means DECIMAL(10, 2)
we don't try to detect that it;s DECIMAL(10, 2) and not DECIMAL(10, 3)
So I'll limit to that.
people would like that, to see where laembic is like, "hey i cant tell if these are different btw"
it would be a very noisy warning, so like a -vv kind of flag maybe
and we could even put a hook there
then there's some common API that different areas, like the part that compares Identity, the part that compares CheckConstraints, the part that comapres types, etc. can all call that thing
i.e. it's more interesting to me that we identify everywhere this happens
You mean a single column? I think there is for a table, this one https://docs.sqlalchemy.org/en/14/core/reflection.html?highlight=inspector#sqlalchemy.engine.reflection.Inspector.get_columns
This returns a lost of dicts, that is used by reflect_table
This way we can pick up any changes in database versions on unit tests
If a new database version changes, chances are it won't affect anything - but at least we will know
That would he useful
e.g. a bug I missed due to it
https://docs.sqlalchemy.org/en/14/core/reflection.html?#fine-grained-reflection-with-inspector
this uses insp = reflection.Inspector.from_engine(engine)
however that method is deprecated https://docs.sqlalchemy.org/en/14/core/reflection.html?#sqlalchemy.engine.reflection.Inspector.from_engine
I can generate a gerrit