tamada / fauxrest / 30511226004

86%

main: 86%

Pull #13

github

fix: order string operands lexicographically in gt/gte/lt/lte

compare_ord reduced both operands with `as_f64().unwrap_or(0.0)`, so two
strings both became 0.0. The consequences differ per operator, and the issue
understated half of them:

| op | before | correct |
|---|---|---|
| gt, lt | matched nothing | - |
| gte, lte | matched everything | - |

`0.0 >= 0.0` holds, so `gte` and `lte` emitted every record. For a directive
whose job is keeping records out of the generated API that is the unsafe
direction, the same failure mode as #1 — a date-range endpoint silently
published its whole collection.

compare_ord now asks scalar_ordering for an `Ordering` and lets the caller
decide which orderings satisfy the operator, so numbers compare numerically and
strings lexicographically. That is the correct semantic for the zero-padded,
fixed-width formats this is wanted for: `activities.from` holds ISO-8601 dates
as strings, and `papers.year`/`theses.year` hold years as strings. It is not
meaningful for free-form text such as "April 2023", which is noted in the
function's documentation.

is_type_compatible now accepts two strings for the ordering operators. Without
that the warning fired on every comparison this change fixes, and its wording
was self-contradictory to begin with: "lhs is string, rhs is string" reported as
a mismatch.

is_match_type is gone; compare_ord was its only caller, and scalar_ordering
matches on the kinds directly.

Verified end to end against three records dated 2018, 2021 and 2026 with a
pivot of "2020-01-01": gt and gte now select the two later records, lt and lte
the one earlier record. Before, gt and lt selected none while gte and lte
selected all three.

Closes #2

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

86 of 87 new or added lines in 1 file covered. (98.85%)

1232 of 1470 relevant lines covered (83.81%)

15.47 hits per line