Skip to content

Conversation

@rekhoff
Copy link
Contributor

@rekhoff rekhoff commented Jan 29, 2026

Description of Changes

This is the implementation of the Typed Query Builder for C# modules outlined in #3750.
This requires the changes from #4146 to be in place before it can properly function.

This aligns the C# typed query builder SQL formatter with the Rust implementation:

  • Supports And/Or with same grouping styles as Rust.
  • All comparison operators (Eq/Neq/Lt/…) wrap expressions in parentheses so chained predicates produce byte-for-byte identical SQL.

API and ABI breaking changes

Not breaking. Existing modules keep producing the same SQL semantics; only redundant parentheses were added to match the Rust formatter.

Expected complexity level and risk

2 — localized string-format updates plus parity harness tweaks. Low functional risk; largest concern is ensuring every comparison path gained parentheses.

Testing

  • Tested against a local test harness validating output from these changes match current Rust behavior.

@rekhoff rekhoff self-assigned this Jan 29, 2026
@rekhoff rekhoff marked this pull request as ready for review January 29, 2026 04:27
Copy link
Collaborator

@joshua-spacetime joshua-spacetime left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to share the core query builder types between the sdk and module bindings? I also think we should have end-to-end tests similar to what we have for the client builder.

@rekhoff
Copy link
Contributor Author

rekhoff commented Feb 2, 2026

Is it possible to share the core query builder types between the sdk and module bindings? I also think we should have end-to-end tests similar to what we have for the client builder.

Requested changes made, merging both the common Module Bindings and Client SDK sides of Module Builder into the BSATN.Runtime portion of the code base.

^^^^^^^^^^^^^^^^^^^^^^^^^^
}
*/
Message: The call is ambiguous between the following methods or properties: 'TestDuplicateTableNameCols.TestDuplicateTableNameCols(string)' and 'TestDuplicateTableNameCols.TestDuplicateTableNameCols(string)',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which tests generate these errors?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running dotnet test crates/bindings-csharp/Codegen.Tests executes TestDiagnostics, which compiles the diag fixture and captures compiler errors for validating the error output.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But do these errors make sense? Are these from new tests you added?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, not exactly a test I've added, but is a result of the code changes.
diag already does a test of duplicate table names (see TestDuplicateTableName) in it's Lib.cs. With QueryBuilder's additional generated helpers are emitted for both of these tables with a duplicate name, the Roslyn generator sees the duplicate type/constructor symbols and generates the error.
The error's text comes strait from the C# compiler, not something we authored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants