On 12/27/2011 2:34 PM, Michael Bayer wrote:
On Dec 27, 2011, at 1:51 PM, Kent wrote:
In http://www.sqlalchemy.org/trac/changeset/7025%3A0a6576abea5b#file1
you added a warning that I'm hitting now.
'when "save-update" cascade is disabled, or the target object is
otherwise not
present in the session, and collection/scalar changes have taken
place. A warning
is emitted describing the type of operation, the target reference, and
the relationship
description, stating that the operation will not take place.'
Do you think it is appropriate to skip the warning if the object isn't
in the session *and* the "save-update" cascade is disabled?
With *both* conditions present, it would seem the user has arranged
them as such intentionally (at least in my case).
It basically means it's doing a flush and outright ignoring an object that
you've assigned to a collection or scalar. I don't know that the UOW should
ever break it's behavioral contract that badly and not at least say something.
Either that or they
messed up twice (I suppose that is the more conservative approach,
huh?)
The save-update cascade is often disabled so that someone can have control over
when an object gets placed into the session. In that case they want to still
be adding objects in manually, so actually when save-update is turned off is
when the warning does actually become very important.
Possibly consider a different warning for that case? I like the idea
of raising this warning, but only if one or the other conditions
exist, but not both.
so you're not only working with detached objects, getting them to load things
despite their being detached, which I've maintained is not how the ORM was
intended to be used, now you're also trying to mix and match them with
collections that are being flushed ? Can I get a reminder what the use case
here is again ? I hope this isn't all just for performance....
Haha! I sense you're getting irritated, Mike! It's got little to do
with performance... it's more a serialization artifact. To keep our web
server truly stateless (well, 99.9% stateless), our objects are stored
in memory client side until the user clicks save, then they are
serialized and sent to python, deserialized, turned into transient sa
objects and merged into the session. There are certain objects that
aren't placed in the session because they aren't in the merge cascade
(purposefully). These are transient objects.... I think that's where
I'm hitting this warning.
It's been working quite well for about a year since we've been live.
We've a lot of work to do (oracle 8 and all), and sqlalchemy is
beautiful toolset to make it work. It's a toolset to build an orm,
right? Not necessarily an orm out of the box to fit every need. So
don't be offended when I hack at it a bit (trust me, I try to work
within the public API as it was intended to be used, and I'm the only
one in the company who it goes against my grain to hack... the other
guys would have trashed it by now! I'm the one on your side, believe it
or not! ;)
I don't mind if you don't want to change the warnings, just wanted your
input whether it made sense.
--
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.
