On Apr 29, 2008, at 5:55 PM, David Bonner wrote:
Hi, I'm trying to write a mapper extension that notifies a daemon
about changes made to the DB that it needs to care about. But it
looks like after_update() is actually getting called before the UPDATE
is sent to the db.
Not knowing a
then queried the db *directly using sql*. It looks like the change
hasn't made it to the DB yet
Also possible is that you're using a an MVCC DB such as Postgres or Oracle,
and you're looking at an old, pre-update version of the data, as your direct
SQL would be in a separate transaction
On Wed, Apr 30, 2008 at 10:56 AM, Rick Morrison [EMAIL PROTECTED] wrote:
then queried the db directly using sql. It looks like the change
hasn't made it to the DB yet
Also possible is that you're using a an MVCC DB such as Postgres or Oracle,
and you're looking at an old, pre-update
On Wed, Apr 30, 2008 at 9:29 AM, Michael Bayer [EMAIL PROTECTED] wrote:
after_update() is called after all UPDATE statements have been issued
for that particular mapper. This includes *only* the table that is
mapped by that mapper, not any other mappers.
Is it possible that you are
I suppose that depends on the behavior of the DB-API interface, in this case
I guess that's psycopg.
Anyway, I'm certainly not sure if an MVCC snapshot that's causing your
problem, but it does seem like at least a possibility. The certain way is to
check the update status inside the same
oops, uncommenting the pdb.set_trace(), obviously. sorry.
class MyExtension (MapperExtension) :
def after_update (self, mapper, connection, instance) :
#pdb.set_trace()
pprint.pprint(instance)
return EXT_CONTINUE
--
david bonner
[EMAIL PROTECTED]
On Apr 30, 2008, at 11:22 AM, David Bonner wrote:
When this code drops me into pdb, the data in instance.notes looks
like the new value, but querying the db in a separate process gets me
the old value.
flush() always uses a transaction, so when your pdb process hits, the
transaction has
On Wed, Apr 30, 2008 at 11:30 AM, Michael Bayer
[EMAIL PROTECTED] wrote:
flush() always uses a transaction, so when your pdb process hits, the
transaction has not been committed yet and results are not visible
outside of the transaction. the transactional keyword on Session
does not mean
On Apr 30, 2008, at 12:15 PM, David Bonner wrote:
On Wed, Apr 30, 2008 at 11:30 AM, Michael Bayer
[EMAIL PROTECTED] wrote:
flush() always uses a transaction, so when your pdb process hits, the
transaction has not been committed yet and results are not visible
outside of the transaction.
On Wed, Apr 30, 2008 at 2:50 PM, Michael Bayer [EMAIL PROTECTED] wrote:
if you want pre/post flush activities theres a SessionExtension which
hooks into Session for that. You can set it up with the
sessionmaker() function so that its always plugged in.
thanks, i'll look into that.
and
10 matches
Mail list logo
