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