I'll look into the new code. It does look simpler. I tried using the MapperExtension functionality, but, the last time I tried to use it, it did not allow for orm level changes(new items added to the session, or attribute changes) to be made, as the UOW has already been calculated. My main use case is business logic where child objects end up updating parent items, or adding items to parent relations. Once the UOW is calculated I have found that changes to items and their relations are not caught, which makes sense.
I'd love to have something in the public session/UOW api that provides the items to be flushed in the order in which they are being flushed, even though this may be an expensive operation. On May 4, 4:17 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > On May 4, 2010, at 5:23 PM, chris e wrote: > > > I'm trying to provide functionality in a session extension for an > > class to provide a 'before_flush' method that allows the class to make > > changes to the session, and add additional items. To do this I need to > > get the list of instances to be flushed to the database, and the order > > in which sqlalchemy would commit the changes to the database. I then > > reverse the order of this list so that items that the instances are > > processed in the reverse order of the database commits. I used to do > > this using some of the internal task functionality of UOW(see below), > > but that is no longer available in 0.6.0. Any suggestions? > > getting the "order" is pretty controversial. what elements of the "order" > are significant to you and why isn't this something you are tracking yourself > ? wiring business logic onto the details of persistence doesn't seem like a > good idea. Or are your flush rules related to SQL -level dependencies, in > which case why not let the flush handle it, or at least use a MapperExtension > so that your hooks are invoked within the order of flush ? > > anyway, the "order" is available in a similar way as before if you peek into > what UOWTransaction.execute() is calling, namely _generate_actions(). It > would be necessary for you to call this separately yourself which is fairly > wasteful from a performance standpoint. it returns a structure that is > significantly simpler than the old one but you'll still have to poke around > unitofwork.py to get a feel for it, since this isn't any kind of documented > public API (you obviously figured out the previous one, this one is simpler). > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To post to this group, send email to sqlalch...@googlegroups.com. > To unsubscribe from this group, send email to > sqlalchemy+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/sqlalchemy?hl=en. -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalch...@googlegroups.com. To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
