On 7/3/14, 1:01 PM, Paul Molodowitch wrote: > > > That makes sense... but if if it really means nothing, and we > shouldn't be looking at it, then why keep it's attributes around at all? because it is an additional step to actually erase the attributes and just hadn't been considered.
> Particularly since sqlalchemy has already established that it's > willing to expire dict members when they may not be valid anymore - > ie, what it does to clear any "cached" values from a row proxy after > the session is committed. well it doesn't expire the deleted object right now because it's been evicted from the Session by the time the commit goes to expire things. Changing that behavior now would definitely bite a lot of people who depend on how it is right now (other people who are also looking at their deleted objects against my recommendations... :) ) > > Of course, you could make the case that other pieces of the program > may want to inspect the data that was on there, after the fact... > maybe you're going to print out something that says, "RIP Steggy", or > something - but in that case, the one field that really DOESN'T make > any sense in this case (and it seems like it would be a common > pattern!) is the one that exists solely as a means to look it up in > the database, it's auto-incremented id column. Which is what prompted > this question... well all the cols don't exist anymore, not just the primary key. the inspect(obj).deleted call does allow this information (that the object was deleted) to be known, though not very transparently. > from sqlalchemy import inspect > def exists(session, obj): > state = inspect(obj) > return session.query(state.mapper).get(state.identity) is None > > print exists(sess, a1) > > > Hmm... very interesting. I'll have to read up what what exactly this > is doing (ie, what is state.identity?)... it's documented here: http://docs.sqlalchemy.org/en/rel_0_9/orm/internals.html?highlight=instancestate#sqlalchemy.orm.state.InstanceState.identity > > from sqlalchemy import inspect, UniqueConstraint > def exists(session, obj): > state = inspect(obj) > table = state.mapper.local_table > for const in table.constraints: > if isinstance(const, UniqueConstraint): > crit = and_(*[col == getattr(obj, col.key) for col in > const]) > return session.query(state.mapper).filter(crit).count() > 0 > else: > return False > > > Yep, it looks like that's doing basically what I was thinking of. Thanks! > > the unique constraints are a set though. not necessarily > deterministic which one it would locate first. I'd use more of > some kind of declared system on the class: > > > Not clear on why this matters - if we're iterating through all the > constraints, and returning True if any of them is matched, what > difference does it make which one is evaluated first? Except > potentially from a performance standpoint, I suppose... what if there are two constraints, and only one is satisfied for a given object's values (e.g. the constraint is now satisfied by some other row), the other one is not present. Is the answer True or False? -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
