I think I understand why, during a flush(), if I use
session.query().get() for an item that was just added during this flush,
I don't get the persistent object I might expect because the session
still has it as pending even though, logically, it is already persistent.
I don't suppose you have
On Jan 26, 2012, at 11:28 AM, Kent Bower wrote:
I think I understand why, during a flush(), if I use session.query().get()
for an item that was just added during this flush, I don't get the persistent
object I might expect because the session still has it as pending even
though,
Fair enough. I had enough understanding of what must be going on to
know flush isn't straightforward, but I'm still glad I asked. Sorry for
having not read the documents very well and thanks for your answer,
because from it, I surmise that before_flush() *is* safe for session
operations,
yup, before_flush is made for that, and I've for some time had some vague plans
to add some more helpers there so you could get events local to certain kinds
of objects in certain kinds of states, meaning it would look a lot like
before_update. But looping through .new, .dirty, and .deleted
So, as a typical example of where it seems very natural to use
before_update, suppose you need to automatically update the not null
sequence of a related table. This but to get the sequence you need to
loop over the parent table's collection.
You want the sequence to be human friendly
On Jan 26, 2012, at 1:21 PM, Kent wrote:
So, as a typical example of where it seems very natural to use
before_update, suppose you need to automatically update the not null
sequence of a related table. This but to get the sequence you need to loop
over the parent table's collection.
