[
https://issues.apache.org/jira/browse/OPENJPA-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137892#comment-18137892
]
ASF subversion and git services commented on OPENJPA-3064:
----------------------------------------------------------
Commit 77f4fa6833f8a6df83e7d1f32b895f96084ff7fb in openjpa's branch
refs/heads/OPENJPA-3059 from Richard Zowalla
[ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=77f4fa683 ]
[OPENJPA-3064] Fix decimal columns, EXTRACT(SECOND/WEEK) and dropping columns
on SQL Server (#265)
* [OPENJPA-3064] Keep decimal fractions and fix EXTRACT(WEEK) and
EXTRACT(SECOND) on SQL Server
SQL Server reads an unsized DECIMAL or NUMERIC as DECIMAL(18,0), and
SQLServerDictionary wrote no precision or scale for any decimal column,
so 2.5 was stored as 3. Keep the precision and scale of decimal columns,
and create a decimal column of a non integral Java type without a
precision as NUMERIC(38, scale), with scale 10 if the mapping gives none,
unless NumericTypeName or DecimalTypeName was configured or a
columnDefinition is used. Move the check for an unsized decimal column
from H2Dictionary to DBDictionary, as for MySQL and MariaDB.
Render EXTRACT(WEEK) as DATEPART(ISO_WEEK, x), the ISO-8601 week, and
add DATEPART(NANOSECOND, x) / 1000000000.0 to EXTRACT(SECOND) so that
the fraction of the second is kept.
* [OPENJPA-3064] Compare LOCAL TIME with the clock of the database in
TestJava8TimeTypes
testGetCurrentLocalTime expected a row created with the JVM clock to be
before LOCAL TIME, which is the clock of the database server, and failed
when the server runs in another time zone, for example a SQL Server
container in UTC queried from a JVM in a zone east of UTC at night.
Compare the rows with the time the database reports instead.
* [OPENJPA-3064] Drop the indexes and constraints of a column before the column
on SQL Server
When a table holds columns that the mapping does not know, for example
of a subclass that another test mapped to the same table, the schema
tool drops the mapped columns one by one instead of the table. SQL
Server refuses to drop a column that the primary key, a unique
constraint, an index, a default constraint or a foreign key of the
table depends on, while other databases drop these with the column.
Drop them first, as found in the catalog views, and then the column in
one transaction, so that nothing is dropped when the column cannot be
dropped.
> SQL Server: decimal scale, EXTRACT(SECOND/WEEK), current local time and
> shared test tables fail
> -----------------------------------------------------------------------------------------------
>
> Key: OPENJPA-3064
> URL: https://issues.apache.org/jira/browse/OPENJPA-3064
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Reporter: Richard Zowalla
> Assignee: Richard Zowalla
> Priority: Major
> Fix For: 4.2.0
>
>
> The test suite on Microsoft SQL Server ({{-Dtest-mssql-docker}}) has 13
> failures and 13 errors (4022 tests):
> * {{TestDecimalScale}}, {{TestUnarySign}}, {{TestArithmeticResultType}}:
> decimal values are stored rounded to integers ({{2.5 <> 3}}, {{-25.5 <>
> -26}}). Same cause as OPENJPA-3051 (H2), OPENJPA-3062 (MySQL, MariaDB) and
> OPENJPA-3063 (HSQLDB): a decimal column without a precision has scale 0
> ({{DECIMAL}} is {{DECIMAL(18, 0)}} on SQL Server).
> * {{TestEJBQLFunction.testExtractSecondKeepsFractionFromTime/Timestamp}}:
> {{EXTRACT(SECOND)}} drops the fraction ({{expected:<42.75> but was:<42.0>}}),
> see OPENJPA-3055.
> * {{TestExtractDateTimeField.testExtractWeek}}: {{expected:<[1, 52]> but
> was:<[1, 53]>}}, {{EXTRACT(WEEK)}} is not the ISO week, see OPENJPA-3037.
> * {{TestJava8TimeTypes.testGetCurrentLocalTime}} fails.
> * {{TestFlushModeAutoNavigation}}, {{TestTckFixes}},
> {{TestTreatJoinOnEmbeddable}}: setting up the schema fails with "The object
> 'PK__TPRODUCT__...' is dependent on column 'id'" ({{ALTER TABLE TPRODUCT DROP
> COLUMN id}}, {{ALTER TABLE FLUSH_ORDER DROP COLUMN ID}}, code 5074). Several
> test entities map the same table names ({{TPRODUCT}}, {{FLUSH_ORDER}}) with
> different columns, and the schema refresh tries to drop a primary key column.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
