Re: [OS-JIRA] Resolved: (CAY-503) Uniquing broken

[Mike Kienenberger <mk...@gmail.com>]

On 4/13/06, Andrus Adamchik (JIRA) <ji...@objectstyle.org> wrote:
> Mike, I fixed it by reimplementing equals and hashCode of ObjectId to "normalize" numeric values, so that all Number subclasses could be compared based on the numeric value, excluding the actual class from the picture.

Hey Andrus.   That fixes this symptom of the problem, but it seems to
me that the root underlying issue is still going to be around.   
Comparisons of primary key attributes will fail when used in other
contexts due to differing types depending on whether the record was
created or fetched from the database.

Re: [OS-JIRA] Resolved: (CAY-503) Uniquing broken

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

On Apr 13, 2006, at 7:27 PM, Mike Kienenberger wrote:

> I'm certainly no expert, but I would think the place to "normalize"
> the value is in the place where the pk value is pulled from the
> database and the place where the pk value is generated.   To what it
> should be normalized is a harder question.   Maybe this is
> adaptor-dependent?   Heck, maybe the whole problem is adaptor
> dependent.

I think it should be normalized to a default (per JDBC spec) Java  
class derived from JDBC type of the PK DbAttribute. There is a more  
general issue with DataRow types [1]. As you see this can open a big  
can of worms. I will log a Jira task to get back to it after 1.2.

BTW, I wonder if my current fix also addressed [2]? It was truly  
universal :-)

Andrus

[1] http://objectstyle.org/jira/browse/CAY-399
[2] http://objectstyle.org/jira/browse/CAY-191

Re: [OS-JIRA] Resolved: (CAY-503) Uniquing broken

[Mike Kienenberger <mk...@gmail.com>]

On 4/13/06, Andrus Adamchik <an...@objectstyle.org> wrote:
> On Apr 13, 2006, at 6:15 PM, Mike Kienenberger wrote:
>
> > On 4/13/06, Andrus Adamchik (JIRA) <ji...@objectstyle.org>
> > wrote:
> >> Mike, I fixed it by reimplementing equals and hashCode of ObjectId
> >> to "normalize" numeric values, so that all Number subclasses could
> >> be compared based on the numeric value, excluding the actual class
> >> from the picture.
> >
> > Hey Andrus.   That fixes this symptom of the problem, but it seems to
> > me that the root underlying issue is still going to be around.
> > Comparisons of primary key attributes will fail when used in other
> > contexts due to differing types depending on whether the record was
> > created or fetched from the database.
>
> I guess alternatively we may enforce the ID value type [and convert
> wrong types to a type returned by TypesMapping.getJavaBySqlType(int)]
> in places such as ObjectIdQuery, pk generator,
> DataDomainFlushObserver generated key callback (am I missing anything?).
>
> Doing this at the ObjectId level is actually safe - the id will work
> even if it isn't using the right Number subclass. But I agree - it
> does look ugly (and probably wrong at some level).  I opted for this
> solution because it doesn't require access to a PK DbAttribute at the
> point of id creation (e.g. there are no DbEntities on the client).
>
> So maybe we leave it the way it is in 1.2, and after that we can add
> id metadata to the ObjEntity, so that it is accessible without going
> below the object mapping layer? (actually that may become a part of
> the ClassDescriptor).

I agree that this will work for the common case.   I'm just concerned
about what will happen if someone tries anything fancy directly with
the PK DbAttributes.

I'm certainly no expert, but I would think the place to "normalize"
the value is in the place where the pk value is pulled from the
database and the place where the pk value is generated.   To what it
should be normalized is a harder question.   Maybe this is
adaptor-dependent?   Heck, maybe the whole problem is adaptor
dependent.

Re: [OS-JIRA] Resolved: (CAY-503) Uniquing broken

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

On Apr 13, 2006, at 6:15 PM, Mike Kienenberger wrote:

> On 4/13/06, Andrus Adamchik (JIRA) <ji...@objectstyle.org>  
> wrote:
>> Mike, I fixed it by reimplementing equals and hashCode of ObjectId  
>> to "normalize" numeric values, so that all Number subclasses could  
>> be compared based on the numeric value, excluding the actual class  
>> from the picture.
>
> Hey Andrus.   That fixes this symptom of the problem, but it seems to
> me that the root underlying issue is still going to be around.
> Comparisons of primary key attributes will fail when used in other
> contexts due to differing types depending on whether the record was
> created or fetched from the database.

I guess alternatively we may enforce the ID value type [and convert  
wrong types to a type returned by TypesMapping.getJavaBySqlType(int)]  
in places such as ObjectIdQuery, pk generator,  
DataDomainFlushObserver generated key callback (am I missing anything?).

Doing this at the ObjectId level is actually safe - the id will work  
even if it isn't using the right Number subclass. But I agree - it  
does look ugly (and probably wrong at some level).  I opted for this  
solution because it doesn't require access to a PK DbAttribute at the  
point of id creation (e.g. there are no DbEntities on the client).

So maybe we leave it the way it is in 1.2, and after that we can add  
id metadata to the ObjEntity, so that it is accessible without going  
below the object mapping layer? (actually that may become a part of  
the ClassDescriptor).

Andrus