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 -~----------~----~----~----~------~----~------~--~---