[
https://issues.apache.org/jira/browse/OPENJPA-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138836#comment-18138836
]
ASF subversion and git services commented on OPENJPA-3034:
----------------------------------------------------------
Commit b6b6177aedf2c9e5b24983ca4ab755eaec5cd79e in openjpa's branch
refs/heads/OPENJPA-3034 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=b6b6177ae ]
[OPENJPA-3034] Use real sequences on Derby and SQL Server
Apache Derby (10.6+) and SQL Server (2012+) have sequence objects, but
neither dictionary declared a NextSequenceQuery, so a @SequenceGenerator
was backed by a row of the OpenJPA sequence table (OPENJPA-3014) and the
schema tool generated no CREATE/DROP SEQUENCE for it. The TCK tests
jpa22.se.generators.sequencegenerators and
se.schemaGeneration.annotations.sequenceGenerator expect those statements
in the generated scripts.
DerbyDictionary: NEXT VALUE FOR from 10.6 on, sequences created AS BIGINT,
DROP SEQUENCE ... RESTRICT as Derby requires, sequence reflection from
SYS.SYSSEQUENCES scoped to the current schema.
Derby has no ALTER SEQUENCE, so the INCREMENT BY of a sequence cannot be
adjusted to the allocation size of its generator, and the dictionary sets
disableAlterSeqenceIncrementBy. With that set, NativeJDBCSeq used to trust
the increment of the sequence: one that already existed with a smaller
INCREMENT BY than the allocation size made it hand out values the database
hands out as well. DBDictionary.getSequenceIncrement() now reads the
increment of a sequence (DerbyDictionary: from SYS.SYSSEQUENCES), and
NativeJDBCSeq only caches a block of values if the increment covers the
allocation size; otherwise, or if the sequence cannot be found, it draws
every value from the sequence and logs a warning saying so. Dictionaries
that cannot read the increment keep the previous behaviour, including the
warning about the disableAlterSeqenceIncrementBy property.
SQLServerDictionary: NEXT VALUE FOR from 2012 (major version 11) on,
sequence reflection from sys.sequences scoped to the default schema, and
an explicit START WITH 0 since a sequence otherwise starts at the minimum
of its type.
An explicitly configured NextSequenceQuery is left alone on both.
MySQL has no sequence objects, so the two TCK tests keep failing there on
the missing CREATE/DROP SEQUENCE statements. The TCK runner is not changed
to pass db.supports.sequence=false for MySQL: that would turn eleven tests
into passes without running them, nine of which do pass for real through
the sequence table fallback of OPENJPA-3014.
> Tests failing on several databases: sequence generator, timestamp, scalar
> expressions, mixed access
> ---------------------------------------------------------------------------------------------------
>
> Key: OPENJPA-3034
> URL: https://issues.apache.org/jira/browse/OPENJPA-3034
> Project: OpenJPA
> Issue Type: Sub-task
> Reporter: Richard Zowalla
> Priority: Major
>
> These tests fail on more than one database, which suggests a common cause:
> * {{sequenceGeneratorTest}}: Derby, MySQL, SQL Server. Check with
> OPENJPA-3014 (named sequence generator backed by a table where there are no
> sequences).
> * {{Client4.timestampFieldTest}}, {{timestampPropertyTest}}: MySQL, SQL
> Server (fractional seconds?)
> * {{scalarExpressionsTest}} ({{Client}} and {{Client1}}): Derby, SQL Server
> * {{Client2.mixedAccessTest}}, {{Client3.transientTest}},
> {{Client2.transientTest}}: Derby, SQL Server
> * {{cascadeAllMX1Test2}}, {{persistMX1Test2}}: Derby, SQL Server
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
