You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Patrick Linskey <pl...@bea.com> on 2007/01/17 19:52:57 UTC
detachment, getReference(), and openjpa.DetachState
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
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.
Re: detachment, getReference(), and openjpa.DetachState
Posted by Craig L Russell <Cr...@Sun.COM>.
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 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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: detachment, getReference(), and openjpa.DetachState
Posted by Kevin Sutter <kw...@gmail.com>.
On 1/17/07, Dain Sundstrom <da...@iq80.com> wrote:
>
>
> I think we should ask our selves, what does a user expect to happen
> and make that the default. If every JPA implements this with the
> loaded+fetchgroup style by default, and OpenJPA doesn't that would be
> quite surprising to users and will most likely result in a lot of
> lost hours in a debugger.
>
>
To be spec compliant, I agree with Abe that "loaded" should stay the
default. Providing the other alternatives for the DetachState is great (and
it sounds like loaded+fetchgroup would be a nice addition), but our default
should be consistent with the spec -- regardless of what the other JPA
implementations do. It's much easier to convince customers that we're spec
compliant with the defaults than attempting to explain why some other
default option is "better for them".
Kevin
Re: detachment, getReference(), and openjpa.DetachState
Posted by Dain Sundstrom <da...@iq80.com>.
On Jan 17, 2007, at 12:07 PM, Patrick Linskey wrote:
>>> The tests can be made to pass by setting the openjpa.DetachState
>>> property to 'fgs',
>>
>> 'loaded' is the proper default. If the CTS is relying on any state
>> being loaded after a call to getReference(), then those CTS
>> tests are
>> wrong and should be reported as such. The description of
>> EntityManager.getReference explicitly states that state might be
>> lazily fetched and that you can't rely on the state being available
>> on detach unless you've accessed it.
>
> Yes, agreed. The tests have been challenged and are being removed from
> the CTS. Nonetheless, the behavior that the CTS relied on still seems
> valuable.
>
> I should have been more clear in my original email: I'm not trying to
> figure out how to pass the CTS test, but am wondering if we should be
> adding the loaded+fetchgroup option, since it seems useful.
I think we should ask our selves, what does a user expect to happen
and make that the default. If every JPA implements this with the
loaded+fetchgroup style by default, and OpenJPA doesn't that would be
quite surprising to users and will most likely result in a lot of
lost hours in a debugger.
-dain
RE: detachment, getReference(), and openjpa.DetachState
Posted by Patrick Linskey <pl...@bea.com>.
> > The tests can be made to pass by setting the openjpa.DetachState
> > property to 'fgs',
>
> 'loaded' is the proper default. If the CTS is relying on any state
> being loaded after a call to getReference(), then those CTS
> tests are
> wrong and should be reported as such. The description of
> EntityManager.getReference explicitly states that state might be
> lazily fetched and that you can't rely on the state being available
> on detach unless you've accessed it.
Yes, agreed. The tests have been challenged and are being removed from
the CTS. Nonetheless, the behavior that the CTS relied on still seems
valuable.
I should have been more clear in my original email: I'm not trying to
figure out how to pass the CTS test, but am wondering if we should be
adding the loaded+fetchgroup option, since it seems useful.
-Patrick
_______________________________________________________________________
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.
Re: detachment, getReference(), and openjpa.DetachState
Posted by Abe White <aw...@bea.com>.
> 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',
'loaded' is the proper default. If the CTS is relying on any state
being loaded after a call to getReference(), then those CTS tests are
wrong and should be reported as such. The description of
EntityManager.getReference explicitly states that state might be
lazily fetched and that you can't rely on the state being available
on detach unless you've accessed it.
_______________________________________________________________________
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.