Finally had time to look into my code, and track down why ordering was important. In my before_flush code, I'm doing a status rollup for an approval process. Essentially I have a request, and several child approval objects. When the status of an approval object changes, it may, depending on it's status, make changes to the parent request object. When this occurs, he parent request object will send out an email letting the person who made the request know that the status of the request has changed. For this to work properly, the child approval objects have to be processed before the parent request object. I could potentially re-write the code so that all the status change logic is only on the parent request, but I was trying to share the logic between the two objects.
On May 4, 8:49 pm, Michael Bayer <mike...@zzzcomputing.com> wrote: > On May 4, 2010, at 7:42 PM, chris e wrote: > > > 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. > > yeah what I dont understand is why the "order" of things persisted matters > when you're inside of before_flush(). the only thing that the sorting > inside flush determines, which has a visible effect on the ultimate outcome, > is the order of INSERT for a series of rows in a table. this is derived > from the order in which things were add()ed to the session, and is available > ahead of time off the instance_state. The only time this behavior might be > more complex is if one or more of the rows of one table are dependent on > other rows in that table. everything else about the "order" of things > occuring has to do with "insert into table B before table A" and so forth, > nothing you need to know if you arent issuing INSERT statements yourself > within before_flush(). > > > > > > > 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 > > 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 > 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.
