On Monday 16 July 2007 18:21:42 Michael Bayer wrote: > 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. add somehow an explicit control which columns constitute the primary key (and do autoguess only if nothing specified)? e.g. currently u can add uniqConstraint etc explicitly, but cannot touch the primary-key stuff.
> 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. i dont know of such sql hackeries, i guess they might be possible, the language is powerful enough. Storing just the base-most class would solve some (speed) issues, but others will remain - for each Class u'll have to do 1 get mapper for the Class 2 find the Base - the base-most mapper - or first concrete one towards root 3 constitute identity key from that and look it up. so it's 2 lookups + a hierarchy descent to the base. i think u can make an optional shortcut (some mapper config), which will store keys for all mappers between Class and Base, thus avoiding the need for step 2, eventualy 1. It's a tradeoff ofcourse, speed vs size of identity_map. It'll be small gain comparing to querying vs non querying, but still a gain... As for concrete-ism, while doing/supporting mixed inheritance in principle i found that concrete-table things behave like offsetted "roots", i.e. all things start a new from them. (sawrap: that's in make_klas_selectable() func + the big comment after it, as well in the as make_mapper ). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
