Programming

13376 readers

1 users here now

All things programming and coding related. Subcommunity of Technology.

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 1 year ago

MODERATORS

alyaza@beehaw.org

Hexorg@beehaw.org

remington@beehaw.org

In the defence of Object-Relational Mappers (event-driven.io)

submitted 1 year ago by cwagner@beehaw.org to c/programming@beehaw.org

24 comments fedilink hide all child comments

I’m an accidental DBA, but I still never quite got the hate for ORMs. I thought this article does a good job explaining the issue, and why they aren’t so bad.

you are viewing a single comment's thread
view the rest of the comments

[–] Paradox@lemdro.id 2 points 1 year ago (4 children)

I much prefer the repository pattern, as used by sequel and Ecto

Your models are essentially just enhanced structs. They hold information about the shape of data. Generally don't hold any validations or logic related to storing the data. You perform changes on the data using changesets, which handle validation and generating the transaction to persist the data

It works extremely well, and I've yet to encounter the funky problems ActiveRecord could give you

[–] abhibeckert@beehaw.org 2 points 1 year ago* (last edited 1 year ago) (3 children)

OK, but what about reading the data?

I've never had a problem writing to a database with an ORM. The problems happen when you try to read data (quickly and efficiently).

[–] Paradox@lemdro.id 1 points 1 year ago* (last edited 1 year ago) (1 children)

Data comes out as a map or keyword list, which is then turned into the repository struct in question. If you want raw db data you can get that too. And you can have multiple structs that are backed by the same persistent dataset. It's quite elegant.

Queries themselves are constructed using a language that is near SQL, but far more composable:

Repo.one(from p in Post, join: c in assoc(p, :comments), where: p.id == ^post_id)

Queries themselves are composable

query = from u in User, where: u.age > 18

query = from u in query, select: u.name

And can be written in a keyword style, like the above examples, or a functional style, like the rest of elixir:

User
|> where([u], u.age > 18)
|> select([u], u.name)

None of these "queries" will execute until you tell the Repo to do something. For that, you have commands like Repo.all and Repo.one, the latter of which sticks a limit: 1 on the end of the provided query

[–] abhibeckert@beehaw.org 1 points 1 year ago* (last edited 1 year ago)

I wouldn't call that "near" SQL, I'd basically just call it SQL. Nothing wrong with that... SQL is great, and using proper language constructs instead of strings makes it even better... but it's not solving the some problem as an ORM.

load more comments (1 replies)