On Feb 12, 9:27 pm, "SteveTether" <[EMAIL PROTECTED]> wrote:
> I checked sess.new after the del and there it was, without my having
> called sess.save() on it. In my application I was after fully explicit
> control of sess.save() operations, applying them only to members of
> the data structure and only (or course) if they were not already
> attached to the session. I'm afraid my over-simplified example didn't
> make my motives clear, sorry.
oh, i thought you knew that part, sorry. with the cascade on, saying
this:
p.children.append(Child("Cheshire"))
is equavlent to session.save(Child("Cheshire")) .
hibernate has no cascade turned on by default, but for SA, we added
cascade in the 0.2 series, and it seems like the overwhelming majority
of users like a general level of cascading at least for save()
operations, so its on by default. but just send cascade="none" to
turn it all off, then all is explicit.
>
> The "delete" cascade does not apply since I never called
> sess.delete(). It's "delete-orphan" that applies here and I can avoid
> the problem with it by removing "all" from the cascade options.
OK again, the "delete" cascade is what i thought you were *expecting*
to apply, when you then said:
del p.children[3]
since if that child object were persistent, that would result in a
delete() operation at flush time. but its pending (sorry i mixed up
transient/pending), so nothing happens to it (stays in the session
from the previously cascaded save())
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
