EctoFlex - A very easy and flexible way to query schemas

Hello everyone,

I just released my first hex package, EctoFlex.

make querying schemas extremely fast and easy (in terms of development time). No need to write your own queries to fetch simple data.

I used to write my general “querying” module for every new project that uses ecto and then slowly add some specialized queries as I go on. It used to take from a few hours to a few days to get everything together. It wasn’t practical. I felt like I was repeating myself unnecessarily and most of the code was filled with hardcoded values that prevented me from using it easily in other projects. Hence, ecto_flex was born.

What It’s NOT
ecto_flex is not meant to replace complex queries. For example, it doesn’t support preloads (yet). It doesn’t support aggregate functions too. I’m not sure if this will be added in the future or not.

Why is it called “EctoFlex”?
It’s supposed to mean “Ecto Flexible” or “flexible ecto” in plain English. It helps you write flexible queries extremely easily. At least that’s what I hope. The docs for hex recommend to prefix the package name with the package that it depends on, so ecto_flex it is.


It’s obviously in a very early stage and it’s not recommended for production use.
My plan is to keep enhancing it and adding features until I feel comfortable releasing a 1.0.

Criticism and feedback are welcome.
PRs are also welcome.


Some API docs would be nice, even if the library is in an early stage.


Working on that right now.

I have updated the package with some docs and added a few tests. Also included more examples in the GitHub README file. Hope usage is clearer now.


It seems very interesting. Did you look at Filtrex when you created your library? They seem quite similar. How would you compare EctoFlex to Filtrex?

Interesting. Didn’t know about Filtrex. Thanks for sharing it!

I feel Filtrex is more involved and it offers quite a lot more than EctoFlex.
Some differences I noticed:

  • Filtrex is a bit focused on the web, while EctoFlex tries to be as general as possible.
  • I’m not sure if Filtrex supports OR conditions.
  • EctoFlex tries to be as small as possible. It’s currently only has one function to use.
  • JSON/map fields. This is honestly reason #1 why I’m doing this.

EctoFlex doesn’t have JSON field support yet (searching, filtering, checking key existence, etc) but this is what I’m working on for the next version. JSON querying and OR conditions are what I personally need a lot in my projects.

I have some ambitious ideas for EctoFlex that might not be realistic currently, but only time will tell.