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
