Adding calculated fields to Ecto Schema - virtual field or?

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?

Doesn’t arc_ecto do what you need?

I want to know how to create accessors in Ecto – the exact use-case is secondary. The “full_name” field is a better example, perhaps.

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.

For a GraphQL endpoint, it was easy enough to add in the field in the resolver…

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?