rzo1 opened a new pull request, #245: URL: https://github.com/apache/openjpa/pull/245
https://issues.apache.org/jira/browse/OPENJPA-3033 The TCK failed on Derby and SQL Server because OpenJPA stores `char` fields as their code point: Derby wrote `'a'` as `97` into the TCK's `CHAR(1)` column (`22001`), SQL Server failed to read `'*'` as INTEGER. - `StoreCharsAsNumbers` now defaults to `false` on Derby, H2 and SQL Server, as on PostgreSQL 9+ (OPENJPA-2971), MySQL (OPENJPA-3001) and DB2. An explicit `StoreCharsAsNumbers=true` still wins (applied after the dictionary default, not reset in `connectedConfiguration()`). - A generated column for a `char`/`Character` field without explicit length is now `CHAR(1)` instead of `CHAR(255)`, which Derby rejected. - Migration note (new section `jpa_4.2_StoreCharsAsNumbers`) and reference guide: existing schemas with INTEGER char columns need `StoreCharsAsNumbers=true`; the reverse mapping tool now generates `char` fields on these databases. `TestStoreCharsAsNumbersDefaults` (defaults and explicit override per dictionary) and `TestCharStorage` (OpenJPA-created schema, pre-created `CHAR(1)` table like the TCK, explicit override). Full suite passes on Derby and H2; `TestCharStorage` also on SQL Server 2022. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
