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

[Sebastien B. <sbi...@us...>]

Mario:
> 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 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
> 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 "index" tables can be identical to the
> corresponding row's pk, whatever data table it is in.

Let me rephrase it to make sure I did understand:

- you have some tables, say T1, T2 and T3, for which you want to have a
  unique pk-generation scheme, i.e. where a pk value in T1 cannot be a
  pk value in t2 and in t3

- you want to have one or more tables/entities with relationships
  pointing to t1, t2 and t3. Here I do not really understand your point
  about << the primary key in the "index" tables [being] identical to t=
he
  corresponding row's pk >> ; could you write a little example?

> 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)...

I'm afraid (a) won't be possible in short-term
About (b): there is already such a mechanism you can use for at least
part of your requirements: inheritance! Even if T1, T2 and T3 have
nothing in common, you can always make them sub-entities of a fake
root-entity. This will ensure that the pk values assigned to rows T1, T=
2 and
T3 will never intersect (this is, in fact, exactly what make it possible
to design a relationship from an entity to another one being part of an
inheritance tree).

> Shall I submit this as a feature req in the tracker?
After we make sure we do understand each other, certainly: that's the b=
est
way to make sure that I won't forget !


-- S=E9bastien.

=20=20=20=20=20=20=20=20

> On jeudi, f=E9v 20, 2003, at 23:34 Europe/Amsterdam, Sebastien Bigare=
t=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 kee=
p=20
> > you
> > informed of the evolution.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users