DataType

DataType declares the logical type of a Condition's values. The library uses it to pick the right comparison expression, parse incoming JSON values, and validate that the chosen Operator is legal for that type.

Values

Seven logical types. Each row lists every operator the library will accept when paired with that type. An unsupported pairing is not caught by validation: the predicate builder throws a LogicException reading Unsupported combination of DataType '<type>' and Operator '<op>'.

Date formats

A Date or DateTime value is read against an explicit list of formats, never the lenient .NET parser — at validation and in the predicate builder alike, as the member's own DateTime, DateTimeOffset or DateOnly. The host's culture and calendar play no part, so a value is accepted or refused the same way on every server — including one that declares a local format, since a format whose text the built-in readers also read is refused at configuration. Every deployment accepts these forms:

A C# DateTime, DateTimeOffset or DateOnly placed in Values is written in one of these forms (see Value coercion), so a C# caller is never refused for sending one. Anything else is refused, with one of two codes:

Declaring a local format

A deployment whose clients send a local form declares it once, at startup. With dd/MM/yyyy declared, "01/09/2026" is 1 September on every server.

using DynamicWhere.ex.Source;

// A day-first API.
DwDates.Configure(o => o.Formats.Add("dd/MM/yyyy"));

// Or from configuration. A key nothing answers to — "Fromats" — refuses to start,
// and so does a single value where the list belongs: "Formats": "dd/MM/yyyy".
DwDates.Configure(new DwDateOptions().Bind(configuration.GetSection("DynamicWhere:Dates")));

{
  "DynamicWhere": {
    "Dates": {
      "Formats": [ "dd/MM/yyyy" ]
    }
  }
}

• A format is a .NET exact format string, read with the invariant culture. ISO 8601 and year-first dates stay accepted alongside it.
• Exact means exact: dd/MM/yyyy reads neither 1/9/2026 nor 01/09/2026 12:30. Declare d/M/yyyy or dd/MM/yyyy HH:mm beside it if clients send those. A value no declared format reads is refused as before, so 09/15/2026 sent to a dd/MM/yyyy deployment is still AmbiguousDateFormat.
• Two formats that read one text as different dates — dd/MM/yyyy beside MM/dd/yyyy, or a format that contradicts ISO 8601 such as yyyy-dd-MM — are refused when configured, with ArgumentException, rather than left to disagree on a request. So is a blank format.
• So is a format with no year — dd/MM, HH:mm, t. The parser completes a missing year from the clock, and a missing date from today, so the same value would name a different date depending on when the query ran. A format with a year but no day, such as yyyy-MM, is accepted and reads the 1st.
• So are a malformed format; a format that reads part of what it writes back differently — dd/MM/yyyy hh:mm, a 12-hour clock with no tt, reads 4 PM as 4 AM; a format with a day but no month — dd/mm/yyyy, where mm is minutes; and two formats that put the day and the month in opposite orders even in different shapes, since dd/MM/yyyy HH:mm beside MM/dd/yyyy would read 01/09/2026 00:00 as 1 September and 01/09/2026 as 9 January.
• So is a format whose own text ISO 8601 or a year-first date already reads. yyyy-MM-dd, yyyy/M/d, yyyy-MM-dd HH:mm:ss and yyyy-MM-dd'T'HH:mm:ss'Z' are refused; dd/MM/yyyy, dd/MM/yyyy HH:mm, yyyy-MM, dd MMM yyyy and d/M/yy are accepted. Declaring one can only change what such a value means: the 'Z' in yyyy-MM-dd'T'HH:mm:ss'Z' is a quoted letter rather than a zone, so that format reads 12:00 as a wall time where ISO 8601 reads an instant — and on a DateTime member the ISO reading converts to the host's local time, so off UTC the two readings differed and every such value was refused as AmbiguousDateFormat, on that host only. The refusal at configuration is the same on every host. It runs after the checks above, which name a sharper reason.
• The formats are process-wide and every query reads them without a lock, so they are set once: a second DwDates.Configure call throws InvalidOperationException.

