Skip to content

string_length is inconsistent between atomic and non-atomic updates, for decomposed strings #845

Description

@matt-beanland

Code of Conduct

  • I agree to follow this project's Code of Conduct

AI Policy

  • I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

Versions

Elixir 1.20.2
Erlang/OTP 29 (erts-17.0.3)
ash 3.33.2
ash_sql 0.7.3
ash_postgres 2.13.1

Operating system

macOS 26.5.2 (Darwin 25.5.0) arm64

Current Behavior

With config :ash, :default_string_length_count, :codepoints, a max_length constraint is enforced by two different counts:

  • non-atomic: Ash core evaluates in Elixir: codepoints_length/2, raw codepoints
  • atomic: Ash.Type.String.apply_atomic_constraints/2 builds string_length(expr, :codepoints), which ash_sql renders as length(normalize(...)), so Postgres counts NFC-normalized codepoints

These may differ depending on the string.

Reproduction

repro - included below

Expected Behavior

Regardless of the string, or whether evaluated in the database or memory, the answer should be the raw codepoint of the value as stored.

Activity

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

    bugSomething isn't working

    Type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions