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.
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.
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
>
