I'm wondering if you think my use case is one you would like to
support, or if you think it is sort of off on its own (I could tell I
wasn't explaining our use case extremely well)...
Regardless, I am setting the InstrumentedAttribute's implementation's
"callable_" so I have control over whether to load related objects on
transient/pending objects.
But the framework doesn't exactly support this in some of its
assumptions about the callable_.
For example, for Collections, it doesn't send "passive=PASSIVE_NO_FETCH"
during a set() when it looks for the "old" value:
old = self.get(state, dict_)
whereas, for ScalarObjectAttributeImpl(), the set() method passes
passive=PASSIVE_NO_FETCH unless active_history is True.
def set(self, state, dict_, value, initiator, passive=PASSIVE_OFF):
"""Set a value on the given InstanceState.
`initiator` is the ``InstrumentedAttribute`` that initiated the
``set()`` operation and is used to control the depth of a circular
setter operation.
"""
if initiator is self:
return
if self.active_history:
old = self.get(state, dict_)
else:
old = self.get(state, dict_, passive=PASSIVE_NO_FETCH)
value = self.fire_replace_event(state, dict_, value, old,
initiator)
dict_[self.key] = value
Is it appropriate to implement "active_history" on collections and pass
passive?
I can work around this somehow if you don't wish to make that change...,
but let me know.
On 9/8/2010 3:34 PM, Kent Bower wrote:
I've got a recipe for what will work well for us. I imagine it could
be useful for others, although I left out the actual serialization
mechanism, since that will likely be very project specific.
I'd be happy to put this on the wiki, but if you wanted to look it
over first, you are more than welcome (I'd prefer your feedback). If
you are busy, I can just post it and hope someone may find it useful.
Thank again for your help,
Kent
On 9/7/2010 7:28 PM, Michael Bayer wrote:
On Sep 7, 2010, at 6:41 PM, Kent Bower wrote:
Two items:
* How does the orm currently determine whether it is safe to try
get() (e.i. there are no "funny join conditions")? If you point me
to the function where decision takes place, I can probably answer
this myself....
it compares the join condition of the relationship() to that of the
clause which the Mapper uses when it issues get(), then stores that
away as a flag for future consultation. It's very unusual for a
many-to-one relationship to be based on something other than a simple
foreign-key->primary key relationship, though.
* When I build up the primary key from the foreign key, is there an
efficient way to build a composite key in the correct order to pass
to get()? (I thought maybe "synchronize_pairs", but that maybe has
to do with getting the direction consistent instead?)
Well if you aren't using any composite primary keys in many-to-ones,
you wouldn't even have to worry about this. Otherwise, the two
collections to correlate would be property.local_remote_pairs and
property.mapper.primary_key. Perhaps make a dictionary out of
dict([(r, l) for l, r in prop.local_remote_pairs]) and your PK value
would be [getattr(instance,
prop.parent.get_property_by_column(mydict[p]).key) for p in
property.mapper.primary_key].
Or if you want to get ambitious you can just copy roughly whats in
strategies.py on line 605 but then you're digging into
internals....and looking at that now I'm wondering if
strategy._equated_columns is really different than local_remote_pairs
at all...
Thanks again, you've been much help!
On 9/7/2010 5:03 PM, Michael Bayer wrote:
On Sep 7, 2010, at 4:38 PM, Kent Bower wrote:
Don't want to strangle me, but when the orm (lazy)loads a MANYTONE
object, it doesn't go to the database if the object is in the
session. Can I get "with_parent()" to behave this way, or would I
need to specifically build up the primary key of the related
object and call query.get()?
the latter. You can use get() for all many to ones if you aren't
using any funny join conditions.
On 9/7/2010 10:25 AM, Michael Bayer wrote:
On Sep 7, 2010, at 10:12 AM, Kent Bower wrote:
Mike, in your proof of concept, when __getstate__ detected
transient, why did you need to make a copy of self.__dict__?
"self.__dict__.copy()"
i was modifying the __dict__ from what would be expected in a
non-serialized object, so that was to leave the original object
being serialized unchanged.
On 9/6/2010 2:35 PM, Michael Bayer wrote:
On Sep 6, 2010, at 2:11 PM, Kent Bower wrote:
Also, I was hoping you would tell me whether this would be a candidate for
subclassing InstrumentedAttribute? Would that make more sense or providing custom
__getstate__& __setstate__ ?
__getstate__ / __setstate__ are pretty much what I like to use for pickle
stuff, unless some exotic situation makes me have to use __reduce__. One
problem with the recipe is that theres no 'deferred' loading of attributes.
So in that sense playing with InstrumentedAttribute would give you a chance to
put a callable in there that does what you want.
There is also the possibility that __setstate__ can load up callables into the
instance_state using state.set_callable(). This is a callable that triggers
when you access the attribute that is otherwise None. There's a little bit of
fanfare required to get that callable to assign to the attribute in the right
way. Attached is an example of that. This is all a little more shaky since
the state/callable API isn't really public. Hasn't changed for awhile but
there's no guarantee.
Thanks for your help, hopefully I'll be able to contribute such a recipe.
Kent
Since sqla won't load that for me in the case of transient, I need to load the
relation manually (unless you feel like enhancing that as well).
its not an enhancement - it was a broken behavior that was specifically
removed. The transient object has no session, so therefore no SQL can be
emitted - there's no context established.
Now I can manually emulate the obj being persistent with your changes for
On Sep 6, 2010, at 10:58 AM, Michael Bayer<mike...@zzzcomputing.com> wrote:
On Sep 6, 2010, at 9:06 AM, Kent wrote:
with_parent seems to add a join condition.
OK, so I guess you read the docs which is why you thought it joined and why you didn't
realize it doesn't work for transient. r20b6ce05f194 changes all that so that
with_parent() accepts transient objects and will do the "look at the
attributes" thing. The docs are updated as this method does use the lazy loader
SQL mechanism, not a join.
Is there a way to get at
the query object that would be rendered from a lazy load (or what
"subqueryload" would render on the subsequent load), but on a
transient object, if i supply the session?
even though not "recommended", can it make sqla believe my transient
object is detached by setting its state key?
There are reasons i do not want to add this to the session and
disabling autoflush would also cause problems.
On Sep 3, 9:58 am, Michael Bayer<mike...@zzzcomputing.com> wrote:
On Sep 3, 2010, at 9:36 AM, Kent wrote:
For the case of customerid = '7', that is a simple problem, but when
it is a more complex join condition, we only wanted to define this
condition in one single place in our application (namely, the orm).
That way, if or when that changes, developers don't need to search for
other places in the app that needed to manually duplicate the logic of
the orm join condition.
If I supplied the DBSession to sqla, it would know how to create the
proper Query object for this lazyload. Can you point me in the right
direction (even if where you point me is not currently part of the
public API)?
Query has the with_parent() method for this use case.
Thanks again,
Kent
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email tosqlalch...@googlegroups.com.
To unsubscribe from this group, send email
tosqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this
groupathttp://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email tosqlalch...@googlegroups.com.
To unsubscribe from this group, send email
tosqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email tosqlalch...@googlegroups.com.
To unsubscribe from this group, send email
tosqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email tosqlalch...@googlegroups.com.
To unsubscribe from this group, send email
tosqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email tosqlalch...@googlegroups.com.
To unsubscribe from this group, send email
tosqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email tosqlalch...@googlegroups.com.
To unsubscribe from this group, send email
tosqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/sqlalchemy?hl=en.
--
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
<mailto:sqlalchemy@googlegroups.com>.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
<mailto:sqlalchemy+unsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the
Google Groups "sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
--
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
<mailto:sqlalchemy@googlegroups.com>.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
<mailto:sqlalchemy+unsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google
Groups "sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
--
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
<mailto:sqlalchemy@googlegroups.com>.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com
<mailto:sqlalchemy+unsubscr...@googlegroups.com>.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google
Groups "sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
