45 ms·

I just couldn’t get past ecto! It never seemed to “click” for me. Maybe I need to go back and learn it more in-depth, it sounds like it’ll be fantastic once I g

by hazz99 6y ago

I just couldn’t get past ecto! It never seemed to “click” for me. Maybe I need to go back and learn it more in-depth, it sounds like it’ll be fantastic once I get the hang of it.

dnautics 6y ago
It's definitely not an orm, as it was stolen from c# linq. Imo this is actually much better than an orm because it really hits home that the data in memory are stale as soon as you receive them because database transactions are explicit, and not hidden behind getters and setters. ORMs can get you into trouble because they try really hard to hide the problem of distributed state and sources of truth.
- hvis 6y ago
  Coming from (the much-maligned) ActiveRecord, I wasn't really impressed. It has this cute macro-based syntax, and that seems to inform even the "functional" API as well. Yet when you I wanted to do something just a bit more advanced like joining on an association whose name I don't know in advance (or, say, want to parameterize the function with), I had to resort to writing a macro myself and then eval-ing it an runtime.
  - oli_b 6y ago
    I had the same experience, but now I'm wondering - is ActiveRecord much maligned? It is news to me. It handles simple stuff really well, takes a lot of the pain out of relationships, and doesn't prevent you reaching for SQL when required. I also haven't ever found a good replacement for AR migrations, which makes schema changes + keeping a record of those changes absolutely seamless. Are there some alternatives I should be investigating?
    - hvis 6y ago
      > is ActiveRecord much maligned? Well, take the numerous articles extolling the virtues of Sequel, or DataMapper, or, related to the current discussion, Ecto itself. Like how expressive this stuff is. And how ActiveRecord creates a too huge API surface on models, and that that leads to bad design, etcetera. Now to mention the callbacks, which are admittedly problematic. But then I try those aforementioned libs and see sharp corners like terrible argument validations (in case of Sequel) which lead to silently failing code, or actual hard limitations on what I can ask Ecto to do without resorting to meta-programming. > I also haven't ever found a good replacement for AR migrations IME, both Sequel and Ecto migrations are fairly serviceable. But neither provides the schema dumping feature that AR has. Which is pretty handy.
lawn 6y ago
I can recommend the book "Programming Ecto". Previously I had only dabbled with ecto in the context of Phoenix, but it didn't really click for me either, but the book does a good job going through the different parts of Ecto and clearing up some of my confusion with it.
OkayPhysicist 6y ago
The trick to Ecto is that it serves as a separation between your data storage, and your data representation in your code. Basically, there're 3 parts. The first part is your schema. It defines an Elixir struct that is your domain model of your data. The second idea/part is the concept of a changeset. It represents a change you'd like to make to the data store, but haven't yet. These are composable, so you can bundle a bunch of changes into a single, atomic unit, which you then send to your repo. If any part fails, then the whole thing fails, no changes are made to the persisted data. The last thing is migrations, which strictly speaking are optional, but a huge convience. They define how you'd like your database to be structured. The cool thing about them is that they define rollback operations automatically. Once Ecto "clicks", it really becomes a strong selling point to the language as a whole. It makes working with persisted data super easy.
cultofmetatron 6y ago
For me ecto was a breath of fresh air. When I look at an ecto query, I'm never guessing about the output sql. It doesn't try to make relational queries look like objects. Often times I think, "how would I do this in sql" and there's usually a matching Ecto.Query operator that handles that.

by hazz99 6y ago

I just couldn’t get past ecto! It never seemed to “click” for me. Maybe I need to go back and learn it more in-depth, it sounds like it’ll be fantastic once I get the hang of it.

dnautics 6y ago

It's definitely not an orm, as it was stolen from c# linq. Imo this is actually much better than an orm because it really hits home that the data in memory are stale as soon as you receive them because database transactions are explicit, and not hidden behind getters and setters. ORMs can get you into trouble because they try really hard to hide the problem of distributed state and sources of truth.

hvis 6y ago
Coming from (the much-maligned) ActiveRecord, I wasn't really impressed. It has this cute macro-based syntax, and that seems to inform even the "functional" API as well. Yet when you I wanted to do something just a bit more advanced like joining on an association whose name I don't know in advance (or, say, want to parameterize the function with), I had to resort to writing a macro myself and then eval-ing it an runtime.
- oli_b 6y ago
  I had the same experience, but now I'm wondering - is ActiveRecord much maligned? It is news to me. It handles simple stuff really well, takes a lot of the pain out of relationships, and doesn't prevent you reaching for SQL when required. I also haven't ever found a good replacement for AR migrations, which makes schema changes + keeping a record of those changes absolutely seamless. Are there some alternatives I should be investigating?
  - hvis 6y ago
    > is ActiveRecord much maligned? Well, take the numerous articles extolling the virtues of Sequel, or DataMapper, or, related to the current discussion, Ecto itself. Like how expressive this stuff is. And how ActiveRecord creates a too huge API surface on models, and that that leads to bad design, etcetera. Now to mention the callbacks, which are admittedly problematic. But then I try those aforementioned libs and see sharp corners like terrible argument validations (in case of Sequel) which lead to silently failing code, or actual hard limitations on what I can ask Ecto to do without resorting to meta-programming. > I also haven't ever found a good replacement for AR migrations IME, both Sequel and Ecto migrations are fairly serviceable. But neither provides the schema dumping feature that AR has. Which is pretty handy.

lawn 6y ago

I can recommend the book "Programming Ecto". Previously I had only dabbled with ecto in the context of Phoenix, but it didn't really click for me either, but the book does a good job going through the different parts of Ecto and clearing up some of my confusion with it.

OkayPhysicist 6y ago

The trick to Ecto is that it serves as a separation between your data storage, and your data representation in your code. Basically, there're 3 parts. The first part is your schema. It defines an Elixir struct that is your domain model of your data. The second idea/part is the concept of a changeset. It represents a change you'd like to make to the data store, but haven't yet. These are composable, so you can bundle a bunch of changes into a single, atomic unit, which you then send to your repo. If any part fails, then the whole thing fails, no changes are made to the persisted data. The last thing is migrations, which strictly speaking are optional, but a huge convience. They define how you'd like your database to be structured. The cool thing about them is that they define rollback operations automatically. Once Ecto "clicks", it really becomes a strong selling point to the language as a whole. It makes working with persisted data super easy.

cultofmetatron 6y ago

For me ecto was a breath of fresh air. When I look at an ecto query, I'm never guessing about the output sql. It doesn't try to make relational queries look like objects. Often times I think, "how would I do this in sql" and there's usually a matching Ecto.Query operator that handles that.