On Sunday 13 July 2008 21:46:24 Kyle Schaffrick wrote:
> On Sun, 13 Jul 2008 19:02:03 +0300
>
> [EMAIL PROTECTED] wrote:
> > > I assume that it would be possible to do it after the Query is
> > > gone, at least in theory, since lazy-loaded attributes are able
> > > to trigger eager-loads on attributes of their instances, even
> > > after the Query is gone. So in essence I am trying to figure
> > > out if it's possible to add the eagerload to an instance
> > > after-the-fact.
> >
> > i'm trying to understand what exactly u want...
> > do u want (for an a.b.c.d chain) to query on a (with b being
> > lazy), then _later_ tell b.c.d to be eagerloaded and then
> > lazyload b? i.e. some sort of options-of-relation-loading like
> > those of-query-loading? taking a relation closer to a query in a
> > way? like a temporary/dynamic version of current
> > mapper/relation-options of sorts.
>
> Yeah, exactly. IOW, I would like to get the exact same behavior as
> doing this:
>
> a = sess.query(A).options(eagerload('c')).first()
> foo = a.b # triggers eagerload of c
>
> A handful of the codepaths where I'm querying for the objects are
> generic functions that service queries for many different classes
> for other parts of the app; the gist of all of them is this:
>
> def generic_query_pattern(sess, class_, pk):
> # ..generic logic I wish to reuse..
> instance = sess.query(class_).get(pk)
> # ..more generic logic involving instance..
> return instance
>
> Adding logic for the eagerload there would be my absolute last
> ditch solution since it would be so messy and defeat the "generic"
> part. Hence why I'm wondering if it's possible to do it by only
> accessing the instance "a":
>
> a = generic_query_pattern(sess, A, a_key)
> # Do something here, so that a pattern like this..
> abcs = [ each_b.c for each_b in a.b ]
> # ..isn't O(n) queries
>
> Or, since I'm being more concrete now, if there is some other way
> to architect generic_query_pattern such that I can accomplish this,
> I'm open to that too.
>
ah,..
double-dispatch of sorts?
where/when is the knowledge of what should be eagerloaded?
split the whole-obj-commune structure by that party and give it as
argument...
or, in other words, turn the tables: dont give class/pk/whatever to
generic_func, give generic_func to something that knows better the
context of object's usage.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
