On 4/13/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> 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).
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.
This archive was generated by hypermail 2.0.0 : Thu Apr 13 2006 - 11:27:32 EDT