On Apr 13, 2006, at 6:15 PM, Mike Kienenberger wrote:
> On 4/13/06, Andrus Adamchik (JIRA) <jira-norepl..bjectstyle.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
This archive was generated by hypermail 2.0.0 : Thu Apr 13 2006 - 11:10:14 EDT