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?
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
We build reliable cloud platforms for business-critical systems.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Practical resources that improve the lives of professional developers.
Master modern tools, write cleaner code, and tackle real-world challenges.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 16 to 7- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
smathy
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.
smathy
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”
LostKobrakai
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.
sodapopcan
You can also
value::textbut I still prefer the flexibility if I can get away with it.dimitarvp
I get the reservation against having to work in
psqland not seeing the full names of the enum values but is that really such a problem in practice? You can just slap oneCASE ... THENinside 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.
sodapopcan
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
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.
sushilbansal
will it not be tedious to update (add or delete) an entry later on?
Hermanverschooten
Didn’t know about the ENUM in pg, TIL
thx good to know.
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.
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');