Here's what the spec says about getReference. /** * Get an instance, whose state may be lazily fetched. * If the requested instance does not exist in the database, * the EntityNotFoundException is thrown when the instance *state is first accessed.(The persistence provider runtime is * permitted to throw the EntityNotFoundException when * getReference is called.) *The application should not expect that the instance state will * be available upon detachment, unless it was accessed by the * application while the entity manager was open. * @param entityClass * @param primaryKey * @return the found entity instance * @throws IllegalArgumentException if the first argument does * not denote an entity type or the second * argument is not a valid type for that * entity’s primary key * @throws EntityNotFoundException if the entity state * cannot be accessed */ public <T> T getReference(Class<T> entityClass, Object prima- ryKey);
If I read it correctly, doing the following will result in a detached instance with no state (assuming that the getReference is the first time this persistence context has seen the instance):
TestClass tc = em.getReference(TestClass, testoid); em.close();So without actually seeing the failing CTS test, the test itself might be at issue.
That said, a couple of comments below... On Jan 17, 2007, at 10:52 AM, Patrick Linskey wrote:
Hi, In working on the CTS, we've discovered some assumptions that cause OpenJPA to fail. The CTS obtains records via calls to getReference(), and then does some work with the objects. The tests fail outright with default OpenJPA settings, as the openjpa.DetachState property defaults to 'loaded'. Instances obtained via getReference() have not yet been loaded, so there is no data available when the instances are detached. The tests can be made to pass by setting the openjpa.DetachState property to 'fgs', which causes OpenJPA to explicitly load all the fields in the default fetch group at detachment time. (Incidentally, this raised the issue being tracked with OPENJPA-103.) However, I'm not totally happy with the options available for theopenjpa.DetachState setting. Currently, DetachState can take one of thethree values: loaded: detached objects contain exactly the fields that have been loaded during the persistence context's life fgs: detached objects contain exactly the fields in the current fetch configuration at detach time
The fetch configuration in JDO includes two distinct flags: DETACH_LOAD_FIELDS and DETACH_UNLOAD_FIELDS. If the DETACH_UNLOAD_FIELDS is set to false, it behaves like your proposal for loaded-and-fetched-groups.
Would it be possible to implement the LOAD and UNLOAD behavior in openJPA?
CraigP.S. The Reference Implementation for JSR-220 has a non-spec feature: the ability to load non-loaded fields of detached instances. This behavior might have influenced the CTS test inappropriately.
all: detached objects are fully traversed at detach time I think that it'd be valuable to have a fourth option:loaded-and-fetch-groups. Using this setting, detached objects would haveall the fields in the current fetch configuration, plus all the fields that the business code happened to access during the transaction. This is different than 'fgs' because 'fgs' will actually clear fields that are not in the current fetch configuration. It is different than 'loaded' because it will ensure that instances obtained via getReference() are hydrated prior to detachment. Thoughts? -Patrick -- Patrick Linskey BEA Systems, Inc.______________________________________________________________________ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return thisby email and then delete it.
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
