Constraining primary keys (was: [Modeling-users] primary key + class property)

[Mario R. <ma...@ru...>]

Interesting discussion, especially as i was about to make what I thought
would be a nasty request (given the generous warnings! in the guide ;-)
for a particular situation, I would like to relate the pk of a number=20
of selected
data tables, to guarantee that each key is unique amongst those tables.
This will facilitate (simplify) having one or more other tables, such=20
as a user rights
table, or a "hierarchy-imposing" table, to have relations to each of the
data tables -- the advantage would be that the primary key in the=20
"index" tables
can be identical to the corresponding row's pk, whatever data table it=20=

is in.

This can be done by either:
(a) the framework allowing pk definition responsability to
the application code, or
(b) building into the model capabilities a way to express
this, from which the framework will do everything correctly (very=20
nice)...

Would does everyone think?
Is, at least, (a) possible in short-term?
Shall I submit this as a feature req in the tracker?

Best regards,

Mario Ruggier


On jeudi, f=E9v 20, 2003, at 23:34 Europe/Amsterdam, Sebastien Bigaret=20=

wrote:
> This also rings a bell about one future feature, where you would be=20
> able
> to set the primary key according to your own scheme --in this case,
> having None or 0 (or even '') would mean ''use automatic PK
> generation'', while any other value will be used as-is for the PK=20
> value,
> hence bypassing the automatic generation.  I'll think of it and keep=20=

> you
> informed of the evolution.