ptrdom opened a new issue, #531: URL: https://github.com/apache/pekko-persistence-r2dbc/issues/531
Split out of #94, as was done for MySQL (#158). MySQL and H2 (#517) are now supported, and I'd like to add Oracle next. akka-persistence-r2dbc has no Oracle support, so there's no upstream implementation to port; this would be new work. ### Licensing question (needs answering first) @pjfanning, could you advise on this before any code is written? - Driver: [`com.oracle.database.r2dbc:oracle-r2dbc`](https://github.com/oracle/oracle-r2dbc), dual-licensed under UPL 1.0 or Apache 2.0. UPL is Category A. - It depends on `com.oracle.database.jdbc:ojdbc11`. That driver's Maven POM gives its licence as the [Oracle Free Use Terms and Conditions (FUTC)](https://www.oracle.com/downloads/licenses/oracle-free-license.html), which isn't on the [ASF resolved-licence list](https://www.apache.org/legal/resolved.html). - Proposal: the dialect only uses SQL and the R2DBC SPI, so it shouldn't need any Oracle driver classes to compile. Both artifacts would then be **test-scope only**. Users would add `oracle-r2dbc` to their own application, and neither jar would be bundled in or required by our source or binary releases. - Precedent: apache/pekko-persistence-jdbc#8, where the checked-in `ojdbc6.jar` was replaced by a test-scope Maven dependency. pekko-persistence-jdbc still tests against `ojdbc11` in CI. Questions: 1. Is a test-scope dependency on `ojdbc11` (under FUTC) acceptable here, given it's resolved from Maven and not shipped? 2. If the dialect ever does need driver classes at compile time, would a `provided` dependency be acceptable, or should that be avoided? 3. Does either case need a LEGAL JIRA ticket, or is the pekko-persistence-jdbc precedent enough? ### Minimum Oracle version Which Oracle version should be the minimum? Feedback from anyone running Oracle would help. - **23ai (proposed):** - Has native `BOOLEAN`, so the existing `deleted = false` conditions work unchanged. - Has `CREATE TABLE IF NOT EXISTS` and `GROUP BY` on column aliases, which keeps the Oracle SQL close to the existing queries. - Can be tested with the free, multi-arch `gvenzl/oracle-free` image. - **19c:** still widely deployed, but: - `deleted` would become `NUMBER(1)`, with Oracle-specific conditions everywhere it's used; - the DDL scripts couldn't use `IF NOT EXISTS`; - the bucket queries would repeat their expressions in `GROUP BY` instead of grouping by alias; - CI would need an older image such as `gvenzl/oracle-xe:21`, since there's no free 19c image, so 19c itself wouldn't be tested directly. Starting with 23ai keeps the first version smaller, and 19c support could be added later if users ask for it. ### Proposed scope (once licensing is settled) - A new `oracle` dialect with Oracle DAOs for the journal, query, snapshot and durable state, following the MySQL approach. It would require `use-app-timestamp = on` and `db-timestamp-monotonic-increasing = on`, so the missing SQL `RETURNING` clause and the database interval arithmetic aren't needed. - Targets the minimum version agreed above (23ai proposed). - Oracle-specific handling: - `MERGE` for snapshot upserts; - `FETCH FIRST n ROWS ONLY` for paging; - tags stored as JSON, as for MySQL; - nullable manifest columns, because Oracle stores `''` as `NULL`. - DDL scripts plus a CI job using the multi-arch `gvenzl/oracle-free:23-slim-faststart` image. - The migration tool is out of scope. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
