modeling-users

[Modeling-users] primary key + class property

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I saw in the FAQ that I could see my primary keys by setting them as
class properties.  If I try this, I need to set them by hand.  

How can I have *automatic* primary keys that I can see ?

I really need to see my primary keys in order to cross an XML-RPC bridge.

Regards, 

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VTFArhy5Fqn/MRARAlDxAJwJC4IS7rj7ybmiE/d4TBDG1HhongCfSLWU
NJAJyx92thpzigNpFZ0TQqk=
=if65
-----END PGP SIGNATURE-----

Re: [Modeling-users] primary key + class property

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 February 2003 02:49 pm, Yannick Gingras wrote:
> I saw in the FAQ that I could see my primary keys by setting them as
> class properties.  If I try this, I need to set them by hand.
>
> How can I have *automatic* primary keys that I can see ?

By setting default value to 0 + isRequired to 1.

Should be in the FAQ !

 ; )

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VTMPrhy5Fqn/MRARAs55AJ9yPJmvAAm09aekGUOOB6elyL9rTwCghRFr
+UypJiYLO6E1rJLYOk/jqIA=
=2x4z
-----END PGP SIGNATURE-----

Re: [Modeling-users] primary key + class property

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

Yannick Gingras <yan...@sa...> writes:
> On Thursday 20 February 2003 02:49 pm, Yannick Gingras wrote:
> > I saw in the FAQ that I could see my primary keys by setting them as
> > class properties.  If I try this, I need to set them by hand.
> >
> > How can I have *automatic* primary keys that I can see ?
>=20
> By setting default value to 0 + isRequired to 1.

Could you please be more specific? Do you say that automatic generation
of primary key does not work if you define it as a class property???
More on this: the framework does not support setting the primary key of
an object by hand --that's why I really want more details on what
happened to you here.

  If this is the case, this is a bug I really want to trace: this should
  NOT happen, and I cant even see now how automatic pk generation could
  be defeated when the primary key is a class property (it is nnot even
  checked when insertedObjects of an EditingContext are processed).

However you are right: the default value should be 0, and isRequired
must always be set to 1 for a PK (being a class property or not).


-- S=E9bastien.

Re: [Modeling-users] primary key + class property

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 February 2003 04:56 pm, you wrote:
> > > How can I have *automatic* primary keys that I can see ?
> >
> > By setting default value to 0 + isRequired to 1.
>
> Could you please be more specific? Do you say that automatic generation
> of primary key does not work if you define it as a class property???
> More on this: the framework does not support setting the primary key of
> an object by hand --that's why I really want more details on what
> happened to you here.
>
>   If this is the case, this is a bug I really want to trace: this should
>   NOT happen, and I cant even see now how automatic pk generation could
>   be defeated when the primary key is a class property (it is nnot even
>   checked when insertedObjects of an EditingContext are processed).
>
> However you are right: the default value should be 0, and isRequired
> must always be set to 1 for a PK (being a class property or not).

I had a default value set to 'None' for the primary key of an entity.
It worked perfectly as long as the primary key was not a class
property.  When I turned it (the primary key) to a class property, I
was not able to create an object anymore.  When saving the changes,
the editing context was complaining about a required field not
initialized.  I changed the default value to 0 and it worked.

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VUPprhy5Fqn/MRARAoHUAKCQvgh2zKEYWa87aBd5CPrKxMgLFQCfQ2Li
Mk1ImygzRKW2Hq3RcCFVo48=
=L4/r
-----END PGP SIGNATURE-----

Re: [Modeling-users] primary key + class property

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

Yannick Gingras <yan...@sa...> writes:
[about PK being class properties NOT being automatically generated]
> I had a default value set to 'None' for the primary key of an entity.
> It worked perfectly as long as the primary key was not a class
> property.  When I turned it (the primary key) to a class property, I
> was not able to create an object anymore.  When saving the changes,
> the editing context was complaining about a required field not
> initialized.  I changed the default value to 0 and it worked.

Ok, that makes sense: the validation process was preventing the
framework to save the changes, hence the primary key had no chance to
get its value.

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.

> Should be in the FAQ !
> ; )

Definitely!  Thanks a lot for reporting this.

-- S=E9bastien.

Re: [Modeling-users] primary key + class property

