Validation
As DynamicWhere.ex translates your JSON into an IQueryable<T>, every shape is validated. A bad input throws a LogicException carrying a stable, machine-readable error code so your API can surface a precise 400 to the client.
How validation works
Validation is performed inside each extension method on the input shape you pass, clause by clause as the query is composed. The library throws LogicException carrying the error string as its Message whenever a rule is broken. Most failures stop the call before any SQL runs — but not all: the dynamic terminals run their COUNT query before Orders, Page and Selects are validated. A Segment is combined into one query, and every clause of it is validated before that query runs.
LogicException in your controller pipeline and map its Message — the error string itself; there is no separate code property — to a structured error response. See the full list of codes in Error Codes.Rule categories
Rules are grouped by the shape they protect. Each page below documents every rule and the exact error code it raises.
| Shape | Page | Protects |
|---|---|---|
Condition | Condition rules | Field existence, operator/value arity, parseable values. |
ConditionGroup | ConditionGroup rules | Unique sort indices across sibling conditions and groups. |
GroupBy / AggregateBy | GroupBy rules | Group field shape, aggregation aliases, aggregator/type compatibility. |
Segment | Segment rules | Set-operation ordering and required intersection. |
Summary | Summary rules | Required GroupBy, valid order / having field references. |
PageBy | Page rules | Positive page number and page size. |
Related
- Error Codes — the full enum of error codes raised by validation.
- Condition — the shape most rules guard.