feat: Advanced Update and Delete support (CTEs, Order, Limit)

[cungminh2710]

Enhanced Rain ORM's Update and Delete query builders to support WITH (CTEs), ORDER BY, and LIMIT clauses. This parity improvement allows developers to write more complex data modification queries for MySQL and SQLite, where these features are natively supported. The implementation includes dialect-aware feature gating and refactored common rendering logic to ensure consistency across the query builder.

---

PR created automatically by Jules for task 347139410859395563 started by @cungminh2710

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[greptile-apps]

Greptile Summary

This PR extends UpdateQuery and DeleteQuery with With (CTEs), OrderBy, and Limit support, gated behind new per-dialect feature flags (FeatureUpdateOrder, FeatureUpdateLimit, FeatureDeleteOrder, FeatureDeleteLimit). The shared writeCTEs / writeOrderLimit helpers consolidate logic that was previously duplicated in SelectQuery, and the SelectQuery.limit / offset fields are migrated from int to *int to distinguish "not set" from "explicitly zero".

• New features for UPDATE/DELETE: CTEs, ORDER BY, and LIMIT are now supported on MySQL and SQLite; Postgres correctly returns an error for those clauses.
• Dialect updates: MySQL gains FeatureCTE (MySQL 8.0+); all three built-in dialects add FeatureUnlimited; LimitOffset guards changed from limit > 0 to limit >= 0 so an explicit LIMIT 0 is now rendered.
• SELECT refactor: limit/offset fields changed to *int; this correctly resolves the "set vs. not set" ambiguity for write queries but introduces a silent semantic change on SELECT — callers who previously called .Limit(0) as a no-op will now receive LIMIT 0 (zero rows returned).

Confidence Score: 4/5

Safe to merge for UPDATE/DELETE paths; the SELECT refactor carries a silent API change that could cause existing callers to get empty result sets instead of full ones.

The write-query additions (CTEs, ORDER BY, LIMIT on UPDATE/DELETE) are well-tested and the dialect feature gating is correct. The risky part is the SELECT refactor: migrating limit to *int changes the meaning of .Limit(0) from "no limit" to "return zero rows" with no deprecation path or documentation. A caller whose limit variable happens to be zero will now silently receive no data from a SELECT instead of all rows.

pkg/rain/query_select.go — the Limit(0) semantic change is undocumented and has no test coverage in the existing suite.

Important Files Changed

Filename	Overview
pkg/rain/query_common.go	Adds shared writeCTEs and writeOrderLimit helpers used by all three query types; writeOrderLimit correctly gate-checks dialect features for ORDER BY and LIMIT
pkg/rain/query_select.go	Refactors SELECT to use shared helpers and changes limit/offset to *int — Limit(0) now emits LIMIT 0 instead of being a no-op, which is a silent breaking change for callers who relied on 0 meaning "no limit"
pkg/rain/query_update.go	Adds CTE (With), OrderBy, and Limit support for UPDATE; dialect feature checks correctly gate MySQL/SQLite-only clauses
pkg/rain/query_delete.go	Adds CTE (With), OrderBy, and Limit support for DELETE; ordering relative to WHERE and RETURNING clauses is correct
pkg/dialect/mysql.go	Adds CTE/UpdateOrder/UpdateLimit/DeleteOrder/DeleteLimit/Unlimited features; changes LimitOffset guard from limit > 0 to limit >= 0 so explicit LIMIT 0 is now rendered
pkg/dialect/feature.go	Adds five new feature flags; FeatureUnlimited is used as a sentinel in writeOrderLimit to skip feature checks for SELECT, and HasFeature now correctly handles a zero feature argument

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[ToSQL called] --> B{Query type}
    B --> |SELECT| C[writeCTEs featureOrder=FeatureUnlimited featureLimit=FeatureUnlimited]
    B --> |UPDATE| D[writeCTEs featureOrder=FeatureUpdateOrder featureLimit=FeatureUpdateLimit]
    B --> |DELETE| E[writeCTEs featureOrder=FeatureDeleteOrder featureLimit=FeatureDeleteLimit]
    C --> F[writeOrderLimit]
    D --> F
    E --> F
    F --> G{featureOrder == FeatureUnlimited?}
    G --> |Yes - SELECT| H[Skip ORDER BY check]
    G --> |No - UPDATE/DELETE| I{HasFeature ORDER flag?}
    I --> |No - e.g. Postgres| J[Return error]
    I --> |Yes - MySQL/SQLite| H
    H --> K{featureLimit == FeatureUnlimited?}
    K --> |Yes - SELECT| L[Skip LIMIT check]
    K --> |No - UPDATE/DELETE| M{HasFeature LIMIT flag?}
    M --> |No - e.g. Postgres| N[Return error]
    M --> |Yes - MySQL/SQLite| L
    L --> O[dialect.LimitOffset limit=-1 if nil else ptr value]
    O --> P[Emit clause if non-empty]

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
pkg/rain/query_select.go:158-163
**`Limit(0)` on SELECT now emits `LIMIT 0` — silent breaking change**

Before this PR `SelectQuery.limit` was `int` with a zero default, and `LimitOffset(0, 0)` always returned `""` (all three dialect implementations guarded with `limit > 0`). As a result, calling `.Limit(0)` was a no-op: all rows were returned. After this PR the field is `*int`, so `.Limit(0)` stores a non-nil pointer; `writeOrderLimit` then calls `LimitOffset(0, 0)` which now returns `"LIMIT 0"` (zero rows returned).

Any caller that relied on `Limit(0)` to mean "no limit" — for example a config-driven value that defaults to zero — will now silently receive an empty result set on every dialect instead of all rows. There is no test covering this case and no mention of the breaking change in the PR description.

