[sqlalchemy] Re: Get list of items to be flushed in session extension

2010-05-04 Thread chris e
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.



Re: [sqlalchemy] Re: Get list of items to be flushed in session extension

2010-05-04 Thread Michael Bayer

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 at 
 http://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.