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(ClassT 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 the
openjpa.DetachState setting. Currently, DetachState can take one of
the
three 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?
Craig
P.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
have
all 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
this
by 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
