Hello Scott,
>Right when you think you understand something (hehe)... I have a similar
>problem, but I *thought* I solved it already. Anyways, I mapped my PK
>column as an obj. attribute since I want to be able to access it in
>queries and such. This works, right?
Yes, you can use the objectFromPrimaryKey() function for this.
> I dont have to use the code given, the class generation will create it
> correctly?
Just add a function like "getPaintingId()" to the class which extends the
generated class. (as described on
<http://www.objectstyle.org/cayenne/userguide/dataobjects/unmapped-keys.html>).
>If I want to change the auto-gen PK (cant see why, just trying to
>understand) with the set method, that will map correctly back to the database?
You shouldn't do _that_ :-) As i understand the primary key generated by
cayenne code, i guess you shouldn't fiddle with that unless you understand
what your doing. I only have putted a "getPaintingId()" like function in
the class which extends the generated class, the getPaintingId() function
returns my primary key. That's the only thing i did and it returned the
primary key. Of cource this will fail when you did not yet commit the
object to the database (i guess).
Greetings,
Twan
>Thanks,
>Scott
>
>Twan Kogels wrote:
>
>>Hello Andrus,
>>
>>Thanks for the pointer, it works perfect! For reference i used code from:
>><http://objectstyle.org/cayenne/lists/cayenne-user/2004/01/0004.html>
>>and
>><http://www.objectstyle.org/cayenne/userguide/dataobjects/unmapped-keys.html>
>>
>>to get access to my primary key.
>>
>>Greetings,
>>Twan
>>
>>At 18:15 28-6-2004, you wrote:
>>
>>>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 : Tue Jun 29 2004 - 08:56:51 EDT