Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 18:12
    jshprentz labeled #6313
  • 18:12
    jshprentz opened #6313
  • 17:31

    sqlalchemy-bot on master

    Fixed ``instrument_declarative`… Merge "Fixed ``instrument_decla… (compare)

  • 17:31
    sqlalchemy-bot closed #6291
  • 17:25
    sqlalchemy-bot closed #6256
  • 17:25

    sqlalchemy-bot on master

    Don't stringify unnamed column … Merge "Don't stringify unnamed … (compare)

  • 17:23
    sqlalchemy-bot closed #829
  • 17:23

    sqlalchemy-bot on master

    Ensure proxy transaction still … Merge "Ensure proxy transaction… (compare)

  • 17:23

    sqlalchemy-bot on master

    next release is 1.6.0 The chan… (compare)

  • 16:55
    zzzeek labeled #829
  • 16:55
    zzzeek labeled #829
  • 16:55
    zzzeek unlabeled #829
  • 16:55
    zzzeek labeled #829
  • 16:36
    CaselIT unlabeled #6307
  • 16:36
    CaselIT labeled #6307
  • 16:34
    CaselIT labeled #6309
  • 16:34
    CaselIT labeled #6309
  • 16:34
    CaselIT unlabeled #6309
  • 16:32
    CaselIT closed #6310
  • 16:31
    CaselIT locked #6311
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")
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
Federico Caselli
@CaselIT
We can add that to the list :)
Federico Caselli
@CaselIT
ok I'm making progress in the identity stuff. mostly tests left
Jonathan Vanasco
@jvanasco
@CaselIT is there a public api in sqlalchemy that shows what a column is reflected as (all the attributes) or is that code deeply nested in the logic that maps the output to a class/object?
Federico Caselli
@CaselIT
This returns a lost of dicts, that is used by reflect_table
Jonathan Vanasco
@jvanasco
Thanks. I am thinking of generating a file that shows what creating columns with Identity() and Identity(increment=2) reflects as - under each database
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
Federico Caselli
@CaselIT
+1
That would he useful
Jonathan Vanasco
@jvanasco
If we catch this in the CI tests when a database version updates, then we either update the dataset the tests check against... or have a fix released before anyone files a bug report.
mike bayer
@zzzeek
@CaselIT we have found our first bug because of the asyncpg "fallback" mode :)
e.g. a bug I missed due to it
Federico Caselli
@CaselIT
Well that was a typo. I still think it's worth having the ability to run the ci in non-fallback mode. I'll try to take another look at the gerrit after the identity saga ends to see of we can simply it a bit.
Jonathan Vanasco
@jvanasco
found a 1.4 docs issue!