Michael Bayer wrote:
>
> 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).
pure textual paths are going same (old) way; it needs some
extra-"syntax"/API for multilevel descriptor-specified eagers; e.g
eagerload( (B.foo, 'bar', C.bat ) )
> 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.
yeahhh i know i dont see the wider sql picture...
i may put all this as a ticket to remind.. maybe one day you'll be in better
mood (;-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
