Yes, one more library for working with enums and also my 2nd enum library!

Introduction

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 without ecto_sql and that’s mainly why it’s not just another version of ecto-postgres-enum.

Try it

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 GitLab repository:

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 git tag.

Migrations

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 create and drop enum, but also add and 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 ecto_sql.

Tasks

Of course there is more interesting feature … What would you say if you could simply diff updated your enum in 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 add and drop, but also rename!

Other features

I could describe here all of features, but it could turn into a series of blog posts, so I simply list them all:

1. Constants-like macros
   In response to: Using Enums as constants · Issue #87 · gjaldon/ecto_enum · GitHub

2. Built-in absinthe support! Everything you need is to import type from YourEnum.Absinthe module.
   In response to: Dynamically generate graphql types · Issue #78 · gjaldon/ecto_enum · GitHub

3. Migrations - except those already described there are few more helpful functions.

4. Ecto support

5. Lots of other debug functions, guards, work with indexes and more …

Database support

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 MySQL, but 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.

Future plans

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!

Related

I would like to provide a list of issues and pull requests less or more related to enumex library.

This one I noticed when working with enumex.gen.enum mix task as ecto.gen.enum was a really good source of inspiration:

The blocking flush() bug and new execute usage:

A confusing error of wrongly emitted Erlang AST:

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.