[jira] Updated: (OPENJPA-514) Problems with the openjpa.RestoreState property

["David Ezzio (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OPENJPA-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Ezzio updated OPENJPA-514:
--------------------------------

    Attachment: TestCasesOpenJPA-514.zip

Test cases described.

> Problems with the openjpa.RestoreState property
> -----------------------------------------------
>
>                 Key: OPENJPA-514
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-514
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 1.1.0
>         Environment: Windows, at OpenJPA revision 619978
>            Reporter: David Ezzio
>         Attachments: TestCasesOpenJPA-514.zip
>
>
> Section 3.3.2 of the JPA spec is clear that upon rollback, all managed
> instances become detached, and in their detached state they may not be
> consistent or reusable as normally detached instances would be.
> OpenJPA has a property "openjpa.RestoreState" for which it claims a much
> stronger behavior. In section 5.6.1, the OpenJPA manual says:
>     "While the JPA specification says that you should not use rolled
>     back objects, such objects are perfectly valid in OpenJPA. You can
>     control whether the objects' managed state is rolled back to its
>     pre-transaction values with the openjpa.RestoreState configuration
>     property. none does not roll back state (the object becomes hollow,
>     and will re-load its state the next time it is accessed), immutable
>     restores immutable values (primitives, primitive wrappers, strings)
>     and clears mutable values so that they are reloaded on next access,
>     and all restores all managed values to their pre-transaction state."
>     
> In section 2.5.53, the OpenJPA manual identifies three values for the
> the openjpa.RestoreState value. It identifies "none" as the default
> value.
> In fact, two central statements in the above cited passages from the
> OpenJPA manual are not true.  In addition, the behavior in restoring
> fields is controlled at least in part by other factors.
> To begin with, a detached object will not reload any state. In the
> second instance, the default value appears to be "immutable" instead of
> "none".
> Two test cases were run with the entity class Dohickey. Dohickey has two
> string fields, lazy and eager, as well as an integer identity field.
> Both test cases use a new entity manager. In the first test case, the
> lazy field is dirtied in a newly found a Dohickey. In the second test
> case, the lazy field is dirtied after dirtying the eager field in a
> newly found Dohickey. In both test cases, the transaction is rolled
> back. The detached Dohickey is then tested for detachment, and for
> whether the values of the eager and lazy fields match the values in the
> database.
> Number Test case    RestoreState    Restored Eager  Restored Lazy
> ------+------------+---------------+--------------+--------------          
>  1     Lazy only     undefined       db value        dirty value
>  2     Lazy only     none            null            null
>  3     Lazy only     immutable       db value        dirty value
>  4     Eager first   undefined       db value        null
>  5     Eager first   none            null            null
>  6     Eager first   immutable       db value        null
> Test cases 1, 3, 4, and 6 indicate that the default value is likely
> "immutable". 
> Test cases 2 and 5 indicate that the "none" value behaves as described
> after correcting the statement that fields will be reloaded.
> The test cases indicate that the behavior for "immutable" setting does
> not work as expected, since the behavior depends on whether the field is
> eagerly or lazily loaded (and perhaps on fetch group configurations as
> well.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.