Hello Richard, On Fri, 9 Oct 2026 at 14:58, Richard Zowalla <[email protected]> wrote: > > Hi Maxim, > > Good news: no emulation needed, and no growing table either. > > Neither MySQLDictionary nor MariaDBDictionary sets nextSequenceQuery, so > NativeJDBCSeq.endConfiguration() throws for any @SequenceGenerator. But > OpenJPA already ships a table-backed sequence: SequenceMapping.IMPL_TABLE / > IMPL_VALUE_TABLE, implemented by TableJDBCSeq, which keeps a single row per > sequence in OPENJPA_SEQUENCE_TABLE (column SEQUENCE_VALUE) and updates it in > place. That is the same approach Hibernate and EclipseLink take on MySQL, so > AUTO_INCREMENT is not required and nothing grows. > > I would split it in two, because the two dbms are different: > > MariaDB can do it natively. MariaDB 10.3 and later has real sequence objects > (CREATE SEQUENCE, NEXT VALUE FOR seq, NEXTVAL(seq)), and you are running > 11.8. So MariaDBDictionary.connectedConfiguration() can set nextSequenceQuery > once the server reports >= 10.3, following the version-gated pattern > PostgresDictionary already uses for storeCharsAsNumbers, and leave the older > versions alone. That should make the sequence TCK tests pass on MariaDB > without any mapping change. > > MySQL has no sequences at any version, so a @SequenceGenerator has to fall > back to the table sequence. Interestingly part of it is already there: > AnnotationPersistenceMetaDataParser does both GenerationType.TABLE and > GenerationType.SEQUENCE through the system openjpa.Sequence setting when the > generator is unnamed. The gap would be a named generator on a dictionary > without native sequences, which currently fails instead of falling back. > > As a workaround for your branch right now, before any code change, you can > point the named generator at the table implementation, e.g. > > openjpa.Sequence: table(Table=OPENJPA_SEQUENCE_TABLE)
this would be hard to implement for TCK :( we do pass params via <jpa.provider.implementation.specific.properties> which has `:` delimiter but inside the key it has `=` delimiter :( and we already passing `openjpa.Sequence=time` .... so the only options are: System property and code modification :) I'll try to modify the code > > for the unnamed case, or give the generator an explicit table implementation > in the mapping. > > The MariaDB version check would be low risk, the MySQL fallback changes > identity generation behaviour on a database people are using, so I would keep > them as separate commits (and probably separate review) even if they share > one issue. > > Hope it helps > Richard > > > > Am 09.10.2026 um 05:45 schrieb Maxim Solodovnik <[email protected]>: > > > > There is great progress :)) > > Failing list is reduced :)) > > > > Some tests are failing due to: > > > > ``` > > SEVERE: Exception encountered while creating seq: > > <openjpa-4.2.0-SNAPSHOT-r832b5cdM fatal user error> > > org.apache.openjpa.persistence.ArgumentException: Error instantiating > > named sequence "SEQGENERATOR": Your database dictionary does not > > support native sequences. To tell the dictionary how to select > > sequence values, use: > > openjpa.jdbc.DBDictionary: NextSequenceQuery="SELECT NEXT VALUE FOR > > "SEQGENERATOR" > > Where the above string is replaced with the proper SQL for your database. > > at > > org.apache.openjpa.jdbc.kernel.NativeJDBCSeq.endConfiguration(NativeJDBCSeq.java:190) > > ``` > > > > I guess SEQUENCE can be emulated with AUTOINCREMENT > > https://dev.mysql.com/doc/refman/8.0/en/innodb-auto-increment-handling.html > > But having growing table seems to be overkill .... > > > > On Thu, 8 Oct 2026 at 21:08, Maxim Solodovnik <[email protected]> wrote: > >> > >> It seems regular MySql tests are broken :( > >> > >> ``` > >> [ERROR] Failures: > >> [ERROR] > >> TestContainerSpecCompatibilityOptions>AbstractPersistenceTestCase.run:213->AbstractPersistenceTestCase.runBare:553->AbstractPersistenceTestCase.runBare:577->AbstractPersistenceTestCase.runTest:590->testLegacyDefaultMapKeyColumnName:471->assertSQLFragnments:932 > >> None of the following 3 SQL > >> [ERROR] > >> TestBiDirectionalJoinTable>AbstractPersistenceTestCase.run:213->AbstractPersistenceTestCase.runBare:553->AbstractPersistenceTestCase.runBare:577->AbstractPersistenceTestCase.runTest:590->testBulkDelete:138->SQLListenerTestCase.assertSQL:74 > >> Expected regular expression > >> [ERROR] > >> TestBulkDeleteCompositeId>AbstractPersistenceTestCase.run:213->AbstractPersistenceTestCase.runBare:553->AbstractPersistenceTestCase.runBare:577->AbstractPersistenceTestCase.runTest:590->testCompositeKeyCandidateWithoutCriteria:65->SQLListenerTestCase.assertSQL:74 > >> Expected regular expression > >> [ERROR] > >> TestBulkDeleteDependentFields>AbstractPersistenceTestCase.run:213->AbstractPersistenceTestCase.runBare:553->AbstractPersistenceTestCase.runBare:577->AbstractPersistenceTestCase.runTest:590->testUnfilteredDeleteCleansOwnedTablesOfDependentFields:140->SQLListenerTestCase.assertSQL:74 > >> Expected regular > >> [ERROR] > >> TestBulkDeleteJoinTable>AbstractPersistenceTestCase.run:213->AbstractPersistenceTestCase.runBare:553->AbstractPersistenceTestCase.runBare:577->AbstractPersistenceTestCase.runTest:590->testBulkDeleteWithoutCriteriaEmptiesOwnedTables:58->SQLListenerTestCase.assertSQL:74 > >> Expected regular expression > >> [ERROR] > >> TestBulkDeleteSubclassJoinTable>AbstractPersistenceTestCase.run:213->AbstractPersistenceTestCase.runBare:553->AbstractPersistenceTestCase.runBare:577->AbstractPersistenceTestCase.runTest:590->testBulkDeleteThroughBaseClass:51->SQLListenerTestCase.assertSQL:74 > >> Expected regular expression > >> > >> [INFO] OpenJPA Persistence JDBC ........................... FAILURE [ > >> 01:33 h] > >> > >> [ERROR] Tests run: 3761, Failures: 6, Errors: 0, Skipped: 0 > >> ``` > >> > >> On Thu, 8 Oct 2026 at 13:37, Maxim Solodovnik <[email protected]> wrote: > >>> > >>> Hello Richard, > >>> > >>> On Thu, 8 Oct 2026 at 13:24, Richard Zowalla <[email protected]> wrote: > >>>> > >>>> Hi Maxim, > >>>> > >>>> the truncation is a consequence of it, not a separate problem. > >>>> > >>>> DBDictionary.storeCharsAsNumbers still defaults to true > >>>> (DBDictionary:327), and only DB2 (DB2Dictionary:124) and PostgreSQL > >>>> (PostgresDictionary:151) switch it off. > >>>> MySQL inherits the legacy default, so: > >>>> > >>>> - getPreferredType() maps JavaTypes.CHAR to Types.INTEGER > >>>> (DBDictionary:2006) — that is the "Given column: Type: integer" in your > >>>> warning, and > >>>> - setChar() takes the numeric branch because the mapped column reports > >>>> as INTEGER-compatible (DBDictionary:1285) and does setInt(stmnt, idx, > >>>> (int) val). > >>>> > >>>> So for > >>>> > >>>> @Column(name = "CHARDATA") > >>>> protected char characterData; > >>>> > >>>> we send 65 into the TCK's CHARDATA CHAR column, and two digits do not > >>>> fit one character: code 1406, "Data too long for column 'CHARDATA'". > >>>> > >>>> Workaround for your branch, no code change needed: > >>>> > >>>> openjpa.jdbc.DBDictionary=mysql(StoreCharsAsNumbers=false) > >>>> > >>>> However, I would fix it the way we did for PostgreSQL in OPENJPA-2971: > >>>> have MySQLDictionary set storeCharsAsNumbers = false in the constructor, > >>>> keep the isStoreCharsAsNumbersExplicit() > >>>> so a value a user set explicitly is never overwritten, and add a > >>>> migration note — existing MySQL schemas created by earlier OpenJPA > >>>> releases have INTEGER columns for > >>>> char fields and will need StoreCharsAsNumbers=true to keep working. > >>> > >>> I'll give it a try and will write back :) > >>> Thanks a million for your help! :) > >>> > >>>> > >>>> That is exactl OPENJPA-3001. > >>>> > >>>> On the schema generation: drop-and-create cannot help here, and the > >>>> error you get comes from a different place. > >>>> "Table ... has a foreign key to table ... that has not been generated" > >>>> is thrown by SchemaGenerator:885 while reading the > >>>> live database metadata; it fires when a foreign key in the existing > >>>> schema points at a table that is not part of the group being generated. > >>>> > >>>> With leftover tables from other TCK persistence units in the same > >>>> database, any subset run trips it. > >>>> > >>>> Since the TCK ships its own DDL, I would not let OpenJPA generate the > >>>> schema for a TCK run at all. > >>>> A clean database per run (DROP DATABASE / CREATE DATABASE, or a schema > >>>> per PU) is more reliable > >>>> than asking the schema tool to reconcile. Once the column type is right, > >>>> the incompatibility warning and the truncation, should disappear. > >>> > >>> Actually current script drops all local data at docker stop > >>> https://github.com/apache/openjpa/commit/db9c64be252643555803988f3330d8b32a09dd5a > >>> ``` > >>> <keepContainer>false</keepContainer> > >>> <removeVolumes>true</removeVolumes> > >>> ``` > >>> > >>>> > >>>> Best regards, > >>>> Richard > >>>> > >>>> On 2026-10-07 06:10 UTC Maxim Solodovnik wrote: > >>>>> Hello All, > >>>>> > >>>>> I'm trying to investigate TCK failures with Mysql DB > >>>>> > >>>>> I'm investigating 'Data truncation: Data too long for column' class of > >>>>> problems > >>>>> I've notices these errors are coupled with warnings like: > >>>>> ``` > >>>>> 19 WARN [main] openjpa.jdbc.Schema - Existing column "CHARDATA" on > >>>>> table "DATATYPES" is incompatible with the same column in the given > >>>>> schema definition. Existing column: > >>>>> Full Name: DATATYPES.CHARDATA > >>>>> Type: char > >>>>> Size: 1 > >>>>> Default: null > >>>>> Not Null: false > >>>>> Given column: > >>>>> Full Name: DATATYPES.CHARDATA > >>>>> Type: integer > >>>>> Size: 0 > >>>>> Default: null > >>>>> Not Null: false > >>>>> ``` > >>>>> > >>>>> So my guess was: schemaTool need to be instructed to drop/create > >>>>> existing table so column definition will be updated to have correct > >>>>> type > >>>>> > >>>>> I've tried to add > >>>>> `jakarta.persistence.schema-generation.database.action=drop-and-create` > >>>>> (as well as > >>>>> `:jakarta.persistence.schema-generation.database.action=drop-and-create:jakarta.persistence.schema-generation.scripts.action=drop-and-create`) > >>>>> > >>>>> But got `Table "{0}" has a foreign key to table "{1}" that has not been > >>>>> \ > >>>>> generated. You must run the schema generator on all inter-related > >>>>> tables \ > >>>>> at once.` errors instead :( > >>>>> > >>>>> Any help is appreciated :))) > >>>>> > >>>>> I'm playing at `tck-mysql` branch :)) > >>>>> > >>>>> > >>>>> -- > >>>>> Best regards, > >>>>> Maxim > >>>>> > >>> > >>> > >>> > >>> -- > >>> Best regards, > >>> Maxim > >> > >> > >> > >> -- > >> Best regards, > >> Maxim > > > > > > > > -- > > Best regards, > > Maxim > -- Best regards, Maxim
