openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Lee (Resolved) (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (OPENJPA-2069) Natvie sequence problems uncovered after OPENJPA-1376
Date Mon, 14 Nov 2011 15:45:51 GMT

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

Albert Lee resolved OPENJPA-2069.
---------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2.0
    
> Natvie sequence problems uncovered after OPENJPA-1376
> -----------------------------------------------------
>
>                 Key: OPENJPA-2069
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-2069
>             Project: OpenJPA
>          Issue Type: Bug
>          Components: jdbc, kernel
>    Affects Versions: 2.1.2, 2.2.0
>            Reporter: Albert Lee
>            Assignee: Albert Lee
>             Fix For: 2.2.0
>
>
> After OPENJPA-1376 commits, it uncovered a few issues, some old and some new.
> 1. Backward compatibility - Previous, openjpa relies on the native sequence to provide
the next value based on the sequence's INCREMENT BY setting. Now that openjpa manages the
next sequence value and allocation size, if the db sequence is manually created that does
not match the application's increment and allocation size, committing a new entity may result
a constraint violation exception when new sequence value is requested that crossed the allocation
boundary.  This behavior is indirectly documented in the migration consideration section in
the user manual, but it would be better if this can be handled automatically or at least to
provide a compatibility option to honor previous behavior.
> 2. Initial value always start with the same value (default to 1) - In NativeJDBCSeq,
the _initial, _increment and _allocate are used for the CREATE SEQUENCE generation for SynchronizeMapping
function. For existing db sequence, next returns whatever managed by the db sequence. After
the commit, next will first return the_nextValue value in NativeJDBCSeq until _maxValue is
reached, then it go to db to get the sequence's next value, which may be ways off from the
current _maxValue.
> 3. _nextValue not handled proper when crossing _allocate boundary - When NativeJDBCSeq's
_nextValue exceeds the _maxValue boundary, it queries db's sequence for the next incremental
value and assign directly as the next return value. It works for incrementBy = 1 but for some
value (e.g. 3), the difference of the before and after cross boundary values may NOT be the
_increment value.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message