silverdr
Ecto.Schema / Ecto.Changeset - optional, conditionally present fields
I have a – let’s call it ‘Parent’ schema, which embeds_one child schema. Basically a set of largely mutually exclusive key/value pairs. Something like (simplified here - actual schema is far larger):
field :type, :string
field :time, :time
field :dom, :integer
field :dow, :integer
Depending on the value in :type one of the following fields is required, while others are not relevant. I do all the casting, validating, including conditional validate_required in custom validating functions and I end up with a ready to use, valid changeset that gets persisted in a JSON field in the DB.
The problem is that ALL the fields get stored, even if they are not needed. I would like to have only the relevant fields to end up in the DB but at best I get something like:
{
"type": "dow",
"time": null,
"dom": null,
"dow": 1
}
What can I do to have only
{
"type": "dow",
"dow": 1
}
persisted, instead?
Most Liked
dimitarvp
Instead of embedding a record, can’t you just have that be a free-from singular JSON field whose contents depend on the type column? That’s what I would do because that would also emulate pretty closely what strongly statically typed languages do with sum types (enums in Rust).
garrison
What you’re really looking for here is a “polymorphic embedded schema”, which is something that comes up every so often. I think someone even wrote a library for it, though I’ve never used it.
My personal opinion: If your data is unstructured, just use a map field (JSON column) and don’t worry so much about the schema - that’s what unstructured means, after all!
If your data is structured and you are worried about the schema, then you should probably be using actual tables. That’s what they’re for!
Of course, if you wanted to go in the opposite direction with an even more degenerate solution, I bet you could put the embedded schema in a virtual field and then parse it back out at the end of the parent’s changeset, drop the nulls, and dump it into a real map field. Of course, then your data wouldn’t be structured on the way out of the DB, but you could probably cook up a solution to that too if you really wanted. The Ecto.Type hack is probably better, though.
silverdr
The question is “how”. I don’t see any straightforward path towards that, unless I drop the embeds_one from my “parent” model.
I see, roger.
Thanks for pointing out. This doesn’t bother me that much though as this config is read-heavy. If it’s get completely replaced once in a while doesn’t matter so much as reading it “all the time”.
Yup, precisely that.
No, I don’t 
I index data, by which I want to retrieve (possibly aggregated) information. I don’t need to aggregate any information on configs as of now 
It does. While I am not in the thousand keys range and don’t expect to ever get there. The hundred one doesn’t seem completely improbable. Which is the main reason I started this thread – how do I store only what is needed for a given configuration rather than just “everything”, including 90% of noise.
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
The deployment platform built for Elixir: PaaS ease, VPS control.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"