15 messages in com.googlegroups.sqlalchemy[sqlalchemy] Re: Setting up eager loa...| From | Sent On | Attachments |
|---|---|---|
| Kyle Schaffrick | 12 Jul 2008 10:56 | |
| az...@svilendobrev.com | 12 Jul 2008 12:01 | |
| Rick Morrison | 12 Jul 2008 13:01 | |
| az...@svilendobrev.com | 12 Jul 2008 13:12 | |
| Michael Bayer | 12 Jul 2008 19:49 | |
| Michael Bayer | 12 Jul 2008 19:58 | |
| Kyle Schaffrick | 12 Jul 2008 21:18 | |
| Kyle Schaffrick | 12 Jul 2008 21:53 | |
| Kyle Schaffrick | 12 Jul 2008 22:14 | |
| az...@svilendobrev.com | 13 Jul 2008 09:01 | |
| Kyle Schaffrick | 13 Jul 2008 11:46 | |
| az...@svilendobrev.com | 13 Jul 2008 12:18 | |
| az...@svilendobrev.com | 13 Jul 2008 12:23 | |
| az...@svilendobrev.com | 13 Jul 2008 12:41 | |
| Michael Bayer | 13 Jul 2008 17:40 |
| Subject: | [sqlalchemy] Re: Setting up eager loading after query runs![]() |
|---|---|
| From: | az...@svilendobrev.com (az...@svilendobrev.com) |
| Date: | 07/13/2008 12:23:37 PM |
| List: | com.googlegroups.sqlalchemy |
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 sqla...@googlegroups.com
To unsubscribe from this group, send email to
sqla...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---




