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/Development/2.1/AdvancedJPA Queries/FetchGroup

Revision as of 10:57, 15 April 2010 by Gordon.yorke.oracle.com (Talk | contribs) (Attempts to access unfetched attributes will cause an exception to be thrown)

FetchGroup Copy

  • Session already has a copyObject() API, this should just be exposed on the JpaEntityManager interface and allow an optional FetchGroup argument. I am not a fan of having static Helper objects, but using our public interface and the standard JPA 2.0 unwrap API.

FetchGroup "Sparse" Merge

  • The UnitOfWork merge() APIs should be exposed on our JpaEntityManager interface (shallowMerge, deepMerge, merge(Object, FetchGroup). I am not a fan of having static Helper objects, but using our public interface and the standard JPA 2.0 unwrap API.

EntityFetchGroup

  • I don't see the reason for having an EntityFetchGroup. The Entity should just hold the FetchGroup from the query (which should be cached in the query). If the Entity needs to add something to the fetch-group it should first copy it, perhaps have a shared flag in the FetchGroup if required.

Refreshing

  • There should be some way to refresh a partial object and have the version updated. A normal query should union the two fetch groups and not refresh the version. A refresh query should not union the fetch groups but use the new one only, and refresh the version. Otherwise, there is no way to refresh a stale object without fetching the object in its entirety.

Serialization, instantiation

  • I do not think fetch groups should be coupled with serialization support. Serialization support is something that any user serializing requires, and should not require the usage of fetch groups. We should have a separate option on query to force instantiation of a set of attributes. Fetch groups and join fetching could have an option to automatically add their relationships to this separate option. The instantiation must be implemented very carefully to avoid cache deadlocks.

@FetchGroupAttribute

  • Is the really required since it does not seem to do anything but have a name? Does it have any other attributes?

Attempts to access unfetched attributes will cause an exception to be thrown

  • Our indirection support can load results within a detached object. Our FetchGroup support should be able to do the same.

Back to the top