I think this may be the best bet. It affords us the most flexibility
in the event that someone needs some other piece of metadata.
If no one objects, I'll open up a JIRA and try to take care of it
before I leave tomorrow. Unless it's something we want to vet out a
bit more before the M4 release. I'd just hate to have the integration
module have a dependency on a snapshot release.
--
Kevin
On Apr 28, 2008, at 3:49 AM, Andrus Adamchik wrote:
Extending this thought, maybe we can make ObjectIdQuery optionally
perform type conversion in "getObjectId()" and
"createRelacementQuery()" methods. This would still result in a
cache miss on the client, but will work correctly everywhere on the
server.
... Or maybe we go along the lines of your original suggestion and
just replace
Collection<String> getPrimaryKeyNames();
with
Collection<ObjAttribute> getPrimaryKeys();
returning "synthetic" ObjAttributes that won't be present in the
collection returned via "getAttributes()".
Andrus
On Apr 28, 2008, at 10:36 AM, Andrus Adamchik wrote:
On Apr 28, 2008, at 12:14 AM, Kevin Menard wrote:
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.
My suspicion without reviewing the algorithm, is that it will miss
objects cached in memory, as it doesn't do any type conversion by
itself, an an ObjectId "equals" method implementation depends on
correct value(s) type (ObjectId is used as an object map key
throughout Cayenne). So it will query the database every time, and
if the DB is ok with matching numerics against varchars, it will
produce correct results. If not - this will result in a server-side
SQLException. Again, going from memory, I think MySQL will work,
PostgreSQL will break. But that's worth double-checking.
Andrus
