Fix several LINQ gaps: DateOnly/TimeOnly projection, SelectMany Distinct().Count(), and GroupJoin Distinct/scalar/aggregates

[haefele-octoja]

Summary

This fixes a few related LINQ-translation gaps I ran into while using Marten, each with a focused regression test. They're independent, so I'm very happy to split this into separate PRs, rework it in whatever direction you'd prefer, or drop it entirely if any of it is the wrong approach — no attachment to the implementation, I just wanted to surface the bugs with repros.

The changes are ~220 lines across 4 source files in src/Marten/Linq, plus 32 tests in three Bug_* files.

What's fixed

1. DateOnly / TimeOnly scalar projection

session.Query<Doc>().Select(x => x.SomeDateOnly).ToListAsync();

threw System.Text.Json.JsonException: '-' is an invalid end of a number on non-empty results. SelectorVisitor.ToScalar didn't list DateOnly/TimeOnly among the scalar types, so the projection fell through to DataSelectClause, which selects the quote-stripped data ->> 'x' text and JSON-deserializes it. Fix: add them to the scalar branch (mirroring DateTime) so the value is read from the member's native mt_immutable_date()/mt_immutable_time() locator. Nullable variants covered.

2. Count()/LongCount() over a Distinct() of a SelectMany() projection

session.Query<Doc>().SelectMany(d => d.Children).Select(c => c.Value).Distinct().CountAsync();

threw The database operator 'DISTINCT' cannot be used with non-simple types even though .Distinct().ToList() returned the correct distinct set. BuildSelectManyStatement re-applied DISTINCT to the count clause ProcessSingleValueModeIfAny had already produced, and the Inner-merged IsDistinct never reached the count path. Fix: skip the tail DISTINCT for Count/LongCount and re-sync IsDistinct for those modes.

3. GroupJoin(...).SelectMany(...) — Distinct, scalar projections, and aggregates

All of the following used to throw or return wrong results, and now work:

var join = session.Query<Customer>()
    .GroupJoin(session.Query<Order>(), c => c.Id, o => o.CustomerId, (c, orders) => new { c, orders });

// --- Distinct over an object projection ---
// previously: Distinct() was silently dropped (non-distinct rows / full joined row count)
await join.SelectMany(x => x.orders, (x, o) => new { x.c.Name, o.Amount }).Distinct().ToListAsync();
await join.SelectMany(x => x.orders, (x, o) => new { x.c.Name, o.Amount }).Distinct().CountAsync();

// --- Bare scalar result selector ---
// previously: threw "Sequence contains no elements" at materialization
await join.SelectMany(x => x.orders, (x, o) => o.Amount).ToListAsync();
await join.SelectMany(x => x.orders, (x, o) => o.Amount).Distinct().CountAsync();

// --- Aggregates over a scalar projection ---
// previously: threw NotSupportedException
await join.SelectMany(x => x.orders, (x, o) => o.Amount).SumAsync(z => z);
await join.SelectMany(x => x.orders, (x, o) => o.Amount).MinAsync(z => z);
await join.SelectMany(x => x.orders, (x, o) => o.Amount).MaxAsync(z => z);
await join.SelectMany(x => x.orders, (x, o) => o.Amount).AverageAsync(z => z); // -> double

// --- Left join (DefaultIfEmpty): childless outer rows included, null inner handled ---
await join.SelectMany(x => x.orders.DefaultIfEmpty(), (x, o) => x.c.Id).Distinct().CountAsync();
await join.SelectMany(x => x.orders.DefaultIfEmpty(), (x, o) => (int?)o.Amount).SumAsync(z => z);

The three underlying issues:

• Distinct() was silently dropped. JoinSelectClause was neither IScalarSelectClause nor ICountClause, so neither distinct branch in ProcessSingleValueModeIfAny matched: Distinct().Count() returned the full joined row count, and Distinct().ToList() returned non-distinct rows. Fix: JoinSelectClause implements IScalarSelectClause (renders DISTINCT(<projection>)), and CompileGroupJoin transfers IsDistinct from the SelectMany usage. Reuses the existing distinct / count-over-CTE machinery.
• A bare scalar result selector threw. (x, o) => o.Amount built an empty NewObject → Sequence contains no elements at materialization (JoinSelectParser only handled new {...} projections). Fix: render a bare scalar as to_jsonb(<scalar>) so the existing SerializationSelector<T> deserializes it; the join selector also returns default for a null data column (a left-join unmatched inner row) instead of throwing.
• Sum/Min/Max/Average over a scalar projection threw. The scalar is rendered as to_jsonb(...) and Postgres has no sum/min/max/avg for jsonb. Fix: for an aggregate, render the raw scalar into the join CTE and put a standard NewScalarSelectClause over it, so the existing aggregate machinery handles result types (SUM(int)->bigint, AVG->double), enums, nullable scalars, and left-join nulls.

Known limitations (left in place, fail with a clear error — not silently)

• Aggregates over an object projection (.SelectMany(... => new {...}).Sum(z => z.Amount)) — there's no single column to aggregate. Workaround: project the scalar directly in the result selector.
• .Select() / .Where() after the join's SelectMany — CompileGroupJoin ignores a post-SelectMany SelectExpression. Supporting it would need a synthesized member collection mapping the anonymous result type's members onto the join's jsonb data column; I judged that a separate, larger feature and left it as a documented limitation (workaround: put the projection in the SelectMany result selector). Happy to take a run at it if you think it's worthwhile.

Testing

• 32 regression tests across Bug_dateonly_timeonly_scalar_projection, Bug_distinct_count_over_selectmany, and Bug_groupjoin_distinct_and_scalar_projection. Each headline bug was verified red→green (fails without the fix, passes with it).
• Full LinqTests suite passes on both net9.0 and net10.0 (1301 passing), including all existing group_join_operator tests — no regressions.
• I also did an adversarial pass over the GroupJoin Distinct for silent-wrong-result shapes (multi-field dedup correctness, type round-trips under both System.Text.Json and Newtonsoft, left-join nulls) — none found.

Notes for reviewers

These are independent fixes; I bundled them only because I found them together. Please tell me if you'd rather I split them into separate PRs (the DateOnly/TimeOnly and SelectMany-Distinct().Count() ones are small and standalone; the GroupJoin change is the larger one), rework any of them, or drop them. I'll happily adapt.

🤖 Generated with Claude Code

[jeremydmiller]

This was superseded by #4677, but it's in. Thank you @haefele-octoja!