rzo1 opened a new pull request, #217: URL: https://github.com/apache/openjpa/pull/217
Reported by @solomax from the MySQL TCK run: a named `@SequenceGenerator` fails with *"Error instantiating named sequence … Your database dictionary does not support native sequences"* wherever the dictionary leaves `nextSequenceQuery` null. That is not MySQL-specific — it includes **Derby**, the default CI profile. `openjpa.Sequence` cannot help, because `SequenceMetaData.instantiate()` consults the configured system sequence only for the system sequence name, so a named generator always takes the plugin path. **Two commits, deliberately separate** (the first changes identity generation on databases people use, the second is a dictionary change): 1. `SequenceMapping.instantiate()` substitutes a table-backed sequence when the plugin resolves to `NativeJDBCSeq` with no properties and the dictionary has no `nextSequenceQuery`, gated on the dictionary property rather than a dictionary class, building a separate `SequenceMapping` rather than mutating shared metadata, and warning once per generator. It resolves where the sequence is resolved, so the runtime and the mapping tool agree — the `MappingTool` patch from the dev list fixes the tool while a plain EMF still fails. `IMPL_VALUE_TABLE`, not `IMPL_TABLE`: `ValueTableJDBCSeq` keys its counter row by name, so entities sharing a generator share a counter as they would with a real sequence, where `TableJDBCSeq` keys per class and would give each entity its own. `initialValue`/`allocationSize` travel on the `SequenceMetaData` and are asserted to survive. New `EmulateNativeSequences` compatibility option, default true — what it replaces is an unconditional failure, so nothing that works today changes; `false` restores the hard failure. 2. `MariaDBDictionary.connectedConfiguration()` sets `nextSequenceQuery` for server 10.3 and later, in the version-gated manner `PostgresDictionary` uses. There is no "explicitly set" flag for this property and I did not invent one; the gate is `nextSequenceQuery == null`, which is sound because the constructor leaves it null. Declaring sequence support pulled in two more things, both checked against a real server: `NOCACHE` on `CREATE SEQUENCE`, because `ALTER SEQUENCE … INCREMENT BY` flushes MariaDB default 1000-value cache, and a `getSequencesSQL()` that reads `INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = SEQUENCE`, since `INFORMATION_SCHEMA.SEQUENCES` does not exist before 10.6. Verified per server, sequence package and `TestNamedSequenceGenerator`: **Derby, H2, MySQL 8.0, MariaDB 10.2 and MariaDB 11.8 all green** — 10.2 takes the fallback and 11.8 the native path, so the version gate is exercised both ways. `TestMariaDBDictionary` 18/18. The query, kernel and jpql packages show identical failing class lists to pristine master on both CI profiles. Two rounds of review correction worth noting, since the evidence in the messages matters: the first version of the test asserted "expected a table backed sequence on MariaDB" and so failed 3 of 5 on 11.8 once commit 2 gave MariaDB sequences — the tests now ask the connected dictionary instead of assuming a platform; and the commit messages had quoted DDL OpenJPA never emits and claimed `MariaDBDictionary extends MySQLDictionary` (it extends `DBDictionary`) and that 11.x servers carry the `5.5.5-` prefix (dropped in 11.0 — read off the handshake of both servers). Those are corrected, and the one remaining synthetic test input is now labelled as such. -- 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]
