Hi there,
the reason of not having a PK column in the object by default (you can
change this if you want) is more of a "philosophical" one -
autoincremented PK is meaningless within an object and is just a database
convenience. So the rule of thumb is to not include such columns in the
object model, and let Cayenne handle them internally (encapsulated as
ObjectId). In case PK is meaningful (say "USER_TYPE_CODE" or something),
it can be mapped as an object property - Cayenne fully supports that.
Now, if you want to use an autoincremented PK in your query, you can still
do that. There were a few threads about it on the mailing list. For
example check out this one:
http://objectstyle.org/cayenne/lists/cayenne-user/2004/01/0002.html
Cheers,
Andrus
> Hello people,
>
> Today i downloaded and studied the "cayenne-web-app" example, which uses
> struts en cayenne to create a webapplication which allows people to
> manage paintings, galleries and artists.
>
> It was a interesting and easy to understand example. But i've got a
> question about the example of something that isn't really clear for me.
>
> In the example there is a Artist entity and a table ARTIST where the
> Artist entities are saved into. The ARTIST table contains of 3 rows,
> one of them is ID the primary key. My question is about this primary
> key:
>
> Why is the primary key not included as a attribute in the Artist entity,
> is there maybe a special reason for not to do this?
>
> The reason for asking this is that it seems logical to include the ID as
> a attribute of the Artist entity. Because for example when adding a
> painting to a artist, you could use:
> http://localhost:8080/struts/addPainting.do?artistid=2
> instead of the error phrone:
> http://localhost:8080/struts/addPainting.do?name=myname
> (myname doesn't seems to be unique, artistid is as a primary key always
> unique)
>
> Best regards,
> Twan Kogels
This archive was generated by hypermail 2.0.0 : Mon Jun 28 2004 - 12:15:11 EDT