SAWarning: Object of type <Discount> not in session, add operation along 'OrderDetailDiscount.discount' won't proceed
Kent
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). Either that or they
messed up twice (I suppose that is the more conservative approach,
huh?)
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.
Michael Bayer
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....
Kent
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.
Michael Bayer
On Dec 27, 2011, at 3:33 PM, Kent wrote:
> Haha! I sense you're getting irritated, Mike!
oops...that should never show...
> 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.
do you need the transient objects to be present in collections/attributes owned by pending/persistent objects ?
> It's a toolset to build an orm, right?
OK, yes. If you're building on .orm and not just the core, you get a certain behavioral model that you're building on top of. The behavioral model is built around everything being in a Session, with a transaction going on, and if its not in a Session that means it's essentially in transit from one Session to another. That seems like mostly what you're doing here.
> 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! ;)
yes absolutely ! I'm just stressed when challenged to make small modifications without really understanding the bigger need.
>
> I don't mind if you don't want to change the warnings, just wanted your input whether it made sense.
based on the current model it makes sense. A "partially detached" model that knows not to warn in some cases would require a lot more thought.