On Jul 16, 2007, at 10:45 AM, svilen wrote:
> > i think it is not a problem to store as many keys as there are > identical levels in polymorphism/inheritance as long as this is > synchronized with type of inheritance. > i.e. joined-table inheritance chains (and single table maybe) are ok > as is, anything concrete-table in between changes the game. > As for the concrete, i think it can be done same as with > polymorphism - storing composite keys (type,id) where just keys are > ambigious. > > but i bet noone has ever wanted mixed inheritance, no? (:-) well this has been coming up in other ways lately too. if you map inheritance like this (forgive my entirely made up table syntax): table a ( id primary key ) table b( id primary key a_id foreign key a.id ) SA makes the primary key of B to be (a.id, b.id), since theres a pk in both tables...you have to call get() as get(1,2). this stems from just, i was trying to put as few opinions as possible anywhere. but this is silly. unless we were supporting some kind of inheritance where B1 would be (1,1) and B2 would be (1, 2), i.e. sharing a row of "A" between two instances, theres no reason the primary key shouldnt be just (a.id). but then, maybe someone does want to do that ? we always wanted to allow as much hackery as possible. what i think i might try to do today, in 0.4, is to calculate the "primary key" columns of a mapper against its bottommost inherited mapper, when "concrete" is not present (as usual, concrete cases get thrown by the wayside for now....). and *then*, the "identity_key" would also get created against the bottommost mapper located in this process as well (so yes, (Person, (x,)) in all cases). that would actually fix a lot of things....in most cases ppl wouldnt have to be calling get(x,y,z) or assembling distinct primary keys to achieve it. if they do want the hackery mentioned above, *then* they can put an explicit primary_key on their mapper for that. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---