My initial negative reaction was based on the fact that Cayenne
doesn't actually have the concept of an unmapped PK *Java* type on the
server either. It is derived from JDBC default mapping (and often
interpreted differently by different drivers). So creating a method on
ObjEntity that would imply otherwise would be misleading.
Now looking up an object based on an encoded PK is indeed an extremely
important operation in any webapp, so we need to provide some facility
for generic key decoding. I wrote my own ObjectId DataSqueezers for
Tapestry 4 not so long ago, which did not require the knowledge of an
implicit Java PK type. Type information was encoded in the PK string.
E.g. I35 or L444. Do you think you can use the same approach? Does it
cover all scenarios?
Andrus
On Apr 27, 2008, at 6:08 PM, Andrus Adamchik wrote:
> I'd say if you care about such details as PK type, you should map it
> as a meaningful ObjAttribute. I am not convinced that we need to do
> something else here.
>
> Andrus
>
> On Apr 27, 2008, at 5:08 PM, Kevin Menard wrote:
>
>> As part of the fix for CAY-574, we added a getPrimaryKeyNames() :
>> Collection<String> method to ObjEntity. This did the trick and
>> allowed
>> DataObjectUtils to work. Unfortunately, it doesn't expose the PK
>> type
>> information.
>>
>> As some of you likely know, I'm working on Tapestry5-Cayenne
>> integration
>> module with Robert Zeigler. I'm trying to ensure the module works
>> just as
>> well for an ROP client as it does for traditional Cayenne server
>> apps. One
>> of the things we need to be able to handle is the coercion of keys
>> to and
>> from String values. This implies knowledge of the key class type,
>> which is
>> currently unavailable in the client.
>>
>> I'm soliciting ideas on how to improve this. Off the top of my
>> head, I'm
>> thinking something like the following:
>>
>> // Simple key-> value lookup.
>> String getPkClassName(String pkName)
>>
>> // Modification of existing method to allow PK lookups.
>> ObjAttribute getAttribute(String name, boolean includePks)
>>
>> // Rather than just have getPrimaryKeyNames(), return a mapping
>> // of the key name and its Java class.
>> Map<String, String> getPrimaryKeys()
>>
>> If possible, this is something I'd like to see squeezed in for 3.0M4,
>> because I'd really like that module to not have to rely on 3.0-
>> SNAPSHOT.
>>
>> Thanks,
>> Kevin
This archive was generated by hypermail 2.0.0 : Sun Apr 27 2008 - 13:22:53 EDT