> > 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... :) ) >
Makes sense - maybe it could be a configurable option? Dunno how many people (besides me!) would be interested in such behavior, though... =P > 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 > > Thanks for the link! 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? > In the scenario I was envisioning, True (ie, it exists). Basically, "Would it violate ANY unique constraints if I tried to insert it? Yes". Of course, I see your point: that in some situations, this might not fit conceptually with the answer to the question, "Does THIS object exist in the database?" But I guess that's likely your point... that there isn't really a good "universal" way to answer that question. -- 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 sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
