well, i'm using them NPs just to have another (simpler) select_table.
otherwise anything query through primary_mapper starts off its own 
select_table, which can be rather huge in my case.
if u can make the a query( primary_mapper, select_table) somehow 
possible... i won't need separate NPs. Note this selecttable is not 
additional .select() off the query, it IS the starting query(), e.g. 
thepolymorphic union in a big case and base-class-only in a small 
case.

maybe u need some notion that is smaller than mapper - a mapper 
without ANY select_table, + something do attach allowing different 
initial select_tables.

On Tuesday 17 July 2007 16:17:17 Michael Bayer wrote:
> On Jul 17, 2007, at 2:18 AM, [EMAIL PROTECTED] wrote:
> >>> I don't remember that in docs. Did I miss a section, or is this
> >>> too obscure for the general usage?
> >>
> >> its only obscure because i think non_primary mappers are not
> >> *too* common, but their behavior should be more well defined in
> >> the docs (that they dont want to deal with attributes is a big
> >> one)
> >
> > is this 100%?
> > i mean, if i define a primary mapper with all attrs and
> > relations, then i define a non-primary without adding _any_
> > properties, it will work? Sort-of "inheriting" all these from the
> > primary?
> > so far i am adding (again) all properties which are not
> > relations...
>
> no, it doesnt inherit them.   it just doesnt have any access to
> class- level instrumented attributes since it would conflict with
> the primary mapper, and thats where the "default" loading strategy
> of an attribute is set.  the idea that it would change the loading
> strategies instead in a per-instance manner, which is possible,
> seems like a lot of work to go through when youre supposed to just
> be using options() with the primary mapper.  technically, if you
> made a non primary mapper with a different join condition to an
> attribute, then maybe thats a road more worth going down....but
> then, id rather find a way to not have NPs be necessary since its
> getting crazy at that point.
>
>
>
>
>
> 


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to