I’m wondering the best way to solve this particular problem: I have a schema for file uploads (think of an asset manager). The database record stores the file size, the file name, and its location. I also have a Phoenix endpoint where one can stream that file, e.g. for use as a src in an <img> tag. The route is something like /download/:id.
My question is: how to add a field to the Ecto Schema where I can populate the download url? The schema struct already knows the ID of a record, so the only thing I need to do is to build the URL using one of the Phoenix route helpers. Would this require a custom type?
I think virtual fields are a good use case for it,
For instance:
defimpl Jason.Encoder, for: WhateverSchema do
def encode(struct, opts) do
struct
|> Map.put(:avatar, RunTimeSettings.get_url_for(struct))
# |> maybe_trim_private_fields()
|> Jason.Encode.map(opts)
end
end
Personally, if the full url is the only thing that makes sense for the client(s), I replace the field itself with the valid url, if the client needs/can use the field value for something, I define a virtual field and then populate that instead.
Do you need the data on the schema itself, or is it sufficient to include the URL when the struct is serialized to JSON? In the latter case, @amnu3387’s solution will do exactly what you need.
In the former case, things are more complicated - invoking route helpers from inside schemas will mean a circular dependency between the data layer and the Phoenix layer.
That makes sense – is :avatar a virtual field in that example? I haven’t tested that, but is the virtual field even necessary if you are just putting a field into a map?
And I guess for thoroughness, I would love to see an example of how to add something to the schema. E.g. the class accessor example of having a first_name and last_name field in the database, and then having a “virtual” field for full_name that concatenates the two together.
I completely misread what you’re wanting to do - that is not, indeed, useful for creating routes for use inside the app instead for providing the final link outside of it (spa, wtv). Isn’t there a helper to build urls already?
Regarding the virtual field, it was just an example, sometimes it makes sense other times not?
Yes, there’s a helper for that use case, but as @al2o3cr mentioned, that would create a circular dependency. The primary concept I’m trying to figure out is how to introduce a calculated field on read so that the rest of the app won’t know or care that its value did not come directly from the database.
I usually have a function in my schema’s defmodule that fills virtual fields for that purpose (full name field example), which is called from functions in the context after the actual Repo interaction.
As far as I know, there is no way to have something that looks like you do map.prop but that does getter_for_prop(map) instead (like, for instance, ember computed properties or more generally ES6 getters and setters).
It looks like this (off the top of my head):
def get_person(id) do
case Repo.get(Person, id) do
{:ok, person} -> {:ok, Person.fill_virtual_fields(person)}
other -> other
end
end
(You can pipe a list of schema instances through Enum.map())
Hey! How do you deal with virtual field with relationship in Absinthe then? Say you want to fetch an Artist with their Tracks but each track as a virtual field, poster_url, to fetch to url of the poster column. What’s the easiest way to do that?
