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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
