On Aug 30, 2012, at 11:12 AM, Tony Moutaux wrote: > > > 2.if "some computation" involves SQL functions: > > a. emit your modifications to B using only SQL statements and > Session.execute(), not by adding any new state to the Session or re-flushing. > > b. pre-execute your SQL functions for A *outside* of the flush, then > apply values to B as needed. > > c. use a second Session inside the event: > > def after_flush(session, flush_context): > my_bs = figure_out_bs(session) > new_session = Session(bind=session.connection()) > new_session.add_all(my_bs) > > # this won't actually COMMIT the transaction as we are > # already inside one > new_session.commit() > > I can read this, but I don't understand how to do this and not exactly how it > works. It is 3 solutions right , not 3 points I have to go through ?
three different ways to do it. > > Step A : calling only Session.execute will output direct SQL commands, thus > not modify the Session dirty list and the state. > Seems quiet easy but less readable because of the direct SQL commands. right, but is the most efficient and simple, if the changes you're emitting are also simple. > > Step B : what *outside* of the flush means ? This option doesn't apply here, as you aren't dependent on SQL functions. "outside the flush" means, when you have your A and B and haven't called flush() yet. -- 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 sqlalchemy+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
