Good stuff. I would point out that adding methods get, all, etc to the model is an anti-pattern for elixir/erlang. Yes it's comfortable if you come from rails but it's very OO based thinking. In elixir world your models should not define behavior. Behavior and data should be kept separate if possible.
+1 to this. Chris McCord (author of Phoenix) actually wrote a similar ActiveRecord like ORM called atlas but it has since been abandoned ever since Ecto came on the scene for these very reasons.
Your models (or now Ecto calls them Schemas) should simply produce the queries. Your controller is where all your side effects belong (which include interactions with your Repo).
Author here: I agree with both of you.
I'm an hardcore fan of the declarative nature of the SQL language, AR has never really grown on me, but I'm all in for giving people choices.
Having said that, the point wasn't to encourage people to use AR, but to show how easy meta programming is in Elixir and not to be scared by it: you're not going to lose performance, you're not going to create a mess, the compiler will help you to get it right.
AR is probably the most famous pattern around, practically every developer knows it or has been exposed to it, it seemed natural to show how to do something in the way many already find familiar.
Besides, rewriting AR (or more realistically, a small part of it) could be a good exercise for those coming to Elixir/Phoenix from other languages/frameworks, especially Ruby/Rails.
Thanks for pointing me to Atlas, I didn't know about it.
Just so we're clear, Atlas was basically a project that served two purposes for me:
what not to do with metaprogramming. Lots of abuses
that Ecto's Repo pattern is leaps and bounds better than AR
Atlas starting looking more and more like Ecto as I studied Ecto's design, to the point that I knew the correct way to build the lib would end up recreating Ecto, but doing it poorly :)
dev.mikamai.com
Good stuff. I would point out that adding methods get, all, etc to the model is an anti-pattern for elixir/erlang. Yes it's comfortable if you come from rails but it's very OO based thinking. In elixir world your models should not define behavior. Behavior and data should be kept separate if possible.
+1 to this. Chris McCord (author of Phoenix) actually wrote a similar ActiveRecord like ORM called atlas but it has since been abandoned ever since Ecto came on the scene for these very reasons.
Your models (or now Ecto calls them Schemas) should simply produce the queries. Your controller is where all your side effects belong (which include interactions with your Repo).
Author here: I agree with both of you.
I'm an hardcore fan of the declarative nature of the SQL language, AR has never really grown on me, but I'm all in for giving people choices.
Having said that, the point wasn't to encourage people to use AR, but to show how easy meta programming is in Elixir and not to be scared by it: you're not going to lose performance, you're not going to create a mess, the compiler will help you to get it right.
AR is probably the most famous pattern around, practically every developer knows it or has been exposed to it, it seemed natural to show how to do something in the way many already find familiar.
Besides, rewriting AR (or more realistically, a small part of it) could be a good exercise for those coming to Elixir/Phoenix from other languages/frameworks, especially Ruby/Rails.
Thanks for pointing me to Atlas, I didn't know about it.
Just so we're clear, Atlas was basically a project that served two purposes for me:
Atlas starting looking more and more like Ecto as I studied Ecto's design, to the point that I knew the correct way to build the lib would end up recreating Ecto, but doing it poorly :)
totally agree with this.
In fact I wrote
just one quick question: why there is no Repo.count(Module) function and I have to do
thanks.
Care to elaborate why?