Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 20:15
    zzzeek edited #6003
  • 20:15
    zzzeek milestoned #6003
  • 20:15
    zzzeek labeled #6003
  • 20:15
    zzzeek labeled #6003
  • 20:15
    zzzeek labeled #6003
  • 20:15
    zzzeek unlabeled #6003
  • 20:15
    zzzeek unlabeled #6003
  • 20:15
    zzzeek unlabeled #6003
  • 19:23
    CaselIT review_requested #814
  • 19:23
    CaselIT review_requested #814
  • 19:12
    scnerd edited #6003
  • 18:46
    zzzeek labeled #6003
  • 18:46
    zzzeek labeled #6003
  • 18:46
    zzzeek unlabeled #6003
  • 18:46
    zzzeek labeled #6003
  • 17:46

    sqlalchemy-bot on master

    reduce confusion over "one choi… (compare)

  • 17:33
    zzzeek milestoned #6004
  • 17:33
    zzzeek labeled #6004
  • 17:33
    zzzeek opened #6004
  • 17:33
    zzzeek labeled #6004
Jonathan Vanasco
@jvanasco
They are very similar to Yams, if you have had those.
Federico Caselli
@CaselIT
can't say I'm familiar with those either
Federico Caselli
@CaselIT

@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)
Jonathan Vanasco
@jvanasco
What if the default values are singletons with str and not strings themselves?
Federico Caselli
@CaselIT
this is for identity
Jonathan Vanasco
@jvanasco
__str__. Mike uses a pattern like that in dogpile with the novalue
Federico Caselli
@CaselIT
basically the problem is:
if I have a Column('foo', Integer, Identity()) this renders the default, but when reflecting I get back Identity(start=1, increment=1, minvalue=1, maxvalue=2147483647, cycle=False, cache=1)
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.
Jonathan Vanasco
@jvanasco
hm. sorry, i was trying to solve for differentiating if start=1 within Python is from the user or a default
Federico Caselli
@CaselIT
that one works by checking with an empty identity, but if I have the case:
  • user set Identity(increment=2)
  • creates the table
  • remove the increment (is sets Identity())
  • this one does not get reflected
Federico Caselli
@CaselIT

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

mike bayer
@zzzeek
@CaselIT clearly im not following this identity thing nor much else lately
@CaselIT is that ...creating a table to try to detect something ?
i wouldnt do that...:)
nobody is going to appreciate that happening
Federico Caselli
@CaselIT
Indeed it is. I too would not do that. Comparing existing identity is becoming a can of worms. I think I'm going to scale back the ambition and just detect creation / removal of it for the moment. A more intelligent logic can follow at a second time
mike bayer
@zzzeek
@CaselIT +1
Federico Caselli
@CaselIT
will do
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
mike bayer
@zzzeek
I'm not really hearing anything about identity from the userbase yet besides the user that brought up this whole thing in the 1st place so I dont think we have to go too crazy right now :)
as always the gigantic raging fire in alembic is the enum thing :)
never seen such a small area get so many requests for improvement
Federico Caselli
@CaselIT
Ahah. Enum are a bit of a mess also in pg. Like you cannot remove elements from it
mike bayer
@zzzeek
yup
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
Federico Caselli
@CaselIT
Out of curiosity mike, would there a more appropriate way of doing the check that I tried above? I mean other than opening a transaction, creating a table, reflecting it and rolling back?
mike bayer
@zzzeek
I lack the context to know what it is you actually want to do. is it that an Identity on our end has no arguments, and you wish to compare what would be the "default" of that object with the one in the DB ?
Federico Caselli
@CaselIT
Yes
Basically the use case is: user set a parameter, like increment to 2; creates the table; reset the increment to None.
mike bayer
@zzzeek
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
Federico Caselli
@CaselIT
I'm coming to that idea also. As the alternative needs the db side default.
mike bayer
@zzzeek
if I put "Number()" in my model
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)
Federico Caselli
@CaselIT
Ok. I can detect if user changes from increment=2 to increment=1
So I'll limit to that.
mike bayer
@zzzeek
it might be nice to add a new class of warnings that can be enabled for all the places where alembic makes a decision like this
Federico Caselli
@CaselIT
We can add a note somewhere and that's that I guess.
mike bayer
@zzzeek
ideally this would be documented and be positively identified progammatically, im referring mostly to the type comaprison logic but then places like this also
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
Federico Caselli
@CaselIT
I can add a warning of the type "ignoring comparisons of attributes since they are at default"
mike bayer
@zzzeek
@CaselIT yes but I am envisioning a more general API, like .ambiguous_comparison("type", model_obj, reflected_obj, "attribute X Y Z")