7 ms·

OrmHate (2012)

62 points by wilsonfiifi 8y ago

alexandercrohde 8y ago
I don't get it. Firstly, is this being cited in sincerity, or to point out "Look, even Martin Fowler advocated for NoSQL back in 2012"? If it is entirely in sincerity, I don't understand why he thinks queries isn't the de-facto solution. Perhaps his implicit assumption is that the database should be structured to reflect the code, when really the code should be structured to reflect the database?
martin1975 8y ago
No reason to hate ORM unless you're letting the ORM tool generate your schema, in which case, you might get really lucky... or you might find out the hard way that there's a fine distinction between DBAs and software engineers.
- WJW 8y ago
  ORMs make 95% of queries/tasks simpler, but when you encounter the other 5% the lack of "practice" regarding how the database works under the hood will bite you in the ass. Somehow I became the "database guy" of my workplace (small startup without a dedicated DBA) and everybody thinks I really dislike our ORM because all they hear me say about it is pretty negative. However, that is because nobody comes to me with the 95% of easy questions so every question I get is one of the 5% edge cases where the ORM is really not a good fit :|
- organsnyder 8y ago
  That's been my experience. My team (webservices at a large enterprise) has come to rely on ORM as a crutch—the rule is, if we use an ORM, we don't need to run our schemas past a DBA. This probably came out of necessity (most of the DBAs at my org tend to be more sysadmins responsible for installing Oracle, rather than real DBAs), but the results—bloated schemas that are difficult to query efficiently, various tricky performance gotchas, etc.—should not have been surprising.
scarface74 8y ago
The problem I have with every ORM I've used is it feels tacked on. The only framework that I know that treats queries like a first class citizen is .Net. The beauty of Linq -> Expression Trees -> data store can't be overestated. The fact that you can use the same Linq expressions in your code and they can be translated to in memory Lists, Sql, or even MongoQuery at runtime is beautiful.
- pathartl 8y ago
  Agreed. I used to be on the .NET hate bandwagon because I didn't understand it and conforming to MS was more of a business-suit idea for me. However, EF + LINQ + expression trees are amazing.
vinceguidry 8y ago
I don't know that a better ORM than ActiveRecord is imaginable. It's seriously good, and getting better every year. I don't think a better DSL for database wrangling exists, and dropping down to SQL or the intermediate representation (arel) couldn't be easier, you can take any ActiveRelation object and call .to_sql on it to see what it's doing. I've used DataMapper and Sequel, and read through the ROM docs, I don't think any of them really bring something better to the table than good, old, solid Active Record. Linq is expressive and fun, compared to .NET. Nothing compared to Ruby. As abstraction layers go, I can't ask for a better one.
- Ygg2 8y ago
  > I don't know that a better ORM than ActiveRecord is imaginable. SQL Alchemy https://www.sqlalchemy.org/ https://www.sqlalchemy.org/
  - vinceguidry 8y ago
    That's a fair suggestion, as I don't use Python. My feeling is that it would be the same as Linq, really amazing compared to the other Python alternatives, but ultimately hampered by Python when you're trying to compare it across languages / stacks. My distaste for Python runs somewhat deep, I certainly wouldn't involve myself on any web project that uses it. Maybe for games.
    - blattimwind 8y ago
      sqlalchemy is hands-down the best ORM I've ever seen. It only gives you exactly as much magic as you want (imho an annoying problem with anything related to Django) and instead of generating SQL more or less directly it operates on an SQL DSL, which can be extended at just the right points to use pretty much any DB feature, including those sqlalchemy does not know or understand. I don't know Linq personally but I know people liking it very much -- your comparison is probably accurate.
