xlive
`:any` type for embedded schemas in non-virtual fields
Hey there!
We are using Ecto to parse some API response (it works pretty well!).
We want this response to be converted to a struct, so we first do all the needed validations and at the end we do an apply_action(changeset, :parse).
To do so, we would like to have a module that defines an embedded_schema like the following (we won’t save this):
defmodule MyApp.Response do
use Ecto.Schema
@primary_key false
embedded_schema do
field(:custom_field, :any)
...
end
end
The “problem” comes with this :any type. When compiling, Ecto complains that only virtual fields can be defined with the :any type.
Here the error:
== Compilation error in file lib/my_app/api/response.ex ==
** (ArgumentError) only virtual fields can have type :any, invalid type for field :custom_field
(ecto 3.11.1) lib/ecto/schema.ex:2012: Ecto.Schema.__field__/4
lib/my_app/api/response.ex:36: (module)
(ecto 3.11.1) lib/ecto/schema.ex:2241: Ecto.Schema.__embeds_module__/4
lib/my_app/api/response.ex:32: (module)
Is there an explanation of why they must be virtual?
In our use case, this field can have different types (boolean, integer, string, etc.), so we need this flexibility here.
We think that, as embedded_schemas are just saved as blobs or, like in our case, not saved at all, this doesn’t make a lot of sense. But maybe someone has a better understanding about this.
Thanks in advance! ![]()
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #performance
- #security










Most Liked
cevado
You can use a schemaless changeset
Adzz
Ecto can work for some inputs I found I quickly outgrew it and wrote GitHub - Adzz/data_schema: Declarative schemas for data transformations. · GitHub too. If you need to map data that isn’t essentially a map or a list then ecto schemas aren’t the solution imo.
sodapopcan
I’m assuming this is for similar reasons as to why you can’t use
nilforembeds_many—which came up again recently—that embeds are meant to be treated the same as regular relations. I think your only option if you want to keep using Ecto is to create your own type. Otherwise you could check out Drops which is a more general schema library.