Casting Limitation with Large Integers in Embedded Schemas

[Alisina Bahadori]

Hello Ecto team,

First of all, thank you for all your efforts in making Ecto such a pleasure to work with. Every time I switch back to working in other languages, my appreciation for Ecto grows even more.

Problem

I'm working with embedded schemas that have fields containing 256-bit unsigned integer values. I've noticed that when I attempt to cast these values from strings in a changeset, I encounter cast errors. Interestingly, the same value works fine when passed as an integer.

Upon inspecting Ecto's `type.ex` file, I discovered that there is a restriction that limits the byte size of strings to 32 bytes:

```elixir
# lib/ecto/type.ex:886@892dc85e
# We check for the byte size to avoid creating unnecessary large integers
# which would never map to a database key (u64 is 20 digits only).
defp cast_integer(term) when is_binary(term) and byte_size(term) < 32 do
  case Integer.parse(term) do
    {integer, ""} -> {:ok, integer}
    _ -> :error
  end
end
```

I understand the rationale behind this limitation, as it helps prevent creating unnecessarily large integers that wouldn't fit typical database keys (like `u64`). However, this restriction seems to be overly strict for embedded schemas that might need to handle larger integers, such as 256-bit values.

Suggestion

Would it be feasible to move this limitation to the specific database adapter implementation, where we could limit the actual integer value size as needed, rather than imposing this restriction at the generic casting level? This way, we could handle larger integers more flexibly within embedded schemas without affecting the usual database mappings.

Thanks again for your work and for considering this suggestion.

Best regards,
Alisina

[José Valim]

Could you create your custom Ecto type that is called MyApp.U256 that accepts and returns integers and has more precise casting logic?

José Valim

https://dashbit.co/

--
You received this message because you are subscribed to the Google Groups "elixir-ecto" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-ecto...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/elixir-ecto/e696f3e5-2d9e-4b77-9abe-34101c04db67n%40googlegroups.com.

[Alisina Bahadori]

Thank you for the prompt response José,

Yes, that makes perfect sense to create a custom type for handling these values. Currently, I'm converting the value in my changeset before calling `Ecto.Changeset.cast/3` as a workaround to prevent the issue.

My intention was mainly to point out the discrepancy between casting strings and literal integers, and whether this behaviour could be improved for consistency.

Thanks!