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