[Yannick G. <yan...@sa...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 20 February 2003 05:34 pm, Sebastien Bigaret wrote:
> Definitely!  Thanks a lot for reporting this.

No problems.

While I'm at it, there is a typo in mdl_generate_python_code.py

$ mdl_generate_python_code.py 2>&1 | grep stpped
  exists, the build process is stpped       <---        stpped

Regards, 

- -- 
Yannick Gingras
Byte Gardener, Savoir-faire Linux inc.
(514) 276-5468
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+VVAYrhy5Fqn/MRARAiK3AJ0ZTfXj/uzdn00KhwyGOJ3G34Wi0gCgk2VZ
Ui8gtsyyzYfKUu6UrxhJ+XU=
=lpil
-----END PGP SIGNATURE-----

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.

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

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
>

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

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

        Hi,

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

Okay, let's consider they are all sub-entities of entity Node

> [...] 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,
> obviously, that one would be able to navigate from an indexTable row
> to a dataTable row, even without explicit outgoing relationships on
> the indexTable, facilitated by the fact that the primaryKey are
> identical. However, from the dataTable 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,
>                          thus adding possibility to specify
>                          some meta-data for 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?

  My first thought about this is that the underlying model might look l=
ike:

[1]    +-children----+
       |             |
       v             |
       v             |
    +------+         |
    | Node |<-parent-+
    +------+=20=20=20=20=20=20=20=20=20=20
       |
    +--+--+
    |  |  |
    A  B  C

which can be modeled just straightforward. However I suspect that your
situations requires to keep the hierarchy structure separated from the
informations stored in table A, B and C. In this case, I guess you may
consider this model:

[2]                             +--children---+
                                |             |
                                v             |
                                v             |
    +------+                 +------+         |
    | Node |<-node-----tree->| Tree |<-parent-+
    +------+                 +------+
       |
    +--+--+
    |  |  |
    A  B  C


Given that one-to-one is not supported yet, the node/tree relationship
must be modeled as a one-to-many rel. If you really do not want to have
*any* informations in tables A, B and C about the tree structure (that
is to say, that's a requirement at the relational level, nnot on the
objects' side), just design the toNode as to-one and toTree as to-many
(this way, the relationship is retrieved via a foreign key declared in
the table Tree)


  However and re-reading your post, the following things seem strange t=
o me:

> NODE
> type: enum : A | B | C  (defined via some rel to another TYPE table,
>                          thus adding possibility to specify
>                          some meta-data for each type, e.g; an icon)
[...]
> A:
> toNode        explicit relation to Node, and with A.id =3D Node.id

I wonder whether you're not too tight to the way you'll do this by hand
with raw SQL, or if I'm missing something. Let me comment on this:

   You say A.id=3DNode.id, but you'll never get this: the framework mak=
es
   sure that each row of Node (which will in fact be an empty table,
   since no elements of type Node would ever be instanciated), A, B or C
   will have different PK. In the case you think of it as a mean to
   actually retrieve the corresponding object pointed to in either A, B
   and C, you do not need it: the framework automatically takes care of
   this for you. E.g. in [1], parent & children relationships can point
   to objects of type A, B or C (same for toNode in [2]).

Same for the other entity Type: just model it the way the association
between Node & Tree is made in [2] (or alternatively put the common
meta-datas in entity Node and specific metadatas in entities A, B & C
--at least if the set of metadatas are not subject to changes after
valuable datas are stored within the database: if they are, the first
solution is a better one for sure).

> Ah, i did not realise that inheritance enforces that pk's are unique
> across all rows in the inheritance tree! In the above example, then,
> would it be enough to make A, B and C inherit from NODE?=20

I think so

> (This also raises the question whether the limitation mentioned in the
> manual in section 2.3.2 is still valid... namely that "that toMany
> relationships must have inverse (toOne) relationships defined in the
> model".)

Yes, indeed, this is still valid.

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

  I'm not clear at all on what you mean by: minimum number of explicit
  relations. Why do relations bother you so much? Is this because of the
  previous statement about toMany relations being required to have an
  inverse?  This requirement has really nothing to do w/ inheritance, it
  just says that a toMany relationship from entity e1 to e2 must have an
  inverse. Now speaking of inheritance, the sub-entities *must* include
  the set of the inherited attr. & rels., this is because the model maps
  object to relational --however your (generated) classes will _inherit_
  the relations and attributes, and they wont re-declare them: the
  replication will only be in the model. Similarly, the business-logic
  attached to rel. toTree in class Node will be inherited in A, B and C.

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

I just hope I succeeded to make myself clear, and that I did not miss
some important points in your post...

        Cheers,

-- S=E9bastien.