On Apr 27, 2008, at 1:22 PM, Andrus Adamchik wrote:
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.
Right. What I'm looking for is the type used by the adapter. I'm not
sure using anything else would make much sense.
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?
This would certainly be doable and is indeed how things have been done
with T4. We're striving for prettier URLs as it were. A given URL
will already map to an entity and based on position, we'll know what
the PK value is. So, the inclusion of PK type data just makes the URL
uglier and wouldn't be necessary if the entity could tell us what type
to use for the PK.
Having said that, I was looking more into how DataObjectUtils handles
String values and it looks like it handles the conversion fairly well
in the absence of type information. I'll have to look into it more
though. If that be the case, your initial reaction may have been well-
founded.
--
Kevin
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
