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