[daniellansun]

Continues #2658 .

Summary

Continues / Relates to #2658 (Paul King's GEP-26 reference implementation: GINQ SQL / jOOQ).

This branch rebases Paul's three reference commits onto current master, resolves drift (including verification-metadata.xml), pins checksums for the SQL provider dependencies, adds opt-in mixed-mode, finishes Phase 5 polish, pins H2 2.5.252 for ginq-sql tests, and applies a faithfulness audit so SQL results match Groovy/collection semantics where the GEP requires it.

Credit: Paul King for the GEP-26 reference implementation (#2658).

Phase 5 / mixed mode / audit highlights

• Default remains strict; opt-in mixedMode: true.
• Function push-down covers the GEP initial vocabulary plus concat, isEmpty, abs/floor/ceil/round, constant ranges on in.
• Native dialect: ansi (default), h2, postgres, mysql, mariadb, sqlite.
• Audit fixes: real division for /, null-safe contains/LIKE, empty in/!in, COALESCE(SUM(...),0), jOOQ schema.table split.
• Tests use H2 2.5.252 only (test-only dependency).

Tests (local, last tip)

• :groovy-ginq-sql:test — 137 passed
• :groovy-ginq:test — 665 passed
• Module checkstyleGate / codenarcGate for ginq + ginq-sql — passed

Out of scope / deferred (per GEP)

• Window functions, type-driven table inference, ORM, full native dialect breadth, table(…) helper, jOOQ Record results / runtime DSLContext, async/streaming.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

[Copilot]

🟡 Changes recommended

Several moderate active findings remain in SQL rendering and provider selection, including unsafe table-name handling, incorrect NULL membership semantics, unsupported SQLite functions, and unreliable jOOQ auto-detection.

4 open issues

• Validate table names in mixed-mode selectAll · New
• Handle null members in IN and NOT IN predicates · New
• Reject or emulate FLOOR and CEILING for SQLite · New
• Check jOOQ availability before selecting the SQL provider · New

_{Review effort: Lite}

[paulk-asert]

I've been through this with 7.0.0-alpha-1 in mind and I think it can go in as is, as an incubating optional module, with the smaller items handled in later alphas.

Checked: :groovy-ginq:test (665) and :groovy-ginq-sql:test (207, on the #3167 tip which includes this) are green locally; the Copilot findings and Jochen's two comments are addressed at the tip; jOOQ stays compileOnly, H2 test-only, nothing new is bundled. The additive groovy-ginq changes (provider/dataSource, GinqProvider, the two GinqAstVisitor defaults) are all under the incubating provider extension point, which is the right place for them.

CI: the macOS red is the known 60-minute stall. Please rebase onto master before merging: the branch is ~40 commits behind and lacks 7155266 (the cache-scrub fix), which is exactly what failed on Windows for #3167 after a successful Gradle run.

For later alphas (none blocking):

• MixedPlan and Untranslatable are the only public types without @Incubating.
• A note in the guide that SQL result types can differ from in-memory ones (e.g. avg is double from H2, BigDecimal in memory).
• GEP-26 should be updated to say mixed mode is implemented.

While comparing providers I also hit two pre-existing collection-provider bugs (denseRank() over(orderby e.prop) without partitionby NPEs, and a range frame NPEs on a null key); I'll raise those separately, they're unrelated to this PR.

[daniellansun]

Thanks Paul — landed the later-alpha items in this PR and fixed the two collection-provider NPEs you hit while comparing providers:

• MixedPlan / Untranslatable now @Incubating
• ginq-userguide note that SQL result types can differ from in-memory (e.g. H2 AVG → Double vs BigDecimal)
• GEP-26 site updated for mixed mode implemented: GEP-26: document mixed-mode execution as implemented groovy-website#89 (window functions still deferred)
• denseRank() over(orderby …) without partitionby, and range frames on a null order key, no longer NPE

Tip is e8244ce; CI green. Happy to rebase onto master (incl. the cache-scrub) whenever you’re ready to merge.

[blackdrag]

(1)

from e in 'employees'
join d in 'departments' on e.deptId == d.id
select e.name.reverse(), d.name.reverse() // double use of name

This should force mixed mode. The source records are reconstructed independently, but their column labels originate from the SQL projection. If the database returns duplicate column labels within a source projection, some source information could be lost. The design assumes that JDBC metadata provides a stable representation of the original source schema. That assumption is not universally safe. JDBC drivers and database systems can differ in their treatment of labels, duplicate names, case folding and quoting. naming the columns could help, even though it requires remapping later. Also in that map __ginq_mixed_key could collide with a database column of the same name.

There is also a lot about the mapping of the operations... I think a documented list of intentional differences would help to understand not only what is mapped, but also how semantics may differ (exact semantics depend on the db of course if mapped to a db operation. Maybe something like:

Groovy operation: String.length()
SQL mapping: CHAR_LENGTH
Constraints:
  - compatible character-counting semantics
  - compatible treatment of null
  - compatible type conversion

(2)
I think there are also a lot of issues around null-handling

def wanted = null

GQL(provider: 'native-sql', dataSource: db) {
    from e in 'employees'
    where e.deptId == wanted
    select e.name
}

This will most likely result in WHERE e.deptId = ?, but it will not select employees where deptId is null in the table. isNullLiteral fails to recognize this, since this is not a null literal to begin with.
where e.deptId !in 1..3 is translated to NOT (e.deptId >= 1 AND e.deptId <= 3). For a null department ID, the comparisons evaluate to UNKNOWN, and negating UNKNOWN remains UNKNOWN. e.deptId IS NULL OR (e.deptId < 1 OR e.deptId > 3) would represent Groovy semantics better.

I am not saying this must work according to Groovy semantics, but it needs documentation when it does and when not.

(3)

def suffix = '!'

from e in 'employees'
select e.name + suffix

isStringy() does not recognize the captured string variable and silently generates arithmetic addition. The implementation depends a lot on recognizes cases like this, but cannot always do so. Maybe we should consider rejecting some constructions. Having clear limits is better than unpredictable behavior

(4)
Currently it works like this: Groovy AST -> GinqToSqlTranslator -> SQL IR -> Dialect-specific renderer -> SQL text

While reasonable, if a translation succeeds in producing a SqlFunction, a particular dialect might still not support the corresponding function. FlOOR and CEILING have been fixed, but I think the mixed-mode planner needs general mechanism for considering dialect capabilities when determining which clauses can be pushed down. Or there must be a way for the dialect renderer to fall back to non-SQL implementation.

[daniellansun]

Jochen, thanks for the review. I agree with the direction: a mapping that cannot be decided should be rejected or left in memory, not emitted as a guess. The four points are handled as follows.

Mixed-mode rows. A pushed join is no longer reconstructed from the labels of alias.* on the joined result. Each source is probed, the prefix is re-run with those columns named explicitly, and the values are read back by ordinal onto that source's own labels. e.name.reverse(), d.name.reverse() therefore keeps both names. Duplicate labels within one source are rejected rather than dropped, because JDBC labels, case folding and quoting are not a stable copy of the table. The ordinal that re-aligns the join is not stored as a column, so a real column named __ginq_mixed_key stays readable.

Nulls. == and != against a null literal are still IS NULL / IS NOT NULL. Every other comparison is null-safe (IS NOT DISTINCT FROM, MySQL <=>, SQLite IS), so where e.deptId == wanted matches a null deptId when wanted is null. !in on a list or a constant range keeps null rows (IS NULL OR outside the bounds / the list). Comparisons < <= > >=, and AND / OR / NOT, stay SQL three-valued logic: a null is not ordered below every value the way Groovy would order it. The user guide now lists each mapping and where the semantics differ. The exact result of a mapped function still depends on the database.

+ and text methods. e.name + suffix is no longer arithmetic. + is concatenation only when the left side is text, or a column stands beside a string literal, and addition only when a number anchors it (e.salary + 1) or both sides are numbers. A captured variable is pushed only when its declared type is text or numeric, or it is cast ((suffix as String), (bonus as int)). Two columns are not pushed. length() and the other text methods are pushed only for a column or a value known to be text. Otherwise strict mode rejects the construct and mixed mode evaluates it in memory.

Dialects. Whether a function can be rendered is one table, shared by the translator and both renderers. SQLite does not include FLOOR or CEILING. Strict mode rejects those calls. Mixed mode leaves the clause that uses them in memory and can still push the rest. A function that is only spelled differently, such as CHAR_LENGTH as LENGTH, is still pushed. Adding another gap is an entry in that table, not a special case in the planner. ntile uses integer division, so it does not depend on FLOOR.