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
>
>
This archive was generated by hypermail 2.0.0 : Mon Apr 28 2008 - 03:50:18 EDT