xlive
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! 
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #ai
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
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.cevado
You can use a schemaless changeset
cevado
But now actually answering that part, and expanding on what @sodapopcan . Understand that althought schemas and changesets are just mapping abstractions. both schema and embedded schemas are expected to be at some point dumped to a database.
Since that is not your intention, i’d recommend to use schemaless changeset(you can use that with structs or plain simple maps).
in case you need features like nesting, relations and some more complex stuff that doesn’t work with schemaless changeset i’d do something like:
xlive
Thank you all for answering here!!
@cevado yes.. Actually this variable will be inside an assoc of the main struct
I will try then to find a better way to check these types
Maybe Drop is a nice candidate! Thx @sodapopcan !!
al2o3cr
What happens if you pass
virtual: trueto thefieldcall like the error message suggests?LostKobrakai
With
:anyecto cannot be sure it can encode the data for storage in whatever db driver is in use. Therefore it is only allowed for virtual fields, which are not persisted anyways and therefore do not run into that problem.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.