Repository navigation
Description
Package
CodoMetis.TypeKit.EntityFrameworkCore, CodoMetis.TypeKit.Generators
Version
2.4.0 (unreleased; the same since 1.0.0 for an operator written by hand)
How does it fail?
Silently. It compiles or answers, and does less than it appears to
What you ran
public readonly partial record struct RoundedMoney : IValue<decimal>, IAdditionOperators<RoundedMoney, RoundedMoney, RoundedMoney>
{
public static RoundedMoney operator +(RoundedMoney left, RoundedMoney right) => From(Math.Round(left.Value + right.Value, 2));
}
db.Orders.Where(o => o.Price + o.Tax > RoundedMoney.From(0.01m)) // the database adds the columns; the rounding never runsWhat you got
Measured on SQLite with EF Core 10.0.12 (#189, with the refusal taken out), over Price 1.005 and Tax 0.001: Price + Tax > RoundedMoney.From(1.006m) became ef_compare(ef_add("l"."Price", "l"."Tax"), @limit) > 0 and kept no row, where memory, which rounds to 1.01, keeps the one; Select(l => l.Price + l.Tax) read 1.006 where memory reads 1.01. EF never calls the operator. The same holds for any arithmetic, bitwise or shift operator a value object declares by hand, with or without an interface, a validated value object's included.
What you expected
The query is rejected, naming the value object and .Value, as a query that orders a value object with its own CompareTo is (EF Core, Queries). 2.4 documents a hand-written arithmetic operator as kept (decision 122), which makes this the same seam.
Environment
.NET SDK 10.0.4xx, EF Core 10, SQLite; any provider.
Found in review (#189)
&&and||bypassed the refusal. Over a value object withoperator trueandfalse, C# compiles them to their own nodes,AndAlsoandOrElse, whose method is its&or|. The guard knewAndandOronly:Switch && Switchover a column returned true where the operators answer false, unrefused, in a projection and a filter. Both are refused now, in queries and query filters. A condition overoperator trueis a call ofop_True, which EF runs in memory as written, and stays allowed.
Activity
CaffeinatedCoder commentedon Oct 30, 2026
Fixed in #189 (stacked on #188): every generated operator carries
[TranslatedAsWrappedArithmetic], and an EF Core query refuses any other arithmetic, bitwise or shift operator a value object declares, naming the value object and.Value; a query filter fails when the model is built. Conversion operators are left to EF. Decision 123.docs: renumber the hand-written-operator decision record from 0122 to…
CaffeinatedCoder commentedon Oct 31, 2026
Merged into release/2.4.0 by #189 (3dc4695).