Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: AW: [eclipselink-dev] SVN main commit: bug#298985 - changing primary key from vector to object

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


 

Von: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-bounces@xxxxxxxxxxx] Im Auftrag von James Sutherland
Gesendet: Mittwoch, 13. Januar 2010 19:09
An: Eclipselink-Dev@Eclipse. Org (E-mail)
Betreff: [eclipselink-dev] SVN main commit: bug#298985 - changing primary key from vector to object

 

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
  

Back to the top