Skip to content

EF Core: a hand-written arithmetic operator in a query runs as the database's arithmetic #187

Closed

Description

@CaffeinatedCoder

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 runs

What 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 with operator true and false, C# compiles them to their own nodes, AndAlso and OrElse, whose method is its & or |. The guard knew And and Or only: Switch && Switch over 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 over operator true is a call of op_True, which EF runs in memory as written, and stays allowed.

Activity

  1. added this to the 2.4.0 milestone on Oct 30, 2026
  2. added
    bugSomething isn't working
    silentCompiles or answers and does less than it appears to
    severity/mediumInconsistency or failure in a narrow scenario
    package/efcoreAffects CodoMetis.TypeKit.EntityFrameworkCore
    area/value-objectsValue-object contracts and what the aspects generate for them
    on Oct 30, 2026
  3. CaffeinatedCoder commented on Oct 30, 2026

    @CaffeinatedCoder
    OwnerAuthor

    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.

  4. CaffeinatedCoder commented on Oct 31, 2026

    @CaffeinatedCoder
    OwnerAuthor

    Merged into release/2.4.0 by #189 (3dc4695).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/value-objectsValue-object contracts and what the aspects generate for thembugSomething isn't workingpackage/efcoreAffects CodoMetis.TypeKit.EntityFrameworkCoreseverity/mediumInconsistency or failure in a narrow scenariosilentCompiles or answers and does less than it appears to

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions