Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Talk:EclipseLink/DesignDocs/298985

Comments

Deprecating PK API

Currently the API uses Vector any PK operations. I would like to suggest we deprecate these API keeping them functioning as they do now with the plan to remove them in a future release. We can then add new API that takes and returns Object using the JPA id/identifier naming instead of PK. --Doug 21:10, 7 January 2010 (UTC)

Old Vector API is still supported, but deprecated. New API takes Object instead of Vector.
James.sutherland.oracle.com 09:17, 8 February 2010 (UTC)

Batching reading using exist and IN

We are having the "batching using in"-feature in SAP JPA. An additional advantage above the before mentioned is that you can fish out the PKs for which the related entities already exist in the persistence context or in the 2nd level cache. This allows to reduce the number of PKs to be retrieved quite efficiently.

Also, you can batch fetching same entities wich are referenced by different relationships, e.g. employee.homeAddress and employee.workAddress.

--Adrian 08:48, 05 February 2010 (CET)

Yes, there are some advantages to the IN style. This is actually how we originally implemented batch reading in our original Smalltalk product. It also does have its limitations of poorly handling composite primary keys, one-to-manys and many-to-manys, producing large SQL strings, dynamic SQL parsing and generation, requires multiple queries for a large set of objects. There are trade-offs to each approach, which is why to goal is to support three different mechanisms.
James.sutherland.oracle.com 09:17, 8 February 2010 (UTC)

Back to the top