On Jan 15, 2008, at 5:17 PM, [EMAIL PROTECTED] wrote:
>>> hmmm, specify explicitly?
>>> e.g. query(A).eagerload( B.address)
>>>
>>> joined-inh via left-outer-join is enough, no need for polymunion.
>
>>> i dont know how the current machinery for eagerload works, but imo
>>> knowing your level of lookahead-design, it should not be hard to
>>> apply that machinery over a polymorphic mapper/query?
>>
>> theres plenty of much higher priority issues than this one in the
>> queue...considering that you can already get the results you want
>> with
>> this one using direct SQL.....
>
> right..
>
> i've hacked something that seems to work; It's about 20 lines split in
> orm.query and orm.interfaces:
> - such special eagerloaders are requested as
> query.eagerload( B.address) -
> and not just the name/path
> - query-compile calling context.exec_withpath(...) iterates over all
> self.mapper properties (not only select_mapper's), plus all
> eagerloaders of
> above type (i.e. non-names). Thus the 4 cases are covered:
> A has address / query(B).eagerload('address') #works before
> A has address / query(A).eagerload('address') #new - did not work
> before
> B has address / query(B).eagerload('address') #works before
> B has address / query(A).eagerload(B.address) #new - not possible
> before
> (in all these B inherits A via joined inheritance; A is polymorphic
> via
> left-outer-joins)
> i'm absolutely sure that this is not the completely right thing -
> that's
> what i got from the machinery-src in 2 hours - but it is something
> as a
> start... sure it needs correctness tests etc of the sorts.
>
yeah thats the idea but it needs more work than that. for one thing
you might be hitting the same MappedProperty twice using that
iteration (therefore joining twice), and also it doesn't account for
eager loaders like "eagerload("foo.bar.bat")"; i.e. deeper level
properties which would need to have an adjusted "path" sent to them
(or ignored in that part of the iteration).
also i can see a lot of cases where the eager loader from "B" is going
to generate invalid SQL, such as joined table inheritance with no
select_table, the query is only generated against "A". "B.address"
is going to try generating an eager join against the "B" table which
isnt present, and youll get some kind of mess as a result. checking
for this condition beforehand is bound to add lots of complexity and i
only want to add features like these if they can be smoothly
integrated, not lots of extra "if/thens" bolted on.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