_{Reviews (2): Last reviewed commit: "refactor(rain): improve ORDER BY/LIMIT s..." | Re-trigger Greptile}

[cungminh2710]

@jules Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

Issue 1 of 3

pkg/rain/query_common.go:124-128
The featureOrder != 0 guard means that when featureOrder is accidentally passed as 0 for a new query type, ORDER BY will be silently permitted on every dialect — including those that do not support it. The simpler and safer design is to treat 0 as "always reject" (or always permit with an explicit sentinel), making wrong-zero-default impossible. For the current callers this works correctly, but the invariant is fragile: a future caller that forgets to supply the feature will bypass dialect enforcement without any compile-time signal.

func writeOrderLimit(ctx *compileContext, order []schema.OrderExpr, limit int, offset int, featureOrder, featureLimit dialect.Feature) error {
	if len(order) > 0 {
		if featureOrder != 0 && !dialect.HasFeature(ctx.dialect.Features(), featureOrder) {
			return fmt.Errorf("rain: ORDER BY is not supported for this query type in %s dialect", ctx.dialect.Name())
		}
		// Note: featureOrder == 0 means "no dialect gate for ORDER BY" (used by SELECT).
		// New callers must explicitly supply the correct feature constant.

Issue 2 of 3

pkg/rain/query_update.go:73-76
Limit(0) silently produces no LIMIT clause

writeOrderLimit skips the LIMIT block when limit <= 0, so .Limit(0) is silently treated the same as not calling Limit at all. On a write query this is a higher-risk footgun than on SELECT: a caller whose limit variable happens to be zero (e.g., read from config) will silently update every matching row instead of zero rows. Consider returning an error for limit < 0 and treating limit == 0 as "emit LIMIT 0", or at minimum documenting that zero means unbounded. The same applies to DeleteQuery.Limit.

Issue 3 of 3

pkg/rain/query_common.go:124-158
Behavior change for SELECT on custom dialects without FeatureOffset

The old writeOrderLimit method always called dialect.LimitOffset(limit, offset) and used its return value — including for dialects that do not advertise FeatureOffset. The new shared function now returns an error instead when limit > 0 || offset > 0 and the dialect lacks FeatureOffset. For all three built-in dialects this is harmless (all have the flag), but any custom Dialect implementation that previously rendered a LIMIT clause without setting FeatureOffset will now receive a hard error on existing SELECT queries. Worth a note in a CHANGELOG or migration guide if external dialect implementations are supported.

[google-labs-jules]

@jules Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

Issue 1 of 3

pkg/rain/query_common.go:124-128
The featureOrder != 0 guard means that when featureOrder is accidentally passed as 0 for a new query type, ORDER BY will be silently permitted on every dialect — including those that do not support it. The simpler and safer design is to treat 0 as "always reject" (or always permit with an explicit sentinel), making wrong-zero-default impossible. For the current callers this works correctly, but the invariant is fragile: a future caller that forgets to supply the feature will bypass dialect enforcement without any compile-time signal.

func writeOrderLimit(ctx *compileContext, order []schema.OrderExpr, limit int, offset int, featureOrder, featureLimit dialect.Feature) error {
	if len(order) > 0 {
		if featureOrder != 0 && !dialect.HasFeature(ctx.dialect.Features(), featureOrder) {
			return fmt.Errorf("rain: ORDER BY is not supported for this query type in %s dialect", ctx.dialect.Name())
		}
		// Note: featureOrder == 0 means "no dialect gate for ORDER BY" (used by SELECT).
		// New callers must explicitly supply the correct feature constant.

Issue 2 of 3

pkg/rain/query_update.go:73-76
Limit(0) silently produces no LIMIT clause

writeOrderLimit skips the LIMIT block when limit <= 0, so .Limit(0) is silently treated the same as not calling Limit at all. On a write query this is a higher-risk footgun than on SELECT: a caller whose limit variable happens to be zero (e.g., read from config) will silently update every matching row instead of zero rows. Consider returning an error for limit < 0 and treating limit == 0 as "emit LIMIT 0", or at minimum documenting that zero means unbounded. The same applies to DeleteQuery.Limit.

Issue 3 of 3

pkg/rain/query_common.go:124-158
Behavior change for SELECT on custom dialects without FeatureOffset

The old writeOrderLimit method always called dialect.LimitOffset(limit, offset) and used its return value — including for dialects that do not advertise FeatureOffset. The new shared function now returns an error instead when limit > 0 || offset > 0 and the dialect lacks FeatureOffset. For all three built-in dialects this is harmless (all have the flag), but any custom Dialect implementation that previously rendered a LIMIT clause without setting FeatureOffset will now receive a hard error on existing SELECT queries. Worth a note in a CHANGELOG or migration guide if external dialect implementations are supported.

I have addressed all three feedback items:

1. Strict Dialect Gating: Modified writeOrderLimit to treat a zero-value feature as "deny" rather than "permit". This ensures all callers must explicitly opt into dialect feature enforcement. I also introduced a FeatureUnlimited sentinel to represent queries that always permit ORDER BY and LIMIT (like SELECT).
2. LIMIT 0 Handling: Changed the limit and offset fields to pointers (*int) in SelectQuery, UpdateQuery, and DeleteQuery. This allows distinguishing between an unset limit and an explicit Limit(0). Limit(0) now correctly emits LIMIT 0 across all dialects, and limit < 0 now returns a validation error.
3. Dialect Feature Consistency: Enabled FeatureUnlimited on all built-in dialects to preserve existing behavior for SELECT queries. Dialect implementations that lack FeatureUnlimited (or specific write-limit features) will now correctly receive errors when attempting to use these clauses.