Hi Michael,
On Thu, 2011-05-26 at 09:52 -0400, Michael Bayer wrote:
> > 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.
In that case I don't grok the backtrace I posted. It seems like
retrieving the identity key triggers _load_scalar_attributes on the
mapper in my case.
> > 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.
identity_key() is only called in the original thread. Only the return
value of identity_key is sent to the other thread (via a Queue if that
matters).
> > 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
How much more context would be helpful? Basically, this is the top of
the backtrace. Above of that call is only the event handler hierarchy.
File "/home/torsten/workspace/loco2-git/loco2/ui/wizard/importwizard.py",
line 69, in do_component_import
session.commit()
File
"/usr/local/lib/python2.6/dist-packages/SQLAlchemy-0.6.7dev-py2.6.egg/sqlalchemy/orm/session.py",
line 614, in commit
self.transaction.commit()
File
"/usr/local/lib/python2.6/dist-packages/SQLAlchemy-0.6.7dev-py2.6.egg/sqlalchemy/orm/session.py",
line 392, in commit
ext.after_commit(self.session)
> 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.
I am actually using autocommit=True and autoflush=False. The reason is
that autoflush=True caused a bunch of errors as I load hierarchical data
in bottom up fashion and SQLAlchemy tried to flush objects to the
database before a parent was available.
What's so bad about autocommit=True? I don't really remember why I ended
up using it. It would probably suffice to replace most flush() calls
with commit() and be done with it.
BTW: The error is not reproducible anymore.
Greetings, Torsten
--
DYNAmore Gesellschaft fuer Ingenieurdienstleistungen mbH
Torsten Landschoff
Office Dresden
Tel: +49-(0)351-4519587
Fax: +49-(0)351-4519561
mailto:[email protected]
http://www.dynamore.de
Registration court: Mannheim, HRB: 109659, based in Karlsruhe,
Managing director: Prof. Dr. K. Schweizerhof, Dipl.-Math. U. Franz
--
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.
