Thanks a lot for the tips on how to approach this problem. That's
exactly what I needed.
in 0.4 you'd get it off the impl (0.5 too, this is just uglier API):
Excellent! Here's what I came up with as an initial solution:
def poly_load(parent, collection, path):
def itersiblings(parent,
millerdev wrote:
Thanks a lot for the tips on how to approach this problem. That's
exactly what I needed.
in 0.4 you'd get it off the impl (0.5 too, this is just uglier API):
Excellent! Here's what I came up with as an initial solution:
def poly_load(parent, collection, path):
def
On Jun 18, 2009, at 11:09 AM, Daniel wrote:
Hi list!
It's been a long time since I've posted here. SA is still the best
Python ORM; thanks for all your hard work Mike!
Now, the question. I've got a set of related entities:
Order (has items)
Item (has attributes)
Attribute
I am
I dont really understand the case here.
My first example wasn't very good. In an attempt to keep it simple I
actually made it too simple. Here's another example:
Order (has items)
Item (has attributes, has tags)
Attribute
Tag
If I set both Item.attributes and Item.tags to eager-load, then my
Clarification:
If I set both Item.attributes and Item.tags to eager-load, then my
result set size is the product of len(attributes) * len(tags), which
is where the result set becomes HUGE.
I jumped right from the eager-load to the completely non-optimized (no
eager loading) scenario:
This
On Jun 18, 2009, at 2:19 PM, millerdev wrote:
This would be done by the loader strategy (probably a variant of
LazyLoader), which would issue a single query. The result of that
query would be used to populate the attributes collection of each item
on the order.
hey Daniel -
Good to have
So this is some variant of, i have a bunch of objects and I'd like to
...
snip lots of reasons why this should not be a standard feature
Yeah, I understand what I'm asking for here, and I would never expect
this kind of optimization to kick in by default. Instead, it would
only be used in
