refactor: refactor core to simplify the code structure and API

[ahmad-moussawi]

This pull request primarily refactors and improves the handling of condition clauses and their tests in the query builder. The most significant changes include simplifying generic types in condition classes, enhancing test coverage for complex "having" and "where" clause interactions, and cleaning up unused or redundant code.

[Copilot]

🟡 Changes recommended

Callback subqueries lose parent-variable resolution, and retained clause APIs contain cloning and replacement regressions.

4 open findings

• AddOrReplaceComponent appends instead of replacing components · New
• WhereIn callback subqueries cannot resolve outer query variables · New
• Clone bypasses virtual NewQuery factory for derived query types · New
• Replacement joins omit engine and join component metadata · New

What changed in this PR

Refactors query condition storage and compilation around dedicated condition groups while simplifying clause types and APIs.

Changes:

• Separates where, having, and join clauses into dedicated containers.
• Replaces reflective condition compilation with type-based dispatch.
• Expands tests for grouped and interleaved conditions.

File	Description
SqlKata.Execution/​XQuery.cs	Uses centralized clause copying.
SqlKata.Execution/​QueryFactory.cs	Copies dedicated clause containers.
QueryBuilder/​Query.Where.cs	Adds Query-specific where API.
QueryBuilder/​Query.Join.cs	Stores joins directly.
QueryBuilder/​Query.Having.cs	Delegates having operations to condition groups.
QueryBuilder/​Query.From.cs	Extracts Query-specific from API.
QueryBuilder/​Query.cs	Introduces dedicated clause storage and cloning.
QueryBuilder/​Query.Aggregate.cs	Modernizes collection construction.
QueryBuilder/​Join.cs	Reworks joins around dedicated conditions and sources.
QueryBuilder/​IConditional.cs	Defines the conditional-builder contract.
QueryBuilder/​IClauseContainer.cs	Defines the clause-container contract.
QueryBuilder/​Extensions/​ConditionExtensions.cs	Centralizes condition-building operations.
QueryBuilder/​ConditionGroup.cs	Adds reusable condition groups.
QueryBuilder/​Compilers/​ConditionsCompilerProvider.cs	Removes reflection-based dispatch.
QueryBuilder/​Compilers/​Compiler.cs	Compiles dedicated join storage.
QueryBuilder/​Compilers/​Compiler.Conditions.cs	Uses pattern-based condition compilation.
QueryBuilder/​Clauses/​ConditionClause.cs	Simplifies generic condition types.
QueryBuilder/​BaseQuery.cs	Removes the generic base query abstraction.
QueryBuilder/​Base.Where.cs	Removes generic-base condition methods.
QueryBuilder.Tests/​WhereTests.cs	Tests condition groups and flag interactions.
QueryBuilder.Tests/​OperatorWhitelistTests.cs	Tightens expected exception types.
QueryBuilder.Tests/​Infrastructure/​TestCompiler.cs	Removes reflection-testing helpers.
QueryBuilder.Tests/​GeneralTests.cs	Removes obsolete reflection-cache tests.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

Clause metadata, engine-scoped replacement, and derived-query cloning contain behavioral regressions.

1 open finding

• Null engine matching affects all scoped join conditions · New

4 resolved since last review

• AddOrReplaceComponent appends instead of replacing components
• Replacement joins omit engine and join component metadata
• Clone bypasses virtual NewQuery factory for derived query types
• WhereIn callback subqueries cannot resolve outer query variables

Previously missed (3)

In code that hasn't changed since last review

HAVING clauses are incorrectly stamped as where components

QueryBuilder/​Query.Having.cs:10

All simple HAVING APIs delegate to extensions that add the clause as component "where". This makes the compatibility Clauses property non-round-trippable: reading a query's clauses and assigning them to another query routes HAVING clauses into Wheres at lines 68-74. Ensure clauses inserted through Havings are stamped as "having" centrally.

Null engine matching affects all scoped WHERE clauses

QueryBuilder/​Query.cs:219

When engineCode is null, this predicate matches every scoped WHERE clause rather than only the generic clause. A query containing generic and engine-specific conditions will therefore throw from SingleOrDefault() (or remove the sole engine-specific clause) when replacing the generic condition.

This issue also appears on line 225 of the same file.

Join replacement broad-matches and loses engine/component metadata

QueryBuilder/​Query.cs:234

This branch both broad-matches every join when engineCode is null and adds the replacement without stamping its Engine/Component. Consequently an engine-specific join added through AddOrReplaceComponent becomes generic, and generic replacement can throw when scoped joins coexist.

🧠 Review effort: Balanced

[Copilot]

🟡 Changes recommended

Unscoped clause clearing breaks multi-engine queries, and the compatibility clause property can silently lose or misclassify clauses.

4 open findings

• Unscoped aggregate clear overwrites other engine definitions · New
• Clear removes insert clauses for other engines · New
• Clear removes update clauses for other engines · New
• Clauses compatibility property loses metadata and misroutes HAVING · New

1 resolved since last review

• Null engine matching affects all scoped join conditions

🧠 Review effort: Balanced