On Apr 13, 2006, at 6:15 PM, Mike Kienenberger wrote:
On 4/13/06, Andrus Adamchik (JIRA) <[EMAIL PROTECTED]>
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
