Ecto Enum display issue

Questions / Help
,
1

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?

2

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).

5 Likes
3

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?

4

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.

2 Likes
5

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

1 Like
6

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.

7

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.

1 Like
8

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');

5 Likes
9

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.

10

Didn’t know about the ENUM in pg, TIL
thx good to know.

11

will it not be tedious to update (add or delete) an entry later on?

12

In short, possibly. You can’t delete or reorder values which can be mildly to very annoying, or not annoying at all if you don’t run into it :slight_smile:

While I do agree with @champeric that pg enums are nice and I have used to use them, my counter experience is that I’ve never run into any of the caveats of using plain strings. If storage isn’t an issue, I find them much more convenient. While I’m big into fkeys and partial indices, tracking down rows with a mistyped status is orders of magnitude simpler than dealing with orphaned rows. That’s just an example, though, I’ve never actually dealt with the former.

1 Like
13

I get the reservation against having to work in psql and not seeing the full names of the enum values but is that really such a problem in practice? You can just slap one CASE ... THEN inside your SQL query – that will translate integers to strings – and have best of both worlds.

I’ve been using PG enums from ever since they started existing.

14

You can also value::text but I still prefer the flexibility if I can get away with it.

15

I’d argue it very much is. You can throw out any default view a postgres client might give you of a table, because it’ll show integers and not your mapped values. And especially when on call you don’t want to first dig up a mapping somewhere to be able to understand what those intergers mean in the first place.

16

It’s definitely not tedious to add a value, that’s simple and has been available since pg 9.1. Renaming has been available since 10 which alleviates most of the need for deleting, but yes - deleting is a bit tedious, but IMHO appropriately so - you have other issues if you’re needing to delete enum values more than “almost never” :slight_smile:

1 Like
17

Not to mention organizations who use “tableau”-type reporting tools to create their own business reports. Keeping proxy values in sync between your code and not-your-code is a massive PITA.