Re: Client PK access

[Kevin Menard <km...@servprise.com>]

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
>>
>>
>

Re: Client PK access

[Andrus Adamchik <an...@objectstyle.org>]

+1.

If SVN is down when you are ready to commit, attach a patch to Jira -  
I'll apply it once it is back online.

Andrus

On May 2, 2008, at 6:10 PM, Kevin Menard wrote:

> 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
>>>
>>>
>>
>
>