On Mar 27, 2007, at 2:08 AM, chris e wrote:
>
> Currently when sqlalchemy performs a polymorphic lookup, it queries
> against all the detail tables, and returns the correct Python object
> represented by the polymorphic identity. Essentially you get a sub
> select for each detail table that is
On Mar 27, 8:07 am, [EMAIL PROTECTED] wrote:
> On Tuesday 27 March 2007 17:18:04 Michael Bayer wrote:> On Mar 27, 2007, at
> 3:53 AM, [EMAIL PROTECTED] wrote:
> > > Lets say u have 5 leaf types in 4-5 levels of the hierarchy tree,
> > > say that makes 10 tables total.
> > > say E object is a leaf
On Tuesday 27 March 2007 17:18:04 Michael Bayer wrote:
> On Mar 27, 2007, at 3:53 AM, [EMAIL PROTECTED] wrote:
> > Lets say u have 5 leaf types in 4-5 levels of the hierarchy tree,
> > say that makes 10 tables total.
> > say E object is a leaf and comes from A.join(B).join(C).join(E) -
> > so E is
On Mar 27, 2007, at 3:53 AM, [EMAIL PROTECTED] wrote:
> Lets say u have 5 leaf types in 4-5 levels of the hierarchy tree, say
> that makes 10 tables total.
> say E object is a leaf and comes from A.join(B).join(C).join(E) -
> so E is split amongst all A B C E tables. Which is the detail table?
>
On Mar 27, 2007, at 2:08 AM, chris e wrote:
>
> specific to the identity of the object. Is there currently a way, or a
> plan to support, splitting the polymorphic query into two queries? The
> first would get the base table, the second would retrieve the details
> based on the discovered table.
On Tuesday 27 March 2007 09:08:32 chris e wrote:
> Currently when sqlalchemy performs a polymorphic lookup, it queries
> against all the detail tables, and returns the correct Python
> object represented by the polymorphic identity. Essentially you get
> a sub select for each detail table that is