- TimTheTinker 8y ago
  .NET’s entity framework (combined with Linq in C#) is pretty amazing — if it’s not better than ActiveRecord, it’s at least a strong contender.
corpMaverick 8y ago
It is futile to try to hide the relational model. Now days, I think it needs to be embraced.
- mistrial9 8y ago
  'futile' is a false wall.. maybe common rational talk has been polarized by entrenched interests in a technology .. BUT single column and/or schema-less has shown its raw power, without a doubt
0x445442 8y ago
Yeah, to me SQL Mappers like MyBatis are usually the way to go. I don't want the power of SQL abstracted away from me in most cases. If I had a nickel for every time I've seen code using an ORM framework fetching a set of ids and then iterating over that set to fetch a single record at a time. And then if I had another nickle for each blank stare I got when I explained that only one SQL query was needed to return the flattened result set of data and that the hierarchical object graph could be built in the app much faster than the N SQL queries they were making.
- xamuel 8y ago
  >fetching a set of ids and then iterating The ironic part? The folks who do that tend to be the same folks who swear the ORM will pay for itself by query-optimizing under-the-hood. 9_9
- geophile 8y ago
  Many years ago, I wrote a Java ORM that solved that exact problem. But I still have come around 180 degrees to the view that ORMs are terrible. Even aside from this N+1 problem, to use an ORM well, you have to understand the SQL that you want to be generated, and then instead of writing that SQL, you have the additional problem of having to know exactly what to say to the ORM to get that SQL generated. Also: you don't always want objects returned; sometimes partially instantiated objects are what you want; bulk updates are hard to get right; stored procedures break everything; and on and on. The thing that really started me on the path to my current view was a conversation with an app developer who was evaluating our project. Just from a career point of view, having Oracle on her resume was a lot more valuable than having OurProprietaryORM on her resume. That, combined with the realization that solving the N+1 problem was really a pretty minor thing, and that all the other problems were even harder to solve. The approach I have been using for a while is to use a very simple mapping layer that hides some of the ugliness of JDBC, but still lets me write SQL directly. I understand that MyBatis does something like this, although I haven't used it.
- twic 8y ago
  I really feel like i'm owed a considerable number of nickels for all the times i've seen posts and comments about ORMs which miss the fact that they have powerful query languages built in. JPQL is a genuinely pretty nice way of querying a database - it's basically SQL, plus object property syntax [1]. Here's a little example which concisely examines a many-to-many relationship: SELECT DISTINCT p FROM Player p WHERE p.teams IS NOT EMPTY Or navigation through a path (i made this example up, might not be quite right): SELECT t.name, t.league.sport FROM Team t WHERE t.city = 'Ul Qoma' If you're doing reporting where it doesn't make sense to pull out the entities, you can use a constructor expression [2] to materialise results as anything else you like (again, made up, might not be spot on): // package hn; public class CountSummary { public CountSummary(String name, int count) {} } SELECT NEW hn.CountSummary(l.name, COUNT(l.teams)) FROM League l Certainly, there are more sophisticated features of SQL that are useful for analytical queries that aren't in this query language. That's why every ORM has an escape hatch where you can write raw SQL, but still use its machinery for turning results into objects. [1] https://docs.oracle.com/javaee/6/tutorial/doc/bnbtl.html https://docs.oracle.com/javaee/6/tutorial/doc/bnbtl.html [2] https://docs.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnbwc https://docs.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnb...
jdonaldson 8y ago
I started my career out writing database applications. Every aspect of those applications were schema-driven, and I would generally would try and solve problems at a schema level (e.g. for rendering/presentation, etc.) In application development, it's gotten very popular to ignore the data storage component of application design, or at least defer it to the last possible moment. React et al take things even further by requiring their own modeling logic. As many here would agree, relational dbs never went away. But for some reason folks stopped trying to push the envelope with schema-driven application development. I kept expecting to see iterations of schema-driven design and layout system (using inputs derived from table fields, etc). What we got instead is this ORM business. Is there a schema-first tooling community that I'm unaware of?
- haolez 8y ago
  I'm not sure if this fits your bill, but you can go pretty far into application logic by combining PostgreSQL and PostgREST (https://postgrest.com/ https://postgrest.com/).
  - jdonaldson 8y ago
    I think that's a great example!
QueensGambit 8y ago
This article focuses on ease of use i.e. avoiding the nastiness of RDBMS entities as in-memory data structure. But the main reason most of us used ORM is because of its portability between different databases. In the on-premise deployment era, each customer was a Oracle/MSSQL/MySQL shop and ORMs magically solved this problem by letting us write once and run on any database. Today, this portability problem still exists between different cloud vendors' NoSQL databases, even if it solves the mapping problem.
- pgaddict 8y ago
  The downside of using ORM this way is that it doesn't really solve the interesting cases, or more subtle differences in behaviour. By "interesting cases" I mean applications that leverage the more unique features in different database systems (like the full-text search implementations, that tend to be very database specific). By subtle differences I mean e.g. specific issues like Oracle handling NULL vs. empty string unlike other databases, or more serious differences related e.g. to locking (so an application that works fine on one database fails spectacularly on another one). Obviously, if you treat the advanced database system as a dumb data store, this may work. But it kinda tends to reduce any database to the worst non-existent database, missing any of the nice features. Because all the advanced stuff is "forbidden" for portability reasons. I've seen so many cases of performance issues where the right solutions were rejected because it would impact portabiliy ...
  - QueensGambit 8y ago
    >> By "interesting cases" I mean applications that leverage the more unique features in different database systems Actually, most ORMs like Hibernate allow you to write native SQL (or even stored procedure) to take advantage of native db features. In that case, you have to trade-off portability, if that feature is important to you. >> or more serious differences related e.g. to locking (so an application that works fine on one database fails spectacularly on another one) Locking (default - READ_COMMITTED) also works consistently across databases. The problem happens only when you introduce distributed ORM cache where data is not updated synchronously across the cluster. It is a reasonable trade-off for performance.
commandlinefan 8y ago
> deal with the object/relational mapping problem by writing their own framework Now, instead, everybody deals with the object/ORM mapping problem by writing their own framework.
sjclemmy 8y ago
Good article. I’m currently using Entity Framework in .net and I’ve designed the latest bit of software I’m developing by using the balanced approach advocated here; the modelling and the RDBMS are both part of the system and have their own constraints one has to bear in mind. After working with EF there’s only one thing I couldn’t express that I can do in SQL and that’s have multiple parent keys in the parent table to represent relationships with multiple children. It took me a while to work out and I believe it is possible in .net core.
projectileboy 8y ago
My problem with ORMs is that they feel like overkill for small apps, and they merely get in your way with large apps. And I have yet to be on a project with Hibernate where they were using the caching and really understood what they were doing.
- edejong 8y ago
  Well, I once worked on a 1 MLOC (as far as that’s relevant) high school SaaS administration system providing services for a large chunk of the Dutch market. Hibernate, EHcache and cache synchronization across applications (with an Electronic Learning Environment) all worked well. The team of 12 developers with a small minority had expert knowledge in Hibernate and cache management. The biggest problem I often see in large DB systems is the lack of proper normalization, leading to very wide tables and subsequently causing performance problems (both due to reduced scanning speed and ORMs tendency to just pull in all attributes of selected rows). Another problem with Hibernate is the proper demarcation of transactional boundaries, causing DB inconsistencies. Very important to get right. I could go on, but then this would become a blog post. In any case, I feel that a functional mapping over the SQL AST and result sets using Scala and Slick (for example) leads to much higher versatility, places computation closer to storage and provides better abstraction possibilities. This, in turn, reduces the complexity of the middle layer.
  - wwweston 8y ago
    > a small minority had expert knowledge in Hibernate and cache management. How does Hibernate as a project (or the community around it) develop people who have expert knowledge in it and/or general cache management?
    - edejong 8y ago
      It doesn’t! Most was self taught by reading sources and some O’Reilly books. Community support was rather marginal at the time when true technicalities were discussed. Same as Stack Overflow now: loads of people with superficial knowledge, but very few with in-depth or architectural technical prowess. Unfortunately, those ppl are often too occupied to scan the SO posts and a simple answer skimming the true ideas often wins the accepted answer instead.
mildavw 8y ago
Love this. What I've seen lately, as a contractor at several different companies, is inexperienced devs getting a very long way building apps without knowing what's going on with their database under the hood. That's a testament to the value of ORMS. It's common, then, that the low hanging fruit for a contractor coming in to improve performance is to optimize queries and/or introduce triggers, views, and stored procedures. I've found that devs are scared of plain old SQL but the ones who know their ORM well can learn SQL easily with a little nudge and some guidance.
ken 8y ago
> In the 90's many of us (yes including me) thought that object databases would solve the problem by eliminating relations on the disk. We all know how that worked out. What am I supposed to know about this? I've only used an object database for one serious (>100KLOC) project, but it was by far the best part of that system. I always wondered why that architecture never caught on. The only reason I'm not using an ODBMS on my own projects today is that there's no good open-source one, but that seems like something a company could do something about, and a lousy reason to condemn an entire architecture.
- anonetal 8y ago
  OrientDB is a good open-source database that exposes a primarily object data model (the document and graph abstractions are built on top of it). Lack of a good query language and scalability issues doomed those. Mike Stonebraker (https://blog.grakn.ai/what-goes-around-comes-around-52d38ee1ea9e https://blog.grakn.ai/what-goes-around-comes-around-52d38ee1...) had a nice summary in that article.
  - ken 8y ago
    There are 4 reasons proposed for the failure of OODBs, in that paper, but scalability is not among them. Interestingly, the issues are largely C++-specific (and I know lots of people using an ORM today but none via C++), and largely driven by historical accident and market forces ("It is interesting to conjecture about the marketplace chances of O2 if they had started initially in the USA with sophisticated US venture capital backing"). I still don't think these sound like good reasons to dismiss the architecture.
  - lvca 8y ago
    I agree that a pure ODBMS makes no much sense today, but OrientDB is a Multi-Model where the Object Model is one of the supported models. You can mix objects, graphs, schema-less documents and much more + using SQL as the query language. Boom! (Disclaimer: I am the founder of OrientDB)
shujutech 8y ago
I'm moving my ORM into a real database, anyone interested to join me? Need anyone with major in DBMS, able to write SQL parser and database storage/organization. We'll be selling data model instead of database when completed. Check us out at: http://shujutech.mywire.org/corporation?goto=ormj http://shujutech.mywire.org/corporation?goto=ormj

OrmHate (2012)

62 points by wilsonfiifi 8y ago

I don't get it. Firstly, is this being cited in sincerity, or to point out "Look, even Martin Fowler advocated for NoSQL back in 2012"? If it is entirely in sincerity, I don't understand why he thinks queries isn't the de-facto solution. Perhaps his implicit assumption is that the database should be structured to reflect the code, when really the code should be structured to reflect the database?

martin1975 8y ago

No reason to hate ORM unless you're letting the ORM tool generate your schema, in which case, you might get really lucky... or you might find out the hard way that there's a fine distinction between DBAs and software engineers.

WJW 8y ago
ORMs make 95% of queries/tasks simpler, but when you encounter the other 5% the lack of "practice" regarding how the database works under the hood will bite you in the ass. Somehow I became the "database guy" of my workplace (small startup without a dedicated DBA) and everybody thinks I really dislike our ORM because all they hear me say about it is pretty negative. However, that is because nobody comes to me with the 95% of easy questions so every question I get is one of the 5% edge cases where the ORM is really not a good fit :|
organsnyder 8y ago
That's been my experience. My team (webservices at a large enterprise) has come to rely on ORM as a crutch—the rule is, if we use an ORM, we don't need to run our schemas past a DBA. This probably came out of necessity (most of the DBAs at my org tend to be more sysadmins responsible for installing Oracle, rather than real DBAs), but the results—bloated schemas that are difficult to query efficiently, various tricky performance gotchas, etc.—should not have been surprising.

scarface74 8y ago

The problem I have with every ORM I've used is it feels tacked on. The only framework that I know that treats queries like a first class citizen is .Net. The beauty of Linq -> Expression Trees -> data store can't be overestated. The fact that you can use the same Linq expressions in your code and they can be translated to in memory Lists, Sql, or even MongoQuery at runtime is beautiful.

pathartl 8y ago
Agreed. I used to be on the .NET hate bandwagon because I didn't understand it and conforming to MS was more of a business-suit idea for me. However, EF + LINQ + expression trees are amazing.

vinceguidry 8y ago

I don't know that a better ORM than ActiveRecord is imaginable. It's seriously good, and getting better every year. I don't think a better DSL for database wrangling exists, and dropping down to SQL or the intermediate representation (arel) couldn't be easier, you can take any ActiveRelation object and call .to_sql on it to see what it's doing. I've used DataMapper and Sequel, and read through the ROM docs, I don't think any of them really bring something better to the table than good, old, solid Active Record. Linq is expressive and fun, compared to .NET. Nothing compared to Ruby. As abstraction layers go, I can't ask for a better one.

Ygg2 8y ago
> I don't know that a better ORM than ActiveRecord is imaginable. SQL Alchemy https://www.sqlalchemy.org/ https://www.sqlalchemy.org/
- vinceguidry 8y ago
  That's a fair suggestion, as I don't use Python. My feeling is that it would be the same as Linq, really amazing compared to the other Python alternatives, but ultimately hampered by Python when you're trying to compare it across languages / stacks. My distaste for Python runs somewhat deep, I certainly wouldn't involve myself on any web project that uses it. Maybe for games.
  - blattimwind 8y ago
    sqlalchemy is hands-down the best ORM I've ever seen. It only gives you exactly as much magic as you want (imho an annoying problem with anything related to Django) and instead of generating SQL more or less directly it operates on an SQL DSL, which can be extended at just the right points to use pretty much any DB feature, including those sqlalchemy does not know or understand. I don't know Linq personally but I know people liking it very much -- your comparison is probably accurate.
TimTheTinker 8y ago
.NET’s entity framework (combined with Linq in C#) is pretty amazing — if it’s not better than ActiveRecord, it’s at least a strong contender.

corpMaverick 8y ago

It is futile to try to hide the relational model. Now days, I think it needs to be embraced.

mistrial9 8y ago
'futile' is a false wall.. maybe common rational talk has been polarized by entrenched interests in a technology .. BUT single column and/or schema-less has shown its raw power, without a doubt

0x445442 8y ago

Yeah, to me SQL Mappers like MyBatis are usually the way to go. I don't want the power of SQL abstracted away from me in most cases. If I had a nickel for every time I've seen code using an ORM framework fetching a set of ids and then iterating over that set to fetch a single record at a time. And then if I had another nickle for each blank stare I got when I explained that only one SQL query was needed to return the flattened result set of data and that the hierarchical object graph could be built in the app much faster than the N SQL queries they were making.

xamuel 8y ago
>fetching a set of ids and then iterating The ironic part? The folks who do that tend to be the same folks who swear the ORM will pay for itself by query-optimizing under-the-hood. 9_9
geophile 8y ago
Many years ago, I wrote a Java ORM that solved that exact problem. But I still have come around 180 degrees to the view that ORMs are terrible. Even aside from this N+1 problem, to use an ORM well, you have to understand the SQL that you want to be generated, and then instead of writing that SQL, you have the additional problem of having to know exactly what to say to the ORM to get that SQL generated. Also: you don't always want objects returned; sometimes partially instantiated objects are what you want; bulk updates are hard to get right; stored procedures break everything; and on and on. The thing that really started me on the path to my current view was a conversation with an app developer who was evaluating our project. Just from a career point of view, having Oracle on her resume was a lot more valuable than having OurProprietaryORM on her resume. That, combined with the realization that solving the N+1 problem was really a pretty minor thing, and that all the other problems were even harder to solve. The approach I have been using for a while is to use a very simple mapping layer that hides some of the ugliness of JDBC, but still lets me write SQL directly. I understand that MyBatis does something like this, although I haven't used it.
twic 8y ago
I really feel like i'm owed a considerable number of nickels for all the times i've seen posts and comments about ORMs which miss the fact that they have powerful query languages built in. JPQL is a genuinely pretty nice way of querying a database - it's basically SQL, plus object property syntax [1]. Here's a little example which concisely examines a many-to-many relationship: SELECT DISTINCT p FROM Player p WHERE p.teams IS NOT EMPTY Or navigation through a path (i made this example up, might not be quite right): SELECT t.name, t.league.sport FROM Team t WHERE t.city = 'Ul Qoma' If you're doing reporting where it doesn't make sense to pull out the entities, you can use a constructor expression [2] to materialise results as anything else you like (again, made up, might not be spot on): // package hn; public class CountSummary { public CountSummary(String name, int count) {} } SELECT NEW hn.CountSummary(l.name, COUNT(l.teams)) FROM League l Certainly, there are more sophisticated features of SQL that are useful for analytical queries that aren't in this query language. That's why every ORM has an escape hatch where you can write raw SQL, but still use its machinery for turning results into objects. [1] https://docs.oracle.com/javaee/6/tutorial/doc/bnbtl.html https://docs.oracle.com/javaee/6/tutorial/doc/bnbtl.html [2] https://docs.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnbwc https://docs.oracle.com/javaee/6/tutorial/doc/bnbuf.html#bnb...

jdonaldson 8y ago

I started my career out writing database applications. Every aspect of those applications were schema-driven, and I would generally would try and solve problems at a schema level (e.g. for rendering/presentation, etc.) In application development, it's gotten very popular to ignore the data storage component of application design, or at least defer it to the last possible moment. React et al take things even further by requiring their own modeling logic. As many here would agree, relational dbs never went away. But for some reason folks stopped trying to push the envelope with schema-driven application development. I kept expecting to see iterations of schema-driven design and layout system (using inputs derived from table fields, etc). What we got instead is this ORM business. Is there a schema-first tooling community that I'm unaware of?

haolez 8y ago
I'm not sure if this fits your bill, but you can go pretty far into application logic by combining PostgreSQL and PostgREST (https://postgrest.com/ https://postgrest.com/).
- jdonaldson 8y ago
  I think that's a great example!

QueensGambit 8y ago

This article focuses on ease of use i.e. avoiding the nastiness of RDBMS entities as in-memory data structure. But the main reason most of us used ORM is because of its portability between different databases. In the on-premise deployment era, each customer was a Oracle/MSSQL/MySQL shop and ORMs magically solved this problem by letting us write once and run on any database. Today, this portability problem still exists between different cloud vendors' NoSQL databases, even if it solves the mapping problem.

pgaddict 8y ago
The downside of using ORM this way is that it doesn't really solve the interesting cases, or more subtle differences in behaviour. By "interesting cases" I mean applications that leverage the more unique features in different database systems (like the full-text search implementations, that tend to be very database specific). By subtle differences I mean e.g. specific issues like Oracle handling NULL vs. empty string unlike other databases, or more serious differences related e.g. to locking (so an application that works fine on one database fails spectacularly on another one). Obviously, if you treat the advanced database system as a dumb data store, this may work. But it kinda tends to reduce any database to the worst non-existent database, missing any of the nice features. Because all the advanced stuff is "forbidden" for portability reasons. I've seen so many cases of performance issues where the right solutions were rejected because it would impact portabiliy ...
- QueensGambit 8y ago
  >> By "interesting cases" I mean applications that leverage the more unique features in different database systems Actually, most ORMs like Hibernate allow you to write native SQL (or even stored procedure) to take advantage of native db features. In that case, you have to trade-off portability, if that feature is important to you. >> or more serious differences related e.g. to locking (so an application that works fine on one database fails spectacularly on another one) Locking (default - READ_COMMITTED) also works consistently across databases. The problem happens only when you introduce distributed ORM cache where data is not updated synchronously across the cluster. It is a reasonable trade-off for performance.

commandlinefan 8y ago

> deal with the object/relational mapping problem by writing their own framework Now, instead, everybody deals with the object/ORM mapping problem by writing their own framework.

sjclemmy 8y ago

Good article. I’m currently using Entity Framework in .net and I’ve designed the latest bit of software I’m developing by using the balanced approach advocated here; the modelling and the RDBMS are both part of the system and have their own constraints one has to bear in mind. After working with EF there’s only one thing I couldn’t express that I can do in SQL and that’s have multiple parent keys in the parent table to represent relationships with multiple children. It took me a while to work out and I believe it is possible in .net core.

projectileboy 8y ago

My problem with ORMs is that they feel like overkill for small apps, and they merely get in your way with large apps. And I have yet to be on a project with Hibernate where they were using the caching and really understood what they were doing.

edejong 8y ago
Well, I once worked on a 1 MLOC (as far as that’s relevant) high school SaaS administration system providing services for a large chunk of the Dutch market. Hibernate, EHcache and cache synchronization across applications (with an Electronic Learning Environment) all worked well. The team of 12 developers with a small minority had expert knowledge in Hibernate and cache management. The biggest problem I often see in large DB systems is the lack of proper normalization, leading to very wide tables and subsequently causing performance problems (both due to reduced scanning speed and ORMs tendency to just pull in all attributes of selected rows). Another problem with Hibernate is the proper demarcation of transactional boundaries, causing DB inconsistencies. Very important to get right. I could go on, but then this would become a blog post. In any case, I feel that a functional mapping over the SQL AST and result sets using Scala and Slick (for example) leads to much higher versatility, places computation closer to storage and provides better abstraction possibilities. This, in turn, reduces the complexity of the middle layer.
- wwweston 8y ago
  > a small minority had expert knowledge in Hibernate and cache management. How does Hibernate as a project (or the community around it) develop people who have expert knowledge in it and/or general cache management?
  - edejong 8y ago
    It doesn’t! Most was self taught by reading sources and some O’Reilly books. Community support was rather marginal at the time when true technicalities were discussed. Same as Stack Overflow now: loads of people with superficial knowledge, but very few with in-depth or architectural technical prowess. Unfortunately, those ppl are often too occupied to scan the SO posts and a simple answer skimming the true ideas often wins the accepted answer instead.

mildavw 8y ago

Love this. What I've seen lately, as a contractor at several different companies, is inexperienced devs getting a very long way building apps without knowing what's going on with their database under the hood. That's a testament to the value of ORMS. It's common, then, that the low hanging fruit for a contractor coming in to improve performance is to optimize queries and/or introduce triggers, views, and stored procedures. I've found that devs are scared of plain old SQL but the ones who know their ORM well can learn SQL easily with a little nudge and some guidance.

ken 8y ago

> In the 90's many of us (yes including me) thought that object databases would solve the problem by eliminating relations on the disk. We all know how that worked out. What am I supposed to know about this? I've only used an object database for one serious (>100KLOC) project, but it was by far the best part of that system. I always wondered why that architecture never caught on. The only reason I'm not using an ODBMS on my own projects today is that there's no good open-source one, but that seems like something a company could do something about, and a lousy reason to condemn an entire architecture.

anonetal 8y ago
OrientDB is a good open-source database that exposes a primarily object data model (the document and graph abstractions are built on top of it). Lack of a good query language and scalability issues doomed those. Mike Stonebraker (https://blog.grakn.ai/what-goes-around-comes-around-52d38ee1ea9e https://blog.grakn.ai/what-goes-around-comes-around-52d38ee1...) had a nice summary in that article.
- ken 8y ago
  There are 4 reasons proposed for the failure of OODBs, in that paper, but scalability is not among them. Interestingly, the issues are largely C++-specific (and I know lots of people using an ORM today but none via C++), and largely driven by historical accident and market forces ("It is interesting to conjecture about the marketplace chances of O2 if they had started initially in the USA with sophisticated US venture capital backing"). I still don't think these sound like good reasons to dismiss the architecture.
- lvca 8y ago
  I agree that a pure ODBMS makes no much sense today, but OrientDB is a Multi-Model where the Object Model is one of the supported models. You can mix objects, graphs, schema-less documents and much more + using SQL as the query language. Boom! (Disclaimer: I am the founder of OrientDB)

shujutech 8y ago

I'm moving my ORM into a real database, anyone interested to join me? Need anyone with major in DBMS, able to write SQL parser and database storage/organization. We'll be selling data model instead of database when completed. Check us out at: http://shujutech.mywire.org/corporation?goto=ormj http://shujutech.mywire.org/corporation?goto=ormj