Just because the Spec
says something, doesn't mean every user knows
about it, do it, and implement it correctly.
We used to rely on the user implementing equals and hashCode
correctly
for our UnitOfWork, in TopLink 1.0 and it was a complete disaster in
having
clients getting odd behavior and weird errors.
We will also be breaking backward compatibility of anyone who
is not
currently implementing equals or hashCode, or not implementing them
correctly.
The cache is internal to
EclipseLink for normal JPA users. They should
not care that we used an
optimized type, as we have always done so.
It is only the users that are using a third party cache that
would at
all be interested in what our cache is using internally as a cache key.
I cannot see how it would
be possible to implement equivalent
performance with the user defined Id Class objects.
-----Original
Message-----
From: Gordon Yorke
Sent: Monday, January
18, 2010
1:23 PM
To: Dev mailing list
for Eclipse
Persistence Services
Subject: Re: AW:
[eclipselink-dev]
SVN main commit: bug#298985 - changing primary key from vector to object
Any
PKClass that did not
correctly implement hashCode and equals would be in violation of the
specification. As for performance you are still proposing building
some
complex Object type. For PKClasses we could dynamically define
factories
at deployment that should have similar performance to using a
proprietary
internal type.
--Gordon
James Sutherland wrote:
We
should not be using the JPA IdClass by default.
These classes will typically have very poor performance, and commonly
not implement
equals and hashCode correctly. This should be a configurable option.
-----Original
Message-----
From: Gordon Yorke
Sent: Monday, January
18, 2010
10:06 AM
To: Dev mailing list
for Eclipse
Persistence Services
Subject: Re: AW:
[eclipselink-dev]
SVN main commit: bug#298985 - changing primary key from vector to object
The default
for composite PKs should depend on if JPA is used. With JPA we should
be
using the PK class.
Also we need some sort of public policy class for the CacheInterceptor
implementations.
This change is also breaking any CacheInterceptors that have been
created for
previous version and we need some sort of migration plan.
--Gordon
James Sutherland wrote:
It will be configurable,
for a singleton primary key
object it will just be the id value, i.e. Long, Integer, String, etc.
For
a composite primary key object the default will be a CacheId object
that wraps
an Object[]. It is also desirable to be able to use the JPA Id class
as
the cache id.
-----Original
Message-----
From: Goerler, Adrian [mailto:adrian.goerler@xxxxxxx]
Sent: Friday, January
15, 2010
4:41 AM
To: Dev mailing list
for Eclipse
Persistence Services
Subject: AW:
[eclipselink-dev] SVN
main commit: bug#298985 - changing primary key from vector to object
Hi James,
(Vector
is still always used internally)
how
will the primary keys be represented once Vector is not used any longer
internally?
-Adrian
Adrian
Görler
SAP
AG
Pflichtangaben/Mandatory
Disclosure Statements:
http://www.sap.com/company/legal/impressum.epx
SVN
main commit: bug#298985 - changing primary key from vector to object
https://bugs.eclipse.org/bugs/show_bug.cgi?id=298985
Changes:
-
Switching remain primary key methods from Vector to Object, (Vector is
still
always used internally), ObjectBuilder, sessions, queries
-
Deprecated old public API that used Vector in IdentityMapAccessor,
Session, ReadObjectQuery,
ReportQuery
-
Removed some dead code, added some @Overrides
Code
review: Gord
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
