Objection to ORM Hatred (2019)
jakso.me
jakso.me
- SQL is so easy and so useful that being a professional engineer that can code but can't learn SQL is absurd
- You will never switch databases, so abstracting away the DB for some hypothetical "I might want to switch DBs one day!" scenario is absurd
- If you ever get enough scale to require optimization the ORM will be your enemy
In summation, anything related to ORMs and SQL is immediately invalid, other than questions like "Help! I joined a company where they mandate ORMs and I hate my life!"
You actually might switch databases at some point, but in my experience this always included overriding some of the ORM-queries with custom ones that the particular RDBMS needed for some reason.
So you have to write SQL after all when switching, might as well do it from the beginning.
On "great" side of things, Linq brought massive type safety to .net land, and made queries also compile time checked.
IS it leaky? yes. Every once in a while you'll need to write SQL. Does it solve a lot of problems? Also yes.
Disclaimer: I was once a contributor to NHibernate.
Such a waste of time to maintain that conversion code by hand.
Alas, it's far from a complete solution. It's too easy to type an expression that compiles but blows up at runtime because the underlying provider doesn't support it or gets confused.
But it was still great for majority of cases.
Not sure if that's enough to justify ORMs, but DB migration is a real use case and there are things you can do ahead of time to greatly simplify the process.
- Convenience of using SQL from $LANGUAGE where mapping the result, (re)naming, etc. is handled for you. Do this manually, and eventually you will either make silly mistakes or create your own mini-framework.
- Connection pooling / retrying if desired. Can be done without, but again mini-framework.
- Migrations. Generating a schema from code is neat.
- Making our lives miserable when the ORM inevitably generates horrible SQL somewhere and we need to override it manually. That is, ORMs are NOT a replacement for learning SQL.
- saving object graphs: it's trivial to write SQL for a simple CRUD form. It's far more difficult to work with real models where you have to deconstruct the form the user posted into a dozen tables with joins between them, doing insert/update/delete as needed. With a decent ORM you simply construct an object graph by assigning fields (the result can be very complicated), shove that into the database, and the ORM takes care of the rest. It may not be web scale™, but many of us don't need that.
- constructing queries on the fly: if you ever get any exposure to LINQ, I don't think you'll want to go back to SQL after that. It allows you to easily construct queries based on user input (in a type-safe way, unlike some other solutions), which saved me countless hours when building complicated tables with search and filtering on many (sometimes hundreds) of fields.
Here is a trivial example: https://stackoverflow.com/a/10884757
And with good ORMs like Entity Framework the underlying queries they generate are predictable.
Right up until they are not and generate crap. I went from "predictable" EF generated queries to handcrafted ones reduced the load on the DB by about 70% while having more queries per second...
But if I have to do OOP on data from database I much prefer ORM over doing it manually.
No, you may never have had to switch databases, but I have worked on codebases where we've had to switch databases, and I'm sure others have to. Most likely when dealing with monoliths where you can't do a full re-write and you can't break out a separate service for various reasons. The repository pattern is your friend in these situations. An ORM should ideally be able to read/write to multiple database drivers which makes this easy by dual-writing to both databases from the repository layer.
Good luck doing that with hand-coded SQL.
But for me 99% of the benefit of using an ORM is compile-time checking of queries. I don't see why in principle that couldn't be possible using raw SQL, but I don't know of any good examples of it.
I have never seen argument “I use ORM so I don’t need to know SQL”.
It is always people who boast they know SQL that they don’t need to know ORM.
SQL is not hard, it just sucks. Massively. "So useful" in the same way BASIC was useful for 80's computers.
- You will never switch databases
You might not want, but you might need to
- If you ever get enough scale to require optimization the ORM will be your enemy
BS. Most ORMs do let you drop into SQL, no problem. This is usually one or two queries on a whole project that merit this treatment
If things are slow you can probably optimize stuff at the ORM level itself (or your modeling was done by interns - which would be a problem regardless of ORM or no ORM)
In my experience Java domain code written with an ORM is about 4x the LOC compared to using stored procedures to do the same job.
Oh - and that 4x LOC gets you about 1/4 the performance, loosely speaking.
I am a substantially more productive developer since I kicked all those abstractions to the kerb.
It is the database and its structure that is the important part of an application. Building an additional layer of abstraction on top of an already existing abstraction no longer makes sense to me.
My reason is that there are no good object databases yet. I would want something that allows you to take your C++ vector or Python list of plain old objects, and stuff it into a data structure:
- with a choice of rowwise (array-of-struct) or columnwise (struct-of-array) storage
- with custom indexes (e.g. not just map<string, MyStruct>, but Database<MyStruct> and tell it to index of propertyA, propertyB, ...)
basically taking performance oriented aspects of relational databases and applying them to an in-language data structure, without leaving the world of trees and objects. Back to the question, an ORM is for me not an alternative to SQL - it is an alternative to dicts and list comprehensions and manual storage.
I use Django a lot and have found the ORM invaluable for all use cases and can be optimised when needed, with some friction.
There's a reason why the modern approach is parameterized: The old PHP-style templating led to galore SQL injections, and worse performance. Don't see any reason to ever go back.
Tagged templates in js allow you to write safe, injection free sql templates, tsql does exactly that.
Performance is better if anything, but irrelevant - you're talking about sql rendering performance, which is several orders of magnitude lower than invoking query?
You should double check it. See examples of usage. We use it for mssql but same principles apply to other vendors. Mssql has many interesting things in its dialect that can't be expressed in orm. With templates you simply write sql and aid yourself with functional combinators for complex statements. It works really well.
I have a number of hobby projects that work with both SQLite and Postgres by virtue of a ORM. SQLite is great for testing and lightweight installs, while Postgres scaled much better.
So yes, there are absolutely use-cases where the ability to switch DBs is very valuable.
We used SQLAlchemy on a Python project which allowed us to use an in-memory SQLite DB in our integration tests. This gave us blazingly fast database tests during development where a database was torn down and recreated, with data, for each test in milliseconds. When the commits were pushed, CI would run the tests against SQLite and MySql.
It worked extremely well and would be a tremendous amount of effort to handwrite SQL for both DBs. I'd do it on ever project if I could.
But no unit test environment is ever going to emulate everything in production, nor should it.
Hence why they were run against MySql on CI.
I use pg and test suites run in parallel against their own db. It’s pretty cheap with CREATE DATABASE helpers plus using container means little to no headache.
The main reason to write mostly generic SQL is so new hire-ees can get up to speed.
So this is an interesting one. We didn’t switch databases, but deployed the same application in some different infrastructure due to how different companies in our “group” have different setup. So we went from having an API running in Azure connecting to a DB running in MS SQL Server, and had to also deploy that (with some UI changes) to Google Cloud with postgres DB.
It went surprisingly well, but there were a few fiddly bits and I was quite glad I didn’t have to worry about the DB interaction, EF Core handled it for us
One of the main reasons that Django has been so popular for so long is the idea of reusable "apps". Eg, Django Admin, which comes bundled with Django but there are also thousands of 3rd party ones that you can use to quickly put together very powerful sets of features out of polished, tested pieces. That whole ecosystem really only works because of the ORM, which means that apps mostly don't have to know/care what database might be used. (I assume some other frameworks have similar stories, but Django's what I'm most familiar with).
As far as scaling, I've developed and supported Django apps that have hundreds of thousands of users and serve thousands of requests per second. I would probably not even put the ORM in the top ten list of problems with achieving scale. I've occasionally found it generating slow queries and had to tweak or bypass it (both extremely easy to do) but honestly, those have been low hanging fruit when it comes to optimizing (and very easy to find thanks to reusable apps like `django-debug-toolbar`, which exists at least in part because of the ORM). Are ORMs unteneble once you're in the millions of users or tens of thousands of requests per second range? Maybe. But that's a very small part of the software landscape and for the vast, vast majority of the rest of us, a good ORM isn't going to be the problem.
Actually, knowing how to write efficient SQL is very well rewarded by the market.
So adding another layer on top of it, an ORM, is IMHO not a good idea.
Also...
I've seen several anti-pattern usages where someone would query a list of IDs, and then in a loop with an accumulator fetch data from another table, one ID at a time.
If you don't grok joins, and someone tells you "yeah whatever don't bother learning SQL, we have an ORM", this happens.
An ORM is an anti-tool.
Can't we just just accept a tool that augments and improves something without caring that it's not a complete and perfect abstraction over another technology? I use an ORM every day and I also use SQL every day. The ORM is such an improvement for what it does that of course I would use it. But I'm not restricted to using it. In fact, most ORMs encourage mixing SQL with their API; that's not a leaking abstraction -- it's bringing the fire hose.
I agree - I would much rather write SQL. But like others have said in this thread, I hate writing custom code to translate anything but the simplest queries into what I actually need.
I also hate trying to combine slightly different queries with custom string manipulation that turns into 750 lines of code before you know it. Most ORMs handle that use case very well.
I have never ever met anyone who genuinely used ORM claim that in any form of shape. The only ever place where I’ve seen it is threads about “how bad ORMs are”, so it is only a strawmen.
ORMs are first and foremost a tool for OLTP-based workflows, helping mapping between objects and db rows, especially for insertions. They are also very great for CRUD operations on tables. They were never meant to abstract away the SQL model, that is one necessarily has to know the underlying tables, and often write queries with manual joins, etc (many ORMs allow custom queries in a cross-DB way). But even in these cases mapping the result is very convenient with an ORM.
I created and use Kanel ([link redacted]) to generate Typescript types from my Postgres database which helps a lot. Knex itself has some attempt at type safety but it gets confused quite quickly, so that's where it's tempting to override things.
Compared to plain SQL, the obvious advantage is that you don't have to work with string replacements, but a bit of readability/maintainability is lost because of emerging complexity. Compared to an ORM there is much less working around it's quirks, but also the danger of re-inventing a good part of it.
Btw they also wrote up a sizeable number of record types, Kanel looks interesting for auto-generating those - thanks!
I myself went the route of “lets just have raw sql queries” but extract distinct and specific types from them automatically- https://github.com/ivank/potygen
Great thing is that it handles sql of any complexity - CTEs, views, nested selects/joins/unions/custom functions you name it. All tools you can use to encapsulate logic in sql itself (what ORM were supposed to be for) and then have it be statically validated at compile time thus saving you the need for righting all those trivial unit tests that was also one of the key benefits of ORMs.
Admittedly if there was something like LINQ I would probably not have ventured into building potygen, but I’m glad I did as I learned so much about SQL as a language and what it had to offer - its silly how much logic I used to rely on writing in code that could easily be handled by sql in a much mode concise way.
So yeah its all pure JS, and not produced from a parser generator.
With Prisma I like the ability to generate migrations and the DB schema from a single schema definition file. I also like the autogenerated simple crud use cases.
It did not take long to have to go raw. A simple case of selecting the top most occurring unique columns from a table with a join to limit by user id is brutally trivial oneliner in SQL that just rolls off the keyboard. I took a good try to do the same with Prisma and I believe it can be done, but the complexity of what the DSL will look like is laughable.
So I still have the same opinion I've had for these past years, ORMs are okay for simple crud stuff but the moment you need something slightly beyond that bailing for the raw sql is the best thing that you can possibly do for the maintenance team that comes after you have changed projects.
I wish I knew more good options to try, but in JS, I've tangled with Knex (and some Bookshelf, which I have over time felt compounds the problems), and while it usually starts off okay but repetitive, with little shared code, it's rarely clear whether what you want to do is just impossible without gratuitous .raw() madness spiced in or not.
I've seen too many engineers try to out-engineer the limited help something like Knex can offer, try to make better libraries of tools to do common queries. These confound & limit, again and again, provide long term pain, suffering, & misery for everyone who latter stumbles upon them. There's good heart here, but we'd have been better served by a library of knex and/or sql queries to derive from & rewrite, rather than these painful attempts to write higher level tools, which always fall short of the in-practice needs. The sheer expressiveness of sql keeps feeling unmatched, and attempts to capture the main cases keep becoming painful stumbling blocks that limit comprehension & growability. SQL keeps feeling more appealing.
Thinking of using prims ORM for my next side project.
Granted, it doesn't do everything (it just does what it needs to not be hated). I used it because it does the boring error-prone bits of manual SQL but not much else.
- connection pooling, multiple drivers
- core layer (can use to build sql without orm, describe table metadata, output ddl, etc.)
- orm layer (automatic class to table mapping, relationships, configurable relationship loading strategies, easy ad-hoc optimization of loading objects, write custom SQL to load objects, load relationships from subqueries, etc.)
- db reflection
- db inspection
- migrations (via alembic)
- now supports async drivers
- 2.0 coming out soon with more consistent interfaces
edited: formatting
Hibernate: a fairly "traditional" ORM, that can abstract away SQL almost entirely, it even has a DB-agnostic DSL for some use cases (HQL)
myBatis: an ORM that lets you write actual SQL in mappers and generate statements dynamically, with conditions/loops/etc. defined in XML
jOOQ: an attempt at letting you generate queries in pure Java code (as opposed to the myBatis approach), which looks a bit like the one in the article
JDBI: a very lightweight wrapper on top of JDBC, which perhaps isn't a full ORM, but makes querying the database with SQL a bit easier
(probably some others, too)
That way, if you ever need to debug how something is selected, then you can simply look at the data in the view, which is going to be the problem in most cases. In my eyes, that's a good way to also avoid running into the N+1 problem too often - if there's a table in your APP (a list in your API) that you need to populate with data, that might as well be a single query against MY_BUSINESS_DATA_V or something like that.
As for doing the opposite - modifying data, you might also benefit from simple mappings, perhaps even taking advantage of some of the codegen capabilities available. Point a CLI tool at where an instance of your DB is running and generate your entities from the existing schema (or vice versa). As long as you don't have too complex DB types, it shouldn't be too bad.
If you choose a different approach, in my experience you'll spend a lot of time struggling with the internal complexity of the ORM. Hibernate is a good example of this, I've seen people spend entire days trying out how to express their super complex queries in the ORM, not really knowing how to get the equivalent of whatever SQL they need.
SQL is good for working with data, so do that whenever it feels like a good fit for your problem. SQL is sometimes worse for certain other aspects (if you need CPU intensive processing for a limited subset of data, subjectively also readability, how expressive the code is, testing, logging, tracing, the available libraries and so on; things that general purpose languages can do better) so don't try to put everything in SQL either. Try to bridge the gap between SQL and whatever language you're using in a low friction way, if possible.
Let's say I wanted to build an abstraction on top of ORMs. You would think I'm crazy. Why? Pause here for a bit.
Your rationale here... is exactly why you don't want to build an abstraction over SQL.
Anyway. The author does have a somewhat valid point about the auto joining of foreign key relationships on a table. But this is only one missing feature. Creating a whole new high level dsl on top of another high level dsl just for this is over engineering.
The real abstraction needed here is some sort of extension to SQL. Either extend the language itself in the standards, or the implementation or typescript style via transpilation.
The only other valid reasoning behind ORMs is just cosmetic such that you don't have to have to deal with SQL primitives as strings inside another language.
I'm not sure that's a truism at all
For the same reason why Translating python to ruby is generally and obviously pointless.
The main thing that makes ORMs alluring is that people don't like to mess with a language in a language. Dealing with strings is inelegant.
Seeing why the orm is worse then string manipulation requires a 4 dimensional perspective shift that's really hard for people to comprehend.
Or any high level language built on a highly abstracted VM? Are they bad just because of their abstraction degree?
Highness of abstractions is relative not absolute.
What about a UI library? Or image manipulation library? Must you mutate a bitmap yourself?
I don't think it always holds true, but rather many poor tools happen to be leaky abstractions or compounded leaky abstractions.
I don't think the "level" is important except where any lower level is a bad foundation.
They're not all bad foundations.
Typescript and sass are extensions, that's why they are good. ORMs are not extensions.
Before the advent of advanced natural language processing like chatGPT, SQL was literally one of the highest level of language abstractions we can arrive at. It's declarative and English like.
Thus, given that SQL is generally at the highest level... any abstraction you would've built on top SQL would inevitably and in general not be higher. These abstractions are movements in progress that are horizontal in nature and therefore relatively pointless.
The point of most abstractions is to provide a higher level interface. An orm does not do this. Instead an orm is a shift in philosophy that declares the SQL philosophy to be incorrect.
I don't completely disagree with that philosophy. But the proper way to implement your philosophy is to write a database; not a transpiler that transpiles your philosophy onto a technology with a different philosophy.
I think too many people try and discuss tools based on things that aren't relevant or are idealistic or that remove the nuance from the argument.
Does transpiling make for a bad tool? Depends on the use case. Does mapping from tables to objects make a bad tool, again depends on the use case.
I think any discussion of tools without a clearly scoped use case is next to useless.
Some people think the universe is just apple and oranges. Everything is a tool that can be used somewhere nothing is truly good or bad. Well how about that? On the entire earth there isn't a technology that is absolutely great or raw shit and anyone who has such an opinion lacks nuance or is too idealistic.
No. To over-rely on nuance is to say nothing is black and nothing is white and everything is nuanced even when the nuance is inconsequential. This is wrong. Generalities and essential truths exist. For example, punching yourself in the face is generally bad, but if you talk about nuance and context then if you had a poisonous bug on your face, then punching yourself to save your own life is a good thing. But despite this the generality remains true.
The nuance for ORMs is only this: if you want to create a tree or a graph for graph algorithms like bfs or dfs on top of a non graph database then ORMs are literally the main abstraction to use. That's it. This is rare, because usually you have other databases other then relational that are better for this. But if you don't have the resources to load an entirely new type of database into production then ORMs are one way to perform graph algorithms on an existing SQL database.
For this instance the situation is clear, the nuance is negligible. ORMs are bad for most cases the same way eating poison is bad for you in most cases. If you want to talk about the nuance of when eating poison is sometimes good for you, be my guest. But the generality remains true.
>I think any discussion of tools without a clearly scoped use case is next to useless.
Agreed. Let's scope it to the all practical use cases seen in the wild. My argument is for the vast majority of use cases ORMs provide little benefit other then cosmetic.
This whole thing about scope is quite pointless imo. Because obviously the above scope I described basically what I'm referring to. You know it. Why do I need to spell this out specifically or be useless? Shouldn't the implication of scope be derived automatically from the discussion via usage of common sense?
You said it yourself, if you want to store a graph (in memory object instancss referring to each other by reference) in a non-graph database (say postgres or mysql) then an ORM is the thing to use.
This is literally what everyone uses them for. You defined their use, and that's what we're all doing with them and finding immense value from them doing it simply.
It isn't rare. It is literally the common case in every web app everywhere. There are more examples of an ORM being good and providing value, in the real world than not.
I'll just carry on using them and finding them valuable, and in the rare corner case their limit is exceeded then take the harder or more complex option.
Best tool for the job.
Anyway. Dfs or bfs queries are extremely rare in SQL and much of web dev too and they still can be done without an orm and all within database code. The amount of times you see a recursive query is the amount of times an orm would've made that slightly easier. Not worth an entire abstraction for such a rare and impractical feature.
If what you say is true and it's not rare, then I offer you the concept of a graph database that's designed for graph algorithms. That is the "best tool for the job" rendering the orm not the best at anything.
(I edited this from "your logic" to the "logic you present" not making any remark on your intelligence here hope it doesn't come off that way)
I use an ORM because it is cheap, easy, quick, uses a known quantity database which is readily available and deployable and allows me to solve my business case with relatively low complexity exposure and risk.
Best tool for the job. Best, as subjectively defined by me, for my needs as I see them in this un-black-and-white world.
Idealism is the enemy of done and I care about done (with proper engineering constraints) much more than "right". I care even less about trying to define a vague approximation of "right" when there's things to get "done" and the ORM I use is tried and tested to get things done.
That's my use case. Done. That's my tool for that use case.
Everything else is balancing debt, risk and entropy. Right doesn't factor into it for me.
It is quite liberating.
Nobody is talking about idealism. It's all practical. What my claim is this: You are wrong. In both cases you can get things "done" but you'd get things done faster and more easily without the ORM, you just don't know it. That's the claim I am making.
Your claim is that my reasoning is based on theoretical ideals. But I never stated such a thing, so I am stating it now: The basis of my logic rests on practicality NOT idealism.
The funny thing is, SQL as strings is viewed as more "practical" given how inelegant and "un-ideal" string manipulation is. The ORM is more of the misguided attempt to reach an idealism through abstraction.
* Apps (usually) only use
(materialized?) view tables
* Deployments are checked in as
migrations
* Aggressively leverage db features
like caching or other specific
performance features (not just
indexing)
* GraphQL to firewall backend devs from
rapidly changing frontend "widget"
requestsI believe the root cause is that many programmers do not like string manipulations inside their very own programming "language", be it Spring Boot or Nodejs /s
You need a higher level perspective shift to realize that the orm is actually the uglier abstraction then just using plain strings.
What I find is that a good ide or editor is capable of doing this for a string if you tell it what that string is.
Static checks are not a reason to create a whole new abstraction over a language. As I said it's a sign that new features are needed as an extension. In terms of type safety for SQL I find certain ides already cover most of this so even a typescript style extension on top of SQL is not needed.
SQL doesn't help you here. SQL is just a query language that is designed around the relational model (more or less). The same relational model that your application isn't (likely) designed around. Thus, again, you need object relation mapping to provide the conversion between SQL's model and your application's model.
Some ORM toolkits also bundle query builders. The query builder may be what you find unnecessary, but I'm not sure the existence of query builders is crazy. These query builders essentially become another programming language that compiles to SQL. The idea of a programming language compiling to another programming language isn't crazy at all. We do it all the time with great success.
Although there is debate as to whether or not it is due to SQL/RDBMSes not being purely relational or if it is more fundamental, what is agreed upon is that there is an object relation impedance mismatch. This makes it a hard problem to solve and many ORM toolkits only provide half solutions, and this is where a lot of friction comes into play.
I am saying this transformation step is pointless. It's a leftover philosophy from a time when everyone thought object oriented programming was the only way to go.
You don't need the object abstraction. SQL is already a high level abstraction. Tables and foreign keys already cover everything you need including the relations.
You are converting tables to objects. One high level abstraction to another. It's like translating English to Chinese to explain something to someone who is already bilingual.
Here's another way to put it:
The models already exist in the database. Why build a repetitive model in the application language? It's a cosmetic thing because people don't want to deal with string manipulation. Overall most of your logic and abstractions lives in the strings you pass to the database. There should be minimal structure and logic for database queries outside of strings in the application code.
I'm not sure object oriented programming ever really caught on. The only object oriented languages that ever gained any claim to fame are Smalltalk, Objective-C, and Ruby. And none of them really gained what I would consider mass appeal, let alone thinking that they were the "only way to go".
> SQL is already a high level abstraction.
SQL is a high level query abstraction, but we're talking about the data model. Again, a relation is nothing more than a set of tuples[1]. That is a very primitive data abstraction.
Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures?
> The models already exist in the database. Why build a repetitive model in the application language?
Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code.
> It's a cosmetic thing because people don't want to deal with string manipulation.
String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory.
[1] If we are being pedantic, SQL actually deviates from the relational model by not staying completely true to sets. But the terminology has stuck regardless.
What about Java, C#, and Python? The first two have been go-to at many businesses since the turn of the century. If C++ isn’t mainstream it’s because in no small part people picked those instead.
Not sure why you think C# and Python are object oriented? They have what could be considered objects, but where does the orienting come into play?
The majority of the human race thinks of java as oop and is referring to such languages when communicating. Please do the same.
If you’re on some weird purity bent where you insist mainstream usage is wrong, well, I can’t stop you but I’ve never seen that result in something insightful or educational.
C# didn't yield the same results. As you suggest, it even changed its name away from containing 'Object Oriented' during the project scope evolution to not confuse people about what it is. I can't find any primitives that would even allow you to write object oriented-style code.
That said, I won't completely dismiss C# as being object oriented as it is the language I have the least familiarity with and very well could have overlooked the obvious. As before, I ask where the orienting comes into play. What language features at least come close the oriented paradigm?
[1] And, indeed, many do call Go a functional programming language. They're not strictly wrong, but it can make communication hard when you're loose like that. In these sorts of discussions you do have to be a little more precise, otherwise you'll end up talking past each other.
Uh they have. They were the dominant paradigm for a long time. You haven't been around long enough. I'm going to be real with you, a lot of what you say shows that you're relatively new.
>Using Javascript notation, consider the relation: [["John",32], ["Jane",23]]. Now consider a function that takes that input and outputs: [{name:"John", age:32}, {name:"Jane", age: 23}]. That's ORM. That's all ORM is. You see no value in those higher level structures?
Doesn't seem like a relation. Seems like your referring to a single table with no relationship to other tables specified.
You took a tuple and converted it to a named tuple. In SQL named tuples or named sets is the exclusive syntax... all columns are defined by name and type, all columns are queried by name. Indexed ids must be explicitly defined and in SQL they are not the default.
>Primarily because your data store is an implementation detail of your repository layer that shouldn't leak into the rest of the application. Even if your application's domain model can be ideally represented as relations, you still will want a conversion step to not bind that data model to the database's model. Schema changes to the database shouldn't break the users of your code.
This is incorrect. First off with an orm you are implementing your datastore in two places. You define the model in SQL and redefine it in application code. There is no separation here. The orm is by definition a leak. It destroys the concept of a single source of truth.
Second. A change in schema in SQL necessitates a change in model in application code. It cannot be separate by definition. Otherwise your model in code doesn't match what exists in reality.
>String manipulation? Are you encoding your application's state into something like JSON at every turn, or where do strings come into play? Don't do that. Even if you do need to share your application's state (e.g. to share over the network) in a stringly fashion, use another conversion pass to convert your internal representation to the sharable format. Your central domain model should be optimized for the machine's local memory.
Where on earth does Json come from? No man. String manipulation is what an orm does for you. SQL databases can only operate on strings. If you don't have an orm then you are doing the string manipulation yourself because strings of SQL are literally the only interface these databases can accept.
I don't think you fully understand the mechanism at work here. Your orm is sending strings to your SQL database over a network. That is what an orm is.
I've only been programming for about 30 years, so yes still quite young, but during that time the C++/Java style object model has been king, and while it is based on objects, they are definitely not oriented. For orientation you need, at very least, message passing.
When was oriented programming popular and not just a cool novelty that rises up from time to time?
> Doesn't seem like a relation. Seems like you're referring to a single table with no relationship to other tables specified.
A table is represented by a relation[1], yes. A relation isn't a join. A relation is a set of tuples, by literal definition.
Does your confusion here stem from not being familiar with the relational model?
> String manipulation is what an orm does for you.
What string manipulation is required in the ORM phase? You must be thinking of query building, but that's a completely different level of abstraction. Many ORM toolkits also bundle query builders, but you could create an ORM toolkit that expects one to write SQL by hand. They are not intrinsically linked. In fact, most ORM toolkits, even those which come with query builders, do allow you to write SQL by hand if you prefer.
[1] Ignoring the peculiarities of SQL which deviate from the mathematically pure model.
This is what a relation is: https://www.techopedia.com/definition/21677/relation in the context of relational databases.
I think you're confused.
>What string manipulation is required in the ORM phase?
You're just on some strange pedantic purity bent as the other person commented. Even the op refers to his "query builder" as an "orm". Most ORMs intrinsically tie "query building" and the orm together without even referencing the term query builder.
Despite all this it's fairly obvious you know what we mean and what we are trying to say. You're just playing a part here.
"Relation is sometimes used to refer to a table in a relational database" – True, but a relation is any set of tuples. Joining multiple tables together also produces a relation. It's not just tables. It's the more abstract concept of rows and columns, basically.
But, as noted earlier, SQL actually deviates from the relational model here. It doesn't actually operate on sets. This is where you find a lot of the gotchas it is famous for. Something like QUEL, which Postgres used instead of SQL for the first 10 years of its life, is closer to Codd's original model. It actually has relations.
I expect that deviation is why we're having trouble communicating here. As SQL isn't actually relational, calling them relations is technically a misnomer. While I appreciate the purity bent you say you're off on, I have indicated multiple times that I use relation with acknowledgement of SQL's deviation from the term in its purest sense. Yes, again, SQL relations aren't truly relations, but for the sake of ORM they serve the same purpose.
> Most ORMs intrinsically tie "query building" and the orm together without even referencing the term query builder.
Such as? All of the ORMs with query builders I'm familiar with are like "You an use our query DSL and you can even write raw SQL!". They present a clear separation between the ORM and the query building phases. If they were tightly coupled in those toolkits, they wouldn't be able to enable you to use raw SQL queries.
No the deviation is deliberately manufactured here. The oop pedantism is obvious. Smalltalk was the first but the word as evolved, everyone knows that. Including you but you pretend not to know this.
>While I appreciate the purity bent you say you're off on,
I never said this It was said by me and another poster that YOU are the one off on this bent of being overly pedantic about terms.
I think you're just trolling now. This kind of thing is against the rules here fyi.
Formal definition matters only if you haven't reached a shared understanding. Before definitions entered the discussion we started at that end, but all the information necessary to understand what relation means in SQL-speak, particularly with respect to ORM, has been given. There is no value in hanging off any other definition and doing so is merely a straw man.
Whatever you want to call it, the abstraction that converts between the database's data model and the application's data model is not the same abstraction that builds queries. They are very much distinct operations and ORM is only concerned with one of them (hint: Not the one that builds queries).
You don't love to learn new things, that is not your objective here, your objective is to troll. This conversation is over.
Now, it's okay if OOP means something different to you. Words are just tools to help with communication, not some source of pride or identity. That is why definitions were laid out to ensure that we weren't just talking past each other. Despite this making you believe I am young, in my 30 years of development experience I've learned that you can't assume everyone uses the same definition. In software, it is actually quite rare to find any common definition across any sizeable group of developers.
There is no logical reason to leave a discussion because what OOP meant to me differs from what OOP meant to you. The OOP talk that was present early in this thread didn't even carry into the remainder of the conversation about ORM, so it is moot anyway. The reality is that this conversation has reached a dead end because there is nothing left to talk about. We've established that ORM and query building are different operations, which rounds out the entire topic of the thread, and that's that.
there is reason to do so if you're trolling.
That's largely the opposite of the purpose of an ORM, which is to isolate “SQL logic” and present OOP logic.