Run the Quarkus test suite against Oracle too: 55 dialect branches across 33 files are only ever tested on PostgreSQL

Aperta
  • Qualcosa non va?
#1,994 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
57/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
docker, java, postgresql, sql
Ambito
databases, testing

Direzione di ricerca

Start in vcell-rest with AgroalConnectionFactory.usePostgresql() and replace its quarkus.profile switch with a vcell.datasource config property (defaults preserving today's behavior). Then look at SQLCreateAllTables.getVCellTables() plus Table.getCreateSQL(DatabaseSyntax) for Oracle schema generation, and ArtemisTestResource as the model for a QuarkusTestResourceLifecycleManager starting gvenzl/oracle-free:23-slim-faststart (see also PR #1993's DatabaseCleanupOracleSqlTest). Done means a Quarkus_Oracle_IT regression group runs the existing ~79 Quarkus tests with vcell.datasource=oracle and passes — expect to fix dialect-branch failures it uncovers.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Every SQL statement VCell's database layer emits is exercised in CI only against PostgreSQL, and runs in production only against Oracle. The two are not the same statements: DbDriver and friends branch on DatabaseSyntax in 55 places across 33 files, and the Oracle side of every one of those branches is untested.

This came up while fixing #1992 (see #1993). That PR added Oracle coverage for one thing — the cleanup sweep — via a new Oracle_IT regression group. The same reasoning applies to the rest of the database layer, and it is now cheap enough to be worth doing.

Why this is a real gap, not a theoretical one

The dialect branches are not cosmetic. A sample:

  • MINUS vs EXCEPT in the unreferenced-row queries.
  • MathDescriptionDbDriver takes a completely different write path per dialect — updateCleanLOB on Oracle vs the PostgreSQL branch — so CLOB handling for math descriptions is only ever run one way in tests and the other way in production.
  • varchar2_CLOB_update and the LRG/SML column-splitting idiom throughout DbDriver.
  • Field.SQLDataType maps every column type per dialect; ImageDataTable, BrowseImageDataTable, CurveTable, MathModelTable all carry their own case ORACLE.

A defect on the Oracle side of any of these is invisible until it reaches production, which is exactly how #1992 and #1961 stayed open.

What it would take

Not a new profile name. The natural instinct is to add a dev2-style Quarkus profile, but AgroalConnectionFactory.usePostgresql() hardcodes a switch on quarkus.profile:

switch (activeProfile) {
    case "test", "dev": return true;   // postgres
    case "prod":        return false;  // oracle
    default: throw new IllegalStateException("Unexpected value: " + activeProfile);
}

A new profile name throws on that default until the switch learns it, and every future profile has to be added in two places. Better to key the datasource choice off its own config property (vcell.datasource=postgresql|oracle), leaving profiles orthogonal — the same test suite then runs under either database by flipping one property.

The schema is the cheap part. %test.quarkus.datasource.postgresql.devservices.init-script-path=scripts/init.sql points at a hand-maintained PostgreSQL script (79 CREATE TABLEs, bigint/text/numeric). No Oracle equivalent has to be written by hand: SQLCreateAllTables.getVCellTables() is public static, and Table.getCreateSQL(DatabaseSyntax) already emits per-dialect DDL. A test resource can build the Oracle schema directly from the table list. (Don't reuse SQLCreateAllTables.main — it opens a Swing JOptionPane confirmation, so it cannot run headless.)

The container. quarkus-jdbc-oracle and ojdbc11 are already vcell-rest dependencies, so nothing new is needed there. Quarkus devservices will not start one as things stand, because the Oracle datasource is declared quarkus.datasource.oracle.db-kind=other. Two options: change it to db-kind=oracle, or — probably better, since it leaves the production datasource block alone — add a QuarkusTestResourceLifecycleManager that starts gvenzl/oracle-free:23-slim-faststart and injects the JDBC URL. That is the pattern ArtemisTestResource already uses in this module, and #1993's DatabaseCleanupOracleSqlTest shows the image works: 55s from pull to a usable database on a GitHub runner, whole job 2m35s.

Where it should run

Not the fast lane — it roughly doubles the Quarkus suite (79 tests) and adds the image pull. It belongs beside Oracle_IT as a regression group, e.g. Quarkus_Oracle_IT, so the merge queue and the nightly gate it while every push stays fast.

Suggested order

  1. Replace the profile-name switch in AgroalConnectionFactory with a datasource config property, defaulting to today's behaviour. No test changes.
  2. Add an Oracle QuarkusTestResourceLifecycleManager that starts the container and builds the schema from getVCellTables() + getCreateSQL(ORACLE).
  3. Add the Quarkus_Oracle_IT regression group running the existing suite with the property flipped, and fix whatever it turns up. Expect the first run to find things — that is the point.

Related: #1992, #1961, PR #1993.

Lingua principale
Java
Stelle
140
Fork
35
Merge medio
17h 39m
PR unite (30g)
19

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di virtualcell/vcell

Tutte le issue di virtualcell/vcell

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.