Yes, one more library for working with enums and also my 2nd enum library!
My first library was really simple and was mainly intended for personal usage. I did not even expected that other people would use it. This one is completely different as I found that there is still something to do in this place. First of all this library was intended to be
ecto-postgres-enum ~> 2.0, but way too many things changed.
The first thing to note is that it’s not intended to work only for
PostgreSQL database and it even does not require any database. There are lots of helpful features which could be used as same as
ecto_sql and that’s mainly why it’s not just another version of
For now this library depends on
master branch of
ecto_sql, so I’m unable to release it as a
hex package. For now please give it a try by cloning a
This is only a release candidate and gives only preview on what I would like to provide in final release. Based on contribution it may change at any time before
1.0.0 stable release. For each release candidate I would add a
However the true power of this library comes with
ecto_sql support. The one of main features are migrations … fully reversible migrations! It’s not only about
drop enum, but also
drop value. I have written test to ensure that every migration does not cause problem with existing databases, but saying that is like don’t saying anything … You may wonder what happens if we would like to drop value which is already used, but this use case is also covered and tested!
My code for migrations is based on few articles which describes a safely work on database enum and here is one of them:
How does it work in migration file? It’s as simple as calling just one function!
Enumex.Ecto.Migration.drop_value(adapter, prefix, name, repo, value, default)
At this point you may be confused … How could it be
reversible? Of course it’s not possible to turn back value for each row, but this is normal and same result you would have working in raw
PostgreSQL console. This library focused on what database is able to do and offer such features in as simple as possible solutions.
This one feature took for me lots of time especially that
ecto_sql previously blocked me in this specific scenario. Fortunately thanks to @josevalim this has been solved in
master branch of
Of course there is more interesting feature … What would you say if you could simply diff updated your
Elixir just now with values which database is storing? Yes, it’s possible! Take a look at
enumex.gen.migration mix task. It’s not only automatically detecting value
drop, but also
I could describe here all of features, but it could turn into a series of blog posts, so I simply list them all:
In response to: https://github.com/gjaldon/ecto_enum/issues/87
absinthesupport! Everything you need is to import type from
In response to: https://github.com/gjaldon/ecto_enum/issues/78
Migrations - except those already described there are few more helpful functions.
Lots of other debug functions, guards, work with indexes and more …
For now I’m only supporting
PostgreSQL, but I have a plans to change it in next release candidates. However my knowledge about other databases is limited and it could take for me some time. I have take a look at
MySQL and … do I need to comment it?
This library is intended for database like
PostgreSQL which provides a reasonable API. Ok, but what if other databases? I have an idea here. I can implement a
Enumex.Adapters.SQLTable which would provide a
__using__/1 macro for final adapters. In this way I would be able to add support not only for
SQLite also does not looks so problematic with such solution.
Anyway as said I have not much experience with other databases (at least in
enum topic), so I it would be really nice if someone could help with adding support for other adapters.
As already said I’m planning to add at least one helper module called
Enumex.Adapters.SQLTable and I would write (just for an example) an implementation for
PostgreSQL so other developer may see how to deal with it. This mean that there would be at least one release candidate. What will come later I’m not sure, but I would really like to release it on
hex as soon as possible even if it would be only for release candidate test purposes.
Have a nice day!
I would like to provide a list of issues and pull requests less or more related to
This one I noticed when working with
enumex.gen.enum mix task as
ecto.gen.enum was a really good source of inspiration:
flush() bug and new
A confusing error of wrongly emitted
Once again I would like to thank @josevalim for all his help as without him really important parts of this library would not work. Also without it this library would would not be released so fast and most probably it could have a different form.
Feel free in case of any question. I would try to reply to all of them as soon as possible. Hope my work would help in future also in production environments.