On May 26, 2011, at 2:34 AM, Torsten Landschoff wrote: > Hi Michael et al, > > basic question: Can I call identity_key in after_commit? If not, are there > any alternatives?
absolutely. identity_key is strictly informational with regards to the state present on the target object. > To move the list of affected objects to another thread, I use the > identity_key function to retrieve the primary keys. On the target > thread, I use that information to reload ORM instances which are > affected. I would take care not to access any attributes on a session-attached object in a different thread than the originating thread of that Session (which identity_key() does). This would constitute sharing of the Session's functionality across threads which is not threadsafe. > > However, while doing an unrelated change today, this broke down with the > following backtrace. I can not make sense out of this: after_commit > should only be called after a commit I would think (not after a rollback > as the error message seems to indicate). The stacktrace doesn't reveal the source of the issue as the source of the Session.commit() call is not shown. after_commit() is only called as a direct result of Session.commit(), or in the case that you're using a Session in "autocommit" mode (to which I would advise, don't) it would be called in the scope of flush(). But only if the flush() succeeded - otherwise the exception is propagated before commit() is reached. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
