Thanks for the quick response.
Looking forward to the refactoring :)
Stephen Emslie
On 10/9/07, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
> On Oct 9, 2007, at 10:18 AM, stephen emslie wrote:
>
> >
> > Hi. I've been quiet on this for a while. I'm getting by without this
> > behavior, though it would be nice to get a bit of clarity.
> >
> > Just to refresh, I've got an implementation very similar to the
> > adjacency list example. Michael has helped me to eager load a subset
> > of a node's children with a call to from_statement and contains_eager,
> > however I got ambitious and wanted to get the same behavior for
> > grandchildren, etc. and I discovered that dotted relations like
> > contains_eager('children.children', alias=alias) don't seem to work
> > too well with self-referential mappers
> >
> > (the alias of the last contains_eager statement to be issued ends up
> > as the only 'children' relation in the result)
> >
> > Any idea whether this is a bug or expected behavior? I could try to
> > rustle up a test script if it would help.
>
> without even looking, id classify the behavior youre getting as
> "both". i.e. its something that should be improved and also probably
> whats expected for now.
>
> I have an architectural plan to change the way query.options() are
> targeted towards mapperproperties, i.e. via a full path instead of
> identity (right now, the single "children" MapperProperty is targeted
> with "contains_eager" across the board. it would have to be smarter
> to understand that its only targeted with "contains_eager" when the
> load operation hits the path "children.children").
>
> Theres some other eagerload options behaviors which are ticketed in
> trac which would also be addresed by this (someone trying to do A->B-
> >C->B->A eagerloading...similar idea).
>
> the timeline for this refactoring is somewhere beyond the first
> release of 0.4 final which is hopefully by next week.
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
