Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

To ORM or Not to ORM

eli.thegreenplace.net

Post reply on HN
Print view View original

231–240 of 300 posts

Re: To ORM or Not to ORM

#231

Post by udfalkso »

out_of_protocol wrote: post #102

For everyone complaining about orm-something - take a look at elixir's Ecto. It basically allows writing sql via native code. Good for composability, type casting, stuff like that. Account |> where(active: true) |> join(:left, [a], p in Post, on: p.account_id == a.id) |> where([a, p], a.foo == "bar" or p.bar == "foo") |> group_by([a, p], a.id) |> select(...) |> limit(10) ... |> Repo.all() Plus there are changesets fo…

Came here to say this. Ecto is solid. Also, the results come back as elixir structs and not bloated objects so it’s much faster than ORMs in many other languages. Additionally, the functional approach makes everything much less magical.

Changesets can take a little while to grok, but they work.

Re: To ORM or Not to ORM

#232

Post by zbentley »

spion wrote: post #208
derefr wrote: post #206

Earlier quoted context omitted.

So don't map DB records to objects, then. DB records are records , and their proper typing in your business logic is as records —chunks of plain old data, strongly-typed, that your (OO or otherwise) code can declare DB-side interfaces against. The only responsibilities of the module/class that owns the record type, should be getting things converted into and out of that record type. Plain-old-data DB record types (an…

Would that be a "RRM" (Record-Relational mapper)? If so we're already on board (in a different language). P.S. I bet you would never guess which typed language with great support for records makes it easy (for the most part) to build most type-safe SQL queries on the fly, even with projections, without explicitly defining types for every possible projection variation.

Lots of Python codebases are on board with that (and I assume codebases in other languages are as well). It's by convention rather than language-level support, but works perfectly well: don't bolt business logic onto your ORM classes' methods, handle those elsewhere in a separate layer whose conventions you define. Works great.

Re: To ORM or Not to ORM

#233

Post by SOLAR_FIELDS »

mikeryan wrote: post #220
SOLAR_FIELDS wrote: post #201

Earlier quoted context omitted.

Lack of adequate support for versioning your schema and in general bad support for anything versioning with RDBMS is one of the main dislikes I have for SQL. I find SQL to be a beautifully expressive language when you get the hang of it, but no RDBMS that I know of has been able to adequately tackle the versioning problem at both the schema and the script level. Everyone's schema evolves over time, why is it so diffi…

This is a big thing for me. Most ORMs I’ve used have decent migration tools which is a huge benefit for managing your schema. We enforce changing Schemas via migrations as opposed to any sort of auto-migrations some packages offer. Makes life a ton easier being able to put these changes into a build pipeline.

Migrations (or evolutions, depending on the language you are using) are a joy when implemented properly. Alembic and Play Evolutions are two frameworks that I have dealt with specifically that are pretty great and hard to go back from.

Re: To ORM or Not to ORM

#234

Post by sandreas »

Another advantage that i've come across and that has not been mentioned so far is, that an ORM can help you a LOT, when implementing role based access control (RBAC).

Mapping the objects and having all the metadata had huge advantages over pure SQL, if convention over configuration is used to control access to the given objects with a User/Role Entity - and object inheritance gives you the ability to add a "created_by", "modified_by" to each table for controlling even access to the row level...

Re: To ORM or Not to ORM

#235

Post by fwip »

chaostheory wrote: post #217
megous wrote: post #61

Earlier quoted context omitted.

SQL injection is prevented by not using user input as a part of the SQL query. It's orthogonal concern to whether to use ORM or not.

I'm not sure I understand since there are common cases where you have no choice but to deal with user input. Sure you can manually escape user input in your manual sql calls, but if you're doing that manually there's no hard guarantee that you'll always escape that input vs using an ORM.

Christ, no, don't escape user input in SQL. Just use parameterized queries.

Re: To ORM or Not to ORM

#236

Post by philwelch »

yawaramin wrote: post #221
idoubtit wrote: post #132

Earlier quoted context omitted.

> ORM's are easy but not simple. ORM libraries may not be simple, but what matters is the code that uses them. My experience was that the main code was often easier and simpler. Easier because small tasks are made easy. Simpler because it makes the code more consistent: for instance, once you know the ORM, you don't have to deal with hundreds of specific cases that insert or update various records. Promoting stored p…

> Simpler because it makes the code more consistent: for instance, once you know the ORM, you don't have to deal with hundreds of specific cases that insert or update various records. That's not what 'simpler' means in this context. Simpler means conceptually independent things aren't coupled together. For example, ORMs couple together object-oriented code and relational objects. That's the essential complexity that…

Pretty much agreed. Two things to add:

> Simpler means conceptually independent things aren't coupled together. For example, ORMs couple together object-oriented code and relational objects. That's the essential complexity that they introduce.

