use before_flush() for changes to the "dirty" list and such....or if you really want things set up for the *next* flush, use after_flush_postexec().
On Aug 30, 2008, at 10:08 AM, GustaV wrote: > > It almost works. > A small problem though : when I get and modify instances (a priori not > loaded before the flush) in after_flush method, they are correctly > added in the dirty list of the session but the 2nd flush does nothing. > This is because the identity_map is still flagged as 'not modified' > > On 29 août, 18:32, Michael Bayer <[EMAIL PROTECTED]> wrote: >> in r5069, "extension" can be a list of SessionExtension objects. You >> can also append to session.extensions. >> >> On Aug 29, 2008, at 11:36 AM, GustaV wrote: >> >> >> >>> You must be right. >>> Of course, Turbogears2 already add an extension to the session, >>> and it >>> looks like it is not a list of extension anyway (or maybe in the >>> latest trunk?). >>> What the best way then? To subclass the tg2 extension with mine and >>> continue to call overloaded method from mine? Anything better? >> >>> On Aug 29, 3:57 am, Michael Bayer <[EMAIL PROTECTED]> wrote: >>>> On Aug 28, 2008, at 6:57 PM, GustaV wrote: >> >>>>> Hi all. >>>>> I'm currently working on a map (like in geography :) ) >> >>>>> When a new tile in inserted in the DB, I'm using an extension >>>>> mapper >>>>> to update some neighbor's properties (like the neighbors count). >>>>> The >>>>> after_insert method helps a lot... but: >>>>> When I modify another object than the one being inserted in the >>>>> after_insert method, the modification happens in the python >>>>> object, >>>>> but doesn't occur is the DB. The commit at the end does not seem >>>>> to >>>>> have an effect. >> >>>>> What should I do? >> >>>> modifications to objects inside of flush() aren't going to >>>> propigate >>>> the same way as when they're outside of the flush(). Within >>>> MapperExtension you should generally just do things with the >>>> connection (i.e., issue SQL directly). >> >>>> Otherwise, we have SessionExtension which has a before_flush() >>>> hook, >>>> and you can poke around inside the Session and change things freely >>>> before anything flush()-related occurs. The catch there is that >>>> you'd >>>> probably want to be using the latest 0.5 trunk for that (post >>>> beta3) >>>> since we've fixed it up a bit to work in a more useful way. I >>>> find >>>> that using before_flush() and after_flush() is generally a better >>>> way >>>> to go for dependent changes/SQL to be issued since you aren't doing >>>> things inside of the flush() itself, where its hard to predict when >>>> things will actually happen. > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
