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
This archive was generated by hypermail 2.0.0 : Sun Apr 27 2008 - 17:14:54 EDT