JSON examples per type

Text

{
  "sort": 1,
  "field": "Name",
  "dataType": "Text",
  "operator": "IContains",
  "values": ["phone"]
}

Guid

{
  "sort": 1,
  "field": "CustomerId",
  "dataType": "Guid",
  "operator": "Equal",
  "values": ["a1b2c3d4-e5f6-7890-abcd-ef1234567890"]
}

Number

{
  "sort": 1,
  "field": "Price",
  "dataType": "Number",
  "operator": "Between",
  "values": [0, 1.569]
}

Number values (3.3.0)

A number is written into the generated expression unquoted, exactly as sent, so it is read the way the expression parser reads it rather than the way the host's culture does. Two steps.

The grammar, in the invariant culture and ASCII digits only: optional white space, an optional minus, digits, an optional fraction — a point with a digit on both sides — and an optional exponent (e or E, an optional sign, digits). No leading plus, no thousands separator, no trailing sign, no parentheses, no NaN and no Infinity. An integer, meaning one with neither a fraction nor an exponent, must fit UInt64, or Int64 when negative; a real has no bound, and 1e400 reads as infinity. A suffix (5L, 5m), hex (0x1F) and - 5 are refused as they always were, though the parser would read them: nothing is accepted now that was not accepted before.

The member. In a Where condition, for the operators that write the value into a comparison — Equal, NotEqual, In, NotIn, GreaterThan, GreaterThanOrEqual, LessThan, LessThanOrEqual, Between and NotBetween — the literal also has to compare with the member the condition names. The parser itself is asked, against the member's declared type: a collection at the end of the path stands for itself, one along the path stands for its elements. Refused there, where the parser used to throw:

• a literal written with a point and no exponent (1.5, 0.1, 1.0) on a nullable integral member (int?, long?, …). A non-nullable int still takes 1.5, exactly as before;
• an exponent form (1e5, 1E-7) on decimal or decimal?, and a real with more digits than a decimal holds;
• an integer above Int64.MaxValue on a signed integral member (sbyte, short, int, long, nullable or not): such a literal reads as a ulong, which none of them converts to;
• a negative number on ulong or ulong?;
• any number on a string, bool, Guid, DateTime or char member, or on a collection of simple values such as List<int> — a path through a collection, Lines.Quantity, still works;
• a nullable enum under an ordering operator. Equality works on it, and a non-nullable enum orders.

A Having condition reads the grammar and stops: an alias names an aggregate, so there is no member type to ask the parser about. Every refusal is InvalidFormat, the same in both policy tiers, and a denied field is still refused by the gate before any value is read.

Boolean

{
  "sort": 1,
  "field": "IsActive",
  "dataType": "Boolean",
  "operator": "Equal",
  "values": [true]
}

DateTime

{
  "sort": 1,
  "field": "CreatedAt",
  "dataType": "DateTime",
  "operator": "Equal",
  "values": ["2024-06-15T14:30:00"]
}

Date

{
  "sort": 1,
  "field": "CreatedAt",
  "dataType": "Date",
  "operator": "GreaterThan",
  "values": ["2024-01-01"]
}

Enum

{
  "sort": 1,
  "field": "Status",
  "dataType": "Enum",
  "operator": "In",
  "values": ["Active", "Pending"]
}

Value coercion

Values is List<object>. Whatever the front-end sends, the library normalizes each element before validating and building the expression.

C# usage

using DynamicWhere.ex.Enums;

var condition = new Condition
{
    Sort = 1,
    Field = "Price",
    DataType = DataType.Number,
    Operator = Operator.GreaterThan,
    Values = new List<object> { 50 }
};

Related

• Operator → all 28 operators and their value-count requirements.
• Condition → the class that carries the DataType.
• Condition validation → the rules used when parsing each DataType.
• Error Codes → InvalidFormat and AmbiguousDateFormat.