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

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

On vendredi, f=E9v 21, 2003, at 11:21 Europe/Amsterdam, Sebastien =
Bigaret=20
wrote:
>
> 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

Exactly.

> - 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=20=

> the
>   corresponding row's pk >> ; could you write a little example?

OK, this is where maybe I am not so clear myself as to how best
to go about it--i tend to think of these relations being always of type
dataTable-to-indexTable. Thus, indexTable rows are really not aware of
what they point to (or rather, who is pointing to them) -- except,=20
obviously, that
one would be able to navigate from an indexTable row to a dataTable row,
even without explicit outgoing relationships on the indexTable,=20
facilitated by
the fact that the primaryKey are identical. However, from the dataTable=20=

end,
each table provides an explicit relationship into any desired
indexTable, helping enforce that the management of a data row's
index entry "belongs" to the data row, i.e. the logic to add or delete
a data row will include the logic to add or delete (or modify)
all affected index entries.

Example:

NODE      an index table
id: 		int pk
name: 	str
type: 	enum : A | B | C  (defined via some rel to another TYPE table,=20=

thus
                    adding possibility to specify some meta-data for=20
each type,
		e.g; an icon)

TREE	index imposes a hierarchy on NODE rows
treeId:	int pk
parent	rel to Node.pk
child		rel to Node.pk

A
id: 		int pk
a1
a2
toNode	explicit relation to Node, and with A.id =3D Node.id

similarly for B and C

How would be best to model such a structure?

(This also raises the question whether the limitation mentioned in the=20=

manual
in section 2.3.2 is still valid... namely that "that toMany=20
relationships must have
inverse (toOne) relationships defined in the model".)


>> 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
>> 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,=20=

> T2 and
> T3 will never intersect (this is, in fact, exactly what make it=20
> possible
> to design a relationship from an entity to another one being part of =
an
> inheritance tree).

Ah, i did not realise that inheritance enforces that pk's are unique=20
across
all rows in the inheritance tree! In the above example, then, would it=20=

be
enough to make A, B and C inherit from NODE? What about implications
on TREE and TYPE? A, B and C are not related directly to these, but
when adding/deleting a row in A, this will cause a row to be added in=20
NODE,
as well as trigger the update to TREE to take this into account (with=20
the
addition of custom application logic, to know where in the Tree this=20
node
is attached).

I am looking for a way to implement the example construct above, while
staying as light as possible (minimum number of explicit relations) and
at the same time maximising automation (framework) of the management
of the relations.

Have not yet tried to prototype such an example, but will plunge soon...
Any "wisdom" comments very much appreciated.

>> Shall I submit this as a feature req in the tracker?
> After we make sure we do understand each other, certainly: that's the=20=

> best
> way to make sure that I won't forget !

It may then not be a feature request, but a modeling problem.
If a feature becomes apparent, let me know, and I will submit.

Cheers,

mario


> -- S=E9bastien.
>
>
>
>> On jeudi, f=E9v 20, 2003, at 23:34 Europe/Amsterdam, Sebastien =
Bigaret
>> wrote:
>>> This also rings a bell about one future feature, where you would be
>>> 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
>>> value,
>>> hence bypassing the automatic generation.  I'll think of it and keep
>>> you
>>> informed of the evolution.
>>
>>
>>
>> -------------------------------------------------------
>> 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
>