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
