> >
> > 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
in most complex cases things like this end up being a class,
with "generic logic 1", instantiation, "generic logic 2", etc pieces
being methods called in one "procedure/algorithm", and whoever wants
to screw up say the instantiation, subclass that and do whatever.
this allows one to literaly assemble functions from pieces without
losing the whole idea into awful details.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
