Ecto Enum display issue

sushilbansal

Hi,
I am trying to use Ecto.Enum as following:

 schema "demographics" do
    field :gender, Ecto.Enum,
      values: [
        male: "Male",
        female: "Female",
        other: "Other",
        prefer_not_to_say: "Prefer not to say"
      ]

    field :year_of_birth, :integer
    timestamps(type: :utc_datetime)
  end

  # function to get all the gender options - will be used with select input component
  def get_gender_options() do
    Ecto.Enum.dump_values(__MODULE__, :gender)
  end

It is working fine; it is saving in DB as string (e.g. “Prefer not to say”). Issue occurs when i fetch the db record and display on LiveView. It displays gender as: prefer_not_to_say

How i can get LV to display “Prefer not to say”.

One way i can think of is:

 schema "demographics" do
    field :gender, Ecto.Enum,
      values: [
        :Male,
        :Female,
        :Other,
        :"Prefer not to say"
      ]

    field :year_of_birth, :integer
    timestamps(type: :utc_datetime)
  end

Is there any other way?

16 comments

#ecto #ecto_enum

0 1332 16

2024-01-28 17:14:48 UTC

Showing Posts 1 to 10

Show Best Posts
Show All (oldest first)
Show All (newest first)

LostKobrakai

Generally I’d argue that your db representation should be separate from your frontend representation. Just because you store :male runtime value as "Male" in the database doesn’t mean your frontend should render :male as "Male" (applies the same the other direction).

But if you really want to reuse that mapping you can get to it using Ecto.Enum.mappings(schema, :gender).

Post #1

sushilbansal

Thanks for the feedback. What’s the best way to keep db representation separate from frontend representation for Enums (will you store the mapping as a map and use it on front end to map it) or is there any other way?

Post #2

LostKobrakai

Yeah, have two separate mappings. One from atom to frontend string, which can then potentially handle things like localization and another one (the Ecto.Enum one) for atom → db string.

Post #3

Hermanverschooten

Chiming in, I prefer to use integers in the db, they take less space, and since Ecto returns the atoms in both cases.

Post #4

krasenyp

All good but if someone else uses the database and/or there’s no Ecto to map the integers to atoms, the column’s values are meaningless. Strings and/or an enum type in the database are self documenting.

Post #5

Hermanverschooten

True, but I am dealing with millions of records and 1 integer value versus a string of 4~17 characters, makes a huge difference in storage and indexes.

Post #6

champeric

I know some people don’t like using them, but it’s way better in my opinion to use an ENUM if you’re using PostgreSQL. It uses the same space as an int, but it will be readable and better in terms of data integrity (you can’t have a value that doesn’t exist).

There are some caveats, but I never had any problems with them.

CREATE TYPE gender AS ENUM ('male', 'female', 'other');

Post #7

krasenyp

You are right. Even a lookup table and a foreign key column is better than plain integers. We don’t know @Hermanverschooten’s context though. Might be storage constrained.

Post #8