5 ms·

I'm not sure if ORMs are an anti-pattern

43 points by dustingetz 15y ago

dustingetz 15y ago
after blogging this, i found a few example ORM systems which may be interesting to study. I still don't know the answers, but O/R Broker[2] seems the tightest one and it isn't even really an ORM[3]. [1] http://stackoverflow.com/questions/1362748/wanted-good-examples-of-scala-database-persistence http://stackoverflow.com/questions/1362748/wanted-good-examp... [2] http://code.google.com/p/orbroker/ http://code.google.com/p/orbroker/ [3] http://code.google.com/p/orbroker/wiki/JoinExample http://code.google.com/p/orbroker/wiki/JoinExample
- drKarl 15y ago
  I've used Anorm and its very flexible.
- garysieling 15y ago
  It might be instructive to compare an ORM style API for OLTP style databases vs. OLAP star schemas (http://en.wikipedia.org/wiki/Star_schema http://en.wikipedia.org/wiki/Star_schema). At least, the question of what a conditions API does / mutates in a query may be a very different answer between the two.
roopeshv 15y ago
+1 for not just writing to ride on the debate for page views and pointing out the areas of possible discussion.
perfunctory 15y ago
what is conditions api?
- perfunctory 15y ago
  why downvote? That's an honest question.
jrockway 15y ago
How does using an object database exclude transactions? Transactions make as much sense for rows in a database as they do for objects in a database or even objects in memory. Atomic object graph mutations are an essential feature of any concurrent system. It just won't work any other way. The reason to use an ORM instead of an object database is twofold. One, it's safer to use a working database and put some libraries on top of it than it is to write your own database. Do you want to write unit tests for the deadlock detection algorithm? Two, sometimes you're writing an online transaction processing application (99% of web applications) with fixed domain objects, but you want the flexibility to slice-and-dice the data in the future. In that case, an ORM makes your relational database look like an object store to the application (which is exactly what it wants), but it also lets you play with the data in Excel if you want to. The key is not that the data is relational, but that it's in a standard format that other software understands. Ultimately, there are three kinds of applications that you can write. One is what most software is; the user interacts with the application and generates state along the way and you want to record that state and act upon it. In that case, an object database is perfect; the state is meaningless without the application, so there's no reason to encode the state so as to be meaningful to other applications. The next case is something like this but where the data might be useful outside the application (auditing, reporting, other features). In that case, ORM is exactly what you need. Your application wants objects, but the other things that need the data want it in a database. So you compromise and store it in a database, using an ORM to make the relational database look like an object store to your application. The third case is an application that is not particularly interactive (think credit-card processing network), and you don't need any app-specific state to be preserved. In that case, raw database access is perfect; if all you are doing is INSERT INTO transactions VALUES ('jrockway', 'amazon.com', '19.95'), the ORM is just going to waste your time.
- pointyhat 15y ago
  They exclude transactions because an ORM maintains a stateful copy of the data on another tier. Once a copy is made of the data, the guarantee that a transaction can succeed or the data remains correct is no longer valid. Considering Fowler spent years pushing ORM's, isn't it a little ironic that his first law, directly from PoEAA is [1] "Don't distribute your objects" yet an ORM encourages distribution via the Unit of Work pattern and local stateful copies. Technically, the only thing that is possible to work for a Object-oriented database is a shared heap, which comes with its own bag of concurrency problems. Relational databases however, have first class concepts within mathematics such as sets and all operations take place in one place against one true source always so transactions can be guaranteed. ORM's are a recent invention and for some of the really big stuff out there, they just don't cut it. I'll post some example cases where transactions and OO falls over if anyone is interested. I've watched enough concurrency and transaction isolation issues raised from ORMs to be intimately aware of them now. [1] http://martinfowler.com/bliki/FirstLaw.html http://martinfowler.com/bliki/FirstLaw.html
jwatte 15y ago
Most of the time: Yes, traditional ORMs are an anti-pattern. If you think you want an ORM, consider an ODB or KVS instead (neither of which are relational).
baddox 15y ago
The assertion is that ORMs are an anti-pattern because it's hopeless to represent data from a relational db as object in an OO language. Obviously, an object or document database maps better to OO languages. My question is, what programming style maps correctly to relational data, other than the obvious answer of SQL?
- pointyhat 15y ago
  Functional programming maps perfectly. Consider first class sets in a language.
MartinCron 15y ago
I don't really need the external validation anymore. If people do or don't like some of the tools and techniques that I find useful, it doesn't matter. Their tastes and tolerances and scenarios are often different.

43 points by dustingetz 15y ago

after blogging this, i found a few example ORM systems which may be interesting to study. I still don't know the answers, but O/R Broker[2] seems the tightest one and it isn't even really an ORM[3]. [1] http://stackoverflow.com/questions/1362748/wanted-good-examples-of-scala-database-persistence http://stackoverflow.com/questions/1362748/wanted-good-examp... [2] http://code.google.com/p/orbroker/ http://code.google.com/p/orbroker/ [3] http://code.google.com/p/orbroker/wiki/JoinExample http://code.google.com/p/orbroker/wiki/JoinExample

drKarl 15y ago
I've used Anorm and its very flexible.
garysieling 15y ago
It might be instructive to compare an ORM style API for OLTP style databases vs. OLAP star schemas (http://en.wikipedia.org/wiki/Star_schema http://en.wikipedia.org/wiki/Star_schema). At least, the question of what a conditions API does / mutates in a query may be a very different answer between the two.

roopeshv 15y ago

+1 for not just writing to ride on the debate for page views and pointing out the areas of possible discussion.

perfunctory 15y ago

what is conditions api?

perfunctory 15y ago
why downvote? That's an honest question.

jrockway 15y ago

How does using an object database exclude transactions? Transactions make as much sense for rows in a database as they do for objects in a database or even objects in memory. Atomic object graph mutations are an essential feature of any concurrent system. It just won't work any other way. The reason to use an ORM instead of an object database is twofold. One, it's safer to use a working database and put some libraries on top of it than it is to write your own database. Do you want to write unit tests for the deadlock detection algorithm? Two, sometimes you're writing an online transaction processing application (99% of web applications) with fixed domain objects, but you want the flexibility to slice-and-dice the data in the future. In that case, an ORM makes your relational database look like an object store to the application (which is exactly what it wants), but it also lets you play with the data in Excel if you want to. The key is not that the data is relational, but that it's in a standard format that other software understands. Ultimately, there are three kinds of applications that you can write. One is what most software is; the user interacts with the application and generates state along the way and you want to record that state and act upon it. In that case, an object database is perfect; the state is meaningless without the application, so there's no reason to encode the state so as to be meaningful to other applications. The next case is something like this but where the data might be useful outside the application (auditing, reporting, other features). In that case, ORM is exactly what you need. Your application wants objects, but the other things that need the data want it in a database. So you compromise and store it in a database, using an ORM to make the relational database look like an object store to your application. The third case is an application that is not particularly interactive (think credit-card processing network), and you don't need any app-specific state to be preserved. In that case, raw database access is perfect; if all you are doing is INSERT INTO transactions VALUES ('jrockway', 'amazon.com', '19.95'), the ORM is just going to waste your time.

pointyhat 15y ago
They exclude transactions because an ORM maintains a stateful copy of the data on another tier. Once a copy is made of the data, the guarantee that a transaction can succeed or the data remains correct is no longer valid. Considering Fowler spent years pushing ORM's, isn't it a little ironic that his first law, directly from PoEAA is [1] "Don't distribute your objects" yet an ORM encourages distribution via the Unit of Work pattern and local stateful copies. Technically, the only thing that is possible to work for a Object-oriented database is a shared heap, which comes with its own bag of concurrency problems. Relational databases however, have first class concepts within mathematics such as sets and all operations take place in one place against one true source always so transactions can be guaranteed. ORM's are a recent invention and for some of the really big stuff out there, they just don't cut it. I'll post some example cases where transactions and OO falls over if anyone is interested. I've watched enough concurrency and transaction isolation issues raised from ORMs to be intimately aware of them now. [1] http://martinfowler.com/bliki/FirstLaw.html http://martinfowler.com/bliki/FirstLaw.html

jwatte 15y ago

Most of the time: Yes, traditional ORMs are an anti-pattern. If you think you want an ORM, consider an ODB or KVS instead (neither of which are relational).

baddox 15y ago

The assertion is that ORMs are an anti-pattern because it's hopeless to represent data from a relational db as object in an OO language. Obviously, an object or document database maps better to OO languages. My question is, what programming style maps correctly to relational data, other than the obvious answer of SQL?

pointyhat 15y ago
Functional programming maps perfectly. Consider first class sets in a language.

MartinCron 15y ago

I don't really need the external validation anymore. If people do or don't like some of the tools and techniques that I find useful, it doesn't matter. Their tastes and tolerances and scenarios are often different.