Originally I wanted to use
Menshen, but after looking at code, issues and pull request I was not satisfied. This library was small, so I decided to quickly rewrite it and release my own which will focus on
PostgreSQL only and will be maintained well. It’s simple package with just one module. You can find it in hex.
Originally I wanted to use
As I’ve mentioned in an issue in ecto_enum, some parts (there and in your version as well) could probably be optimized by generating some functions and using pattern matching to create a lookup table out of them (instead of using a list for it).
A bit strange that there are so many (your’s the 5th?) ecto_enum-like libraries …
@idiot: good idea, thanks
muh_enum_type (which I don’t even know about) requires to pass list directly, so for me both are bad choices.
requires to pass list directly
What list? The list of enumeration members?
As far as I know variables will not be visible and module attributes like
@__name__ are for introspection.
Yes, sometimes I need to load a list of atoms for example from library (I’m already doing it in
How do you bake that into the migration for stuffing into the PostgreSQL enum datatype then?
This list is already at compile time, but I don’t have them written by hand, because values comes from library.
For example other libraries does not allow things like:
defmodule MyEnum do values = Library.get_enum_values() use MyLibrary, values: values end
opts are used outside
Sure they do, you just need to macro lift the entire
use (maybe just the
values depending on implementation)?
@OvermindDL1: Sorry, I don’t get it. Can you provide an example?
defmodule Example do defmacro __using__(opts) do IO.inspect opts[:values] end end defmodule Sample do values = [:a, :b, :c] use Example, values end
Worst case you can just do this:
Code.eval_quoted(quote do defmodule Sample do use Example, unquote(values) end end)
There are some direct ways for the usual macro’s but unsure about
use, might have to expand it directly or something.
Dear @OvermindDL1, I really appreciate your experience, but … you made my day!
One of my first languages was PHP, so when I see
eval then I’m doing a strange face. Not sure if we have emoticon for what I’m doing with my face.
Sorry, but I just can’t add a code like that to any library just because someone write something outside
quote block. Maybe if there will be a nicer solution then I could think about it again.
Yeah something about
use made it very difficult, direct calls are easier… ^.^;
Could call the
__using__ straight though?
EctoEnum is being very actively developed and as I recall it has support for a variety of PostgreSQL Enum types, as wall as a fallback to entirely server-sided enums when you aren’t using PostgreSQL or don’t want to use a PGSQL type.
@abitdodgy As already mentioned I have made this library, because I wanted to pass a dynamic value (list returned from some library). For now I don’t have any plans for adding new features/enhancement as simply I don’t have any need for them. Anyway release a new version with someone changes is definitely ok for me. I can see now one PR. Sorry, somehow I missed
GitLab notification from
Edit: After reading PR and code I decided to rework it a bit. API will not change, but I will fix some problems and add some debug functions.
New version 1.1.0 published!
Here is a list of all changes:
- Added credo, dialyxir and excoveralls support.
- Added extra debug functions and guards.
- Added more tests.
- Changed dependency from ecto 2.x to ecto_sql 3.x.
- Fixed generated specs and all found bugs.
- Full code refactor: 0 errors/warnings and 100% coverage.
- Removed unneeded config/config.exs
- Updated all dependencies.
- Updated documentation.
Here is how my maintain looks like!
P.S. I really need to find a good way to receive notifications on phone, so I will not have such problems in future …