I don't actually agree that this is where the complexity comes from. The complexity comes from what makes ORM so appealing in the first place. Your ORM can dynamically generate an infinite variety of queries based on how you use it, which makes it a big piece of machinery with many moving parts, the behavior of which you will have to understand and manage even if you didn't build it yourself. This machinery may break, it may behave in undesired or unpredicted ways, it may consume compute resources inefficiently, and if it does any of those things, you're still on the hook to take care of it because it affects the behavior of your product.

Ultimately, you will always have to map some behavior in your service code to an intended SQL query and then map the result set back to in-memory data. Doing so in a consistent way can potentially reduce complexity, though in a lot of cases, you can probably get away with treating a SQL result set as a list of associative arrays, or even a list of objects as long as you tell it what class to deserialize into (which is what many ORMs do anyway).

> There's still the old-fashioned way of checking them into the repo as part of migrations.

Yes, even many ORM-based services have DB migrations in the service repo already.[1]

You could also version-control the stored procedures, database migrations, etc. as its own software artifact. You can think of a relational database as a service (microservice?) that speaks SQL instead of HTTP or GraphQL or GRPC. It's listening to a port somewhere on your network, it consumes computational resources, it will be deployed independently of your service in such a way that you have to worry about backwards compatibility, it can become unavailable to your service, and so forth. And like most services, you may prefer to have a defined, optimized, versioned interface to your DB instead of just trusting your consuming services to execute arbitrary (SQL) code. This is not necessarily the right or wrong solution for you, but it's reasonable enough.

[1] One possible niche might be an ORM that builds all of your DB manipulation commands into parameterized SQL at compile time and installs those SQL statements as stored procedures via the migration mechanism. Then you really can write raw SQL when you need to, by hardcoding your stored procedure instead of compiling it. This would work best on a DB that you could migrate whenever you felt like it, but I've heard Postgres is one of those.

Re: To ORM or Not to ORM

#237

Post by yawaramin »

philwelch wrote: post #236
yawaramin wrote: post #221

Earlier quoted context omitted.

> Simpler because it makes the code more consistent: for instance, once you know the ORM, you don't have to deal with hundreds of specific cases that insert or update various records. That's not what 'simpler' means in this context. Simpler means conceptually independent things aren't coupled together. For example, ORMs couple together object-oriented code and relational objects. That's the essential complexity that…

Pretty much agreed. Two things to add: > Simpler means conceptually independent things aren't coupled together. For example, ORMs couple together object-oriented code and relational objects. That's the essential complexity that they introduce. I don't actually agree that this is where the complexity comes from. The complexity comes from what makes ORM so appealing in the first place. Your ORM can dynamically generate…

> You can think of a relational database as a service (microservice?) that speaks SQL

Exactly. As a colleague of mine once said: stored procedures are the original microservices. A bit tongue-in-cheek, but the point is you can treat stored procs as these lightweight services. You don't even have to write the SQL, just call the procs with the right arguments. That's one scenario, anyway.

Re: To ORM or Not to ORM

#238

Post by Benjamin_Dobell »

gmac wrote: post #126
hardwaresofton wrote: post #65

While I learn towards not using an ORM, the productivity gains (at the very least early on in development) are undeniable. What I've always looked for are frameworks that give you an ORM but also make lower level queries very easy, normally via a query builder, allowing you to go back and forth between levels of abstraction. If I had to choose, I prefer libraries that give you the lower level of abstractions first an…

I loved TypeORM initially, but came to the conclusion that it was written by people who really got TypeScript, but didn't really get SQL. For example, we were converting from Sequelize, where we were catching unique constraint violations and responding appropriately, and we got quite confused that in TypeORM those errors never got thrown ... until we discovered that TypeORM decides unilaterally (and almost unbelievab…

I couldn't agree with this more. I've just started using TypeORM and the TypeScript aspect is great. However, here I am trying to do a simple distinct left join, but it's extremely difficult to write because the query APIs consistently get in the way.

We're regularly receiving invalid SQL errors, which from a typed language/API seems particularly odd.

We're doing this exact same query on the exact same DB in ActiveRecord/Ruby and it's trivial to both write and understand.

Re: To ORM or Not to ORM

#239

Post by Noumenon72 »

cies wrote: post #173
echelon wrote: post #165

In my experience ORM always shoots you in the foot when your use case exceeds what an ORM can provide. ActiveRecord has been a terrible mess for us because the facade masks the underlying behavior (transactional behavior) or often doesn't do what it advertises (commit hooks, timestamps, auto-increment). ORM is great for startups trying to build out an MVP, but beyond that scale it's an anti-pattern. The best solution…

I came here to say that any article discussing the benefits/downsides of ORMs should include JOOQ. It takes such an interesting spot in the design space: not an ORM, but a super flexible, type-safe query builder with lots of helpers so you dont write more code than necessary.

I work at a place with sort of a homebuilt ActiveRecord system made of generated code. JooQ did all the same mapping and object creation just by inspecting my database with a bunch of boilerplate Maven XML, so I wouldn't have to rely on the homebuilt version of SQL join.
Post reply on HN