SQLAlchemy weekly dev meetings: https://docs.google.com/document/d/1WuzZwV_aIV_ltDR3cJ-bXxXMZ9zCfr5pFSXZGZOSSQw/edit?usp=sharing
One thing we don't (typically) do is "sweet potato pie". Never had it, myself.
It's usually pumpkin pie for us.
@CaselIT with that kind of thing we look at the attributes and if an attribute is not set, we dont comapre it to the reflected one
I'm looking again at this. I'm not sure if it works in every case: sa you have modified some value and set it again to the default, this logic would not pick it up
@zzzeek other than the foolproof option to also compare with the default value from the connection I don't see another option at the moment. but that would mean creating a table, reflecting back the identity column and rolling back the creation
unless we hardcode the values (doable, but not a really great solution)
for the metadata I can compare with the empty Identity to see what are the attribute that are changed.
but for the connection I need to know what's the default.
but for the connection I need to know what's the default.
ok this works
def _default_identity(self, autogen_context, col_type):
if self._reflected_identity_default is not None:
return self._reflected_identity_default
nested = autogen_context.connection.begin_nested()
try:
name = "alembic_temp_table_%s" % id(self)
meta = MetaData()
Table(name, meta, Column("c", col_type, sqla_compat.Identity()))
meta.create_all(autogen_context.connection)
meta2 = MetaData()
table2 = Table(name, meta2)
sqla_compat._reflect_table(autogen_context.inspector, table2, None)
self._reflected_identity_default = table2.c.c.identity
self._reflected_identity_default.column = None
return self._reflected_identity_default
finally:
nested.rollback()but is very ugly
@zzzeek thoughts
@CaselIT is that ...creating a table to try to detect something ?
i wouldnt do that...:)
nobody is going to appreciate that happening
an alternative is to configure the defaults in the code somewhere, but it's a bit long, since in will depend by the type / direction of the identity
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.