Comment by bruce511 | Hacker News Reader

Comment by bruce511 | Hacker News Reader

Parent Full thread

>> but the core benefit is that the same code should work on multiple different hardware devices.

I came here to say this. Attractions act as a bridge between things which allow those things to change independently.

Using an ORM allows my program to easily work against multiple sql databases. Using a compiler allows me to target different hardware. Using standard protocols allows me to communicate with different programs. Using libraries to do say email hides me from those protocols and allows me to adapt to service providers Using APIs not protocols.

In other words the abstraction is designed to hide a layer (which can change) from a program not interested in that level of change.

The key is to stop abstracting when the program cares. By all means encapsulate rules and processes, but they're a direct implementation of those rules and processes.

One can argue my "calculateLeaveForEmployee" function is an "abstraction" - but that would be a misnomer. Since there's only one set of rules in play (the set that matters now) its an implementation. An abstraction supports (at least) two things at the same time.

> Using an ORM allows my program to easily work against multiple sql databases.

A curious example, since most developers who've worked on any project with significant amount of data in a database would likely disagree.

IMO, ORMs mostly allow using programming-language-of-choice as a syntax for relational queries instead of constructing it by hand on top of serialization and deserialization of objects into rows and vice versa.

Indeed, given that most sql dialects have subtle differences that make them noncompatible with one another, and most ORMs have support for dipping into raw sql, sufficiently large systems tend to end up coupled with a particular database anyway. That's not to mention that the BAs will want raw sql access for report writing and switching systems breaks all of their scripts too.

Yes, ORMs came to mind for me as an example of indirection without abstraction. If you accept OP’s litmus test of “how often do I have to peek under the hood” I think ORMs generally don’t score particularly well.

If enabling the ablity to think of the database as the rich native data structures provided by the host programming language, and not the tables (rows and columns) that the underlying database service wants to think of the data as is not an abstraction, what is?

Fair, it’s probably incorrect to say there’s “no abstraction” in an ORM, maybe more precise to say it’s quite a leaky one. I’ve never seen an ORM used in the wild where you could actually avoid thinking about tables and columns and rows pretty frequently. But that’s admittedly armchair anecdotal.

In the small-to-medium scale cases I’ve seen, the main re-use you get for a particular mapping is when an object is used as a child node elsewhere. If it’s a one-off you’re essentially writing a bespoke shorthand wrapper for some custom SQL. Which may be a convenient shortcut or prettifier, but isn’t really functioning as an abstraction. Net net it seems like more overhead. Or like the real benefit is constraining database design to closely align with object design (which could be valuable but isn’t a function of abstraction).

This is all assuming code ownership across the stack. With a separate team managing data representation and handing reliable object contracts “over the wall” I could imagine a situation where the consumer gets to think purely in objects. I just haven’t observed that in practice. E.g. What if the contact has two address records? What if the number of purchase records exceeds the maximum result size? If things like that come up regularly enough, it’s worse when you’re waiting on a separate team to fix the leaks.

> I’ve never seen an ORM used in the wild where you could actually avoid thinking about tables and columns and rows pretty frequently.

There is a compelling argument that absent the n+1 problem, it could be a leak-free abstraction. And, in practice, SQLite doesn't suffer from the n+1 problem... But that is definitely true in a lot of cases, particularly where the n+1 problem is unavoidable.

> If it’s a one-off you’re essentially writing a bespoke shorthand wrapper for some custom SQL.

While the original comment also conflated query building and ORM, I am not sure that we should. The intersection of query building and ORM was historically referred to as the active record pattern. I suspect the ActiveRecord library, from Rails, calling itself an ORM is where things started to become confused. Regardless, whatever you want to call the data mapping and query building, they are undeniably distinct operations.

It may be fair to say that query builders are no more than an indirection. That said, I posit that they only exist as an abstraction to model composability on top of SQL. If SQL naturally composed through basic string concatenation, I expect the use of query builders would quickly disappear.

But SQL is "naturally composable" using string concatenation. I've seen one too many of

  tables = ["order", "product"]
  join_on = ["order.product_id = product.id"]
  filters = []

as the base of the query, with all of these being concatenated together.

But instead of this, an ORM usually provides you with a syntax (that will pass syntax checks and have highlighting) that matches the language, which is all nice and good because dealing with arbitrary strings does suck.

I've seen ORMs being used for query composition way before Rails even existed: I believe Hibernate had HQL with their first release in 2001, just like SQLObject did in 2002. I am sure neither of those "invented" the pattern.

Note that fetching objects using an ORM library, filtering and such is what I also consider query composition (it just happens behind the scenes).

> But SQL is "naturally composable" using string concatenation.

It is not. Not even in a simple case. Consider:

    base = "SELECT * FROM table LIMIT 10"
    cond1 = "WHERE foo = 1"
    cond2 = "WHERE bar = 2"

base + cond1 + cond2 or any similar combination will not produce a valid query. It could if SQL had some thought put into it. There are many languages that have no problem with such things. But that irrational fear of moving beyond the 1970s when it comes to SQL...

The only realistic way to assemble queries is to prepare an AST-like structure to figure out where the pieces fit, and then write that out to a final query string. In practice, that means either first parsing the partial queries into that structure (hard) or providing a somewhat SQL looking API in the host language that builds the structure (easy). Unsurprisingly, most people choose what is easy.

> I am sure neither of those "invented" the pattern.

None of these invented the pattern. But the invention point is irrelevant anyway. You must have misread something?

ORM, as the name suggests, is an "adaptation" layer ("mapping" or "mapper").

It does not really abstract away relational data, it instead maps it to object/class hierarchy. And every single ORM I've used also provides an interface to map function/method/expression syntax to SQL queries to get back those rows (adapted into objects).

Now, in a very broad sense, mapping would also be an abstraction — just like an "indirection" would be — but considering the narrower definition from the OP (where indirection is not an abstraction), I think it's fair to say that ORM is also not an abstraction.

It's interesting that some modern ORMs are dropping trying to abstract out the dB engine. Specifically thinking of Drizzle for js. And rather just focusing on the programming interface

> allows my program to easily work against multiple sql databases

How many times have you required that your program runs against different sql databases without modification?

I mean, how many times have you required your plane to be able to fly in the different atmospheres of different planets of the Solar System?

Unless you are NASA, I suggest you cut the complexity and just make a plane that can fly well on Earth's atmosphere.

>> How many times have you required that your program runs against different sql databases without modification?

Our main commercial product currently supports 2 database engines, and we'll be offering a 3rd next year. For enterprise offerings it's pretty common for the client to prefer, or outright specify, the engine.

Commodotizing your complementary technology is a good way to not become dependent on any specific database, and hence can pivot quickly when required.

Fortunately I don't have a plane, so I don't have code to fly in any atmosphere.

Yes, yes, you are NASA.

The rest of us go with Postgres, or SQL server, or Oracle, but definitely don't have to prepare our systems to run in PostgreSQL on Mondays, on SQL server on Tuesdays and so on.

If the pivoting never happens then the effort will have been wasted. Adding features because of "what if" is the worst engineering sin.

Reply on news.ycombinator.com