9 ms·

How Hibernate Almost Ruined My Career

78 points by lightlyused 10y ago

leothekim 10y ago
Straw man script about what happens when you "blindly use Hibernate." I suppose there are lots of people in the world who do that. I would think that Hibernate isn't the sole problem in those cases.
- NeutronBoy 10y ago
  'How selecting a tool without understanding if it was the right tool to use was the wrong decision'
  - raverbashing 10y ago
    "this just works, nobody needs to know theorical stuff anymore"
xyzzy4 10y ago
SQL is an amazing and very useful tool to work with. I will never understand why people want to abstract it away.
- lostcolony 10y ago
  "SQL seems hard" "Here's a tool that makes it so you don't have to use SQL" "Great! Let's use that" - without having done the work to determine if that tool is actually any simpler (hint: it's not)
- bradmwalker 10y ago
  SQL needs marketing. Become obsolete unless you understand this durable persistence and functional, high-leverage reporting service!
- busterarm 10y ago
  I understand why they do, but I don't understand why more developers don't learn SQL. _it's freaking easy_!!! I become the defacto SQL guy at every job I work because other people don't want to touch it for some reason. I write SQL (or SOQL...ugh, Salesforce) virtually every day on the job (I do a ton of ETL in Ruby) and use it to give valuable business intelligence. Constantly I see other programmers jump through all sorts of technical hoops to get things done that could be done in a DB query quicker with more accuracy and less mental overhead. Just write your own toy ORM sometime. Copy the most-common functions of ActiveRecord. It's that easy. That's all it takes.
- nicolas_t 10y ago
  I use ORMs (ActiveRecord in Ruby, Sequelize in node.js) but I strongly believe that the only way to correctly use an ORM is to have a strong understanding of SQL. The ORM is useful in that it makes some things faster to write, makes my code cleaner but I will often revert back to SQL for critical operations that I need to be fast and I also know enough about how the ORM writes SQL to make sure that it doesn't do stupid queries. TLDR: ORMs are a good tool but must never be used to avoid learning SQL. An SQL knowledge is necessary to not shoot yourself in the foot.
- PretzelFisch 10y ago
  I think it's like javascript, when you had to use one language on the server then switch to something else on the client it lead to many years of trying to abstract html and javascript into java/c#... Maybe it would help if languages would allow for first class integration with sql like asp did for html
pstuart 10y ago
I supported a deals site that used Hibernate with JBoss. We went through several years of scaling pain until a consulting engineer found that the Hibernate cache settings were left at their defaults.
ThomaszKrueger 10y ago
"To get a report, we have to wait two days!" Who in their right mind would use Hibernate (or any other ORM for that matter) for reporting?
- koolba 10y ago
  I think JIRA uses it. I vaguely remember the query format for it being a form of JPQL.
  - busterarm 10y ago
    Funny that. The larger our (not particularly large) JIRA account gets, the slower it performs. Very noticeably so.
- karlkatzke 10y ago
  Java developers?
anthonybsd 10y ago
This doesn't look like it was a problem with Hibenrate, more of a "wrong tool for the job"-scenario. Reposting what I recently wrote on Reddit on a similar Hibernate discussion thread: In my experience, ORMs and specifically SpringData-JPA-Hibernate occupy this weird niche in the enterprise spectrum. They are an overkill for small projects and they become a hinderance for large projects, so they sort of sit there for medium projects. If you start with an ORM on a medium size project and it becomes a big project you can sometimes find yourself in an awkward spot where you are writing a lot of SQL (and not of the JPQL kind). With Hibernate/JPA specifically there are so many things that are broken that they just start getting in the way if your schemas become large enough. To me this is really just a manifestation of Behavioral Problem (Martin Fowler, Enterprise Patterns), where relational databases don't really map to objects at all when you get down to it. Basically, if you are going to do quite a bit of SQL, any ORM will just in the way. Should be plainly obvious to anyone with experience.
- sametmax 10y ago
  It depends a lot of the ORM. SQLAlchemy allows you to ditch the ORM when you need it. But instead of going back to raw sql, you just get a DSL like LINK, which is very flexible and can express most of the stuff you could do with manual SQL, while still retaining many benefits of using a wrapper. It's my understanding that Hibernate doesn't allow this. > Basically, if you are going to do quite a bit of SQL, any ORM will just in the way. Should be plainly obvious to anyone with experience. This is the problem you see : a lot of project don't have somebody very experienced with SQL anymore. Because they need to know a bit of sysadmin, and front en dev, and deployment, and CI, etc. So an ORM helps a lot in that regard, and will help most projects because the problems it causes are smaller that the ones it solves: - it forces people to put the schema, migrations and validation code in a centralized place. - it let you reuse your API knowledge instead of having to relearn the stuff for SQLite/Postgres/MySQL/Access. - it enforces good practices on security with data escaping and cleaning. - it let you benefit from your language tooling (analytics, linters, completions, doc, shells) to write queries that otherwise would be plain text in the middle of the file for most people. - it gives a structure to DB operations, so if you look for something, you know where and what to look for. - it gives you an event system to decouple queries and their effect. - it gives a common API so you can write easily libs targetting the ORM. This is why the django ecosystem is so rich : you can write an auth backend or a tagging system and know other people will be able to just plug it in. - it comes with tooling: auto generated admin, forms and APIs, migration manager, paginators... It does have a cost in perf and sometime flexibility. But for anything that doesn't have 1 million of users yet, it's worth it. Especially in a world where a daily salary can be more than a year of server time. I cache everything anyway :)
lowbloodsugar 10y ago
This page will serve as a very useful "Who not to hire" page.
quantumhobbit 10y ago
The idea of "use Hibernate so you don't have to write SQL" while being objectively wrong, also hits on an antipattern I've noticed over and over again. The "- so you don't have to -" anti pattern. Such as "we will configire this in xml so you don't have to write more code". Or "put some code in the database so you don't have to do a deployment process to make changes." You always end up having to do the thing you were trying to avoid plus deal with the middleman abstraction you introduced trying to avoid it. Anytime I hear someone say "- so you don't have to -" I wince and anticipate upcoming technical debt.
- toast0 10y ago
  I'm not sure "so you don't have to" is the problem; it's that do X so you don't have to do Y is only helpful if X costs less than Y. So use an ORM so you don't have to write and maintain SQL is bad, because writing and maintaining SQL is not expensive, but using an ORM is (at least in my experience: I've run into many cases where the ORM generates pathological queries that aren't fixable without throwing away all the code that was calling into the ORM; where a bad query in plain SQL is usually readily accessible). On the other hand, use Erlang's hot code loading so you don't have to restart nodes to update code is not bad: hot code loading isn't super expensive (you have to do a little bit of planning for some types of changes), but restarting nodes is (first you have to move all the traffic, then you have to actually restart it, then you have to move the traffic back).
  - chii 10y ago
    my take on hibernate, or ORMs in general, is really to abstract the _differences_ between vendors' sql implementation (including creation, and upgrading of schema). If you have to ship a product that have to work under all database vendors, an ORM like hibernate is the only choice - otherwise, you'd have to write separate scripts for each vendor, and that just makes the job at least 5x harder (or more, assuming you go for more vendors). Not kwowing how to write proper SQL is a problem, and ORM won't solve that for you.
    - guelo 10y ago
sophiedeziel 10y ago
I suggest a better title for that article: "How I blame technology X of almost ruining my career when I am the only one to blame because I did not understand what I was doing"
- quantumhobbit 10y ago
  I sort of sympathize though because there is overwhelming pressure to use the latest fad in software engineering. At one point Hibernate was the cool new thing, so cool that even non technical managers heard of it. And you really don't want to have to explain to ever busybody non programmer why you aren't using the cool new thing they are reading about. Even if you do explain yourself well, there is a chance they won't understand and will just assume you are incompetent or behind the times for not using Hibernate. Much easier to just use the damned thing and hope for the best. If you doubt me on this, I challenge you to go to a typical enterprise and develop a web page with vanilla js or HTML forms today. Or build a data project without using something like Spark, even if you only have a few hundred MBs of data.
  - Daishiman 10y ago
    > If you doubt me on this, I challenge you to go to a typical enterprise and develop a web page with vanilla js or HTML forms today. Or build a data project without using something like Spark, even if you only have a few hundred MBs of data. No, that problem is called "having shitty people skills that are so grave that you can't sell the benefits of mature technology and experience to people who leave and breathe cost-benefit analyses". The only common theme is developers who can't interact with non-technical staff. Most people out there are actually working with relatively mature and effective tools, it's just that the only way you notice people not catching on to fads is the dead silence of keeping your head down while solving real problems.
gpawl 10y ago
> Software Architect I found the problem.
hibikir 10y ago
Java circa 2005 had a whole lot of problems, but if you ask me, the biggest problem of it all was that many of the 'solutions' to the problems were worse than the disease. Back in the day, a friend of mine brought me in to write business software in Java for a small retail company. They didn't have much money, but they also didn't have any management that cared about our technical decisions, so we had a freedom that helped our careers tremendously: Nobody is making any less than 3x what they did then. But along with that freedom came the responsibility of getting the decisions right. Hibernate was a great improvement over the awfulness that was naked JDBC, but the risks to bad performance were so terrible that we ended up just writing some decorators to make JDBC usable instead. Years later, I went to a big enterprise place, and saw what happens when developers stop learning SQL, and use hibernate to run complex queries.... and then I learned how big of a bullet we dodged. Hibernate wasn't the only bullet though: One that Java is still suffering from is Spring. We decided that exchanging boilerplate you compile for XML was not a good tradeoff. Later they added annotations, but still, handing all of that wiring to the runtime is just not a good idea. Spring also taught people that it's easy to just have objects that can be constructed in ways that are broken (zero param constructors were easier to use), made application startup slower than even EJB, produce error messages that make the Clojure compiler seem friendly, and added all kinds of insane nonsense that made Rod Johnson quite rich, but didn't help Java itself move forward. Java 1.4 and java 5, out of the box, are like a person with a broken femur. Instead of fixing the bone, most of the ecosystem was just feeding the patient oxycodone: The result was that the patient still had a broken bone that was setting incorrectly, and the patient was now addicted to opiates. And yet, the people that wrote the bad tools that caused this have nice houses in Nob Hill and get to try to build new startups, now selling us their magical solution to the microservice problem. The Java ecosystem only started to move forward when Ruby on Rails came to town, and, despite all of it's own problems, made it clear that the whole thing had to move forward. Now the JVM has far better languages than Java, and Java itself has actually improved in important ways, but that was due to competition, not bad solutions to problems. I think we are back in the same boat with NoSQL databases: The companies selling tooling that did well didn't do so on good engineering, while the companies that did the best engineering struggle. But is the whole movement a good idea, or are we just going to see something like Spanner come in and the technologies that people got so excited about were just low quality solutions to problems that most of the time we didn't even have? I think there's more to learn from the pattern of how developer tools succeed (and fail to deliver), than from just the lesson of Hibernate's tremendous shortcomings for anything complicated.
gime_tree_fiddy 10y ago
Maybe this is out of inexperience, but having worked with Rails' and Django's respective ORMs, some of the things, about Hibernate, from this article like, lacking migration support seem a bit strange. And never having used it, feel like I am not seeing the complete picture. Anyone with having worked with both, care commenting ?
jpgvm 10y ago
I used to think I needed to learn an ORM to be able to write maintainable software. However time taught me writing maintainable SQL with good migration story is way better. ORMs make porting queries to another project that needs to use the same database difficult. It's less obvious what is really happening and the performance usually isn't as good as hand written SQL. Hand written SQL also means fine grained control over prepared queries, access to vendor specific features (advisory locks, LISTEN/NOTIFY, triggers), materialised views etc. You could argue these should be domain of DBA but in my opinion all devs should atleast know SQL at this level.
- specialist 10y ago
  ORMs also increase the cost of change, thwarting code evolution / refactoring.
  - flukus 10y ago
    I'd definitely disagree there. It's a lot easier to refactor code than to refactor a multitude of sql statements.
    - specialist 10y ago
      How about when refactoring your database? How does that impact your mappings, DAOs, testing regiment?
- mb_72 10y ago
  > ORMs make porting queries to another project that needs to use the same database difficult. Wouldn't you have written a shared library through which both projects access the same database? I know SQL pretty well (20+ years experience), but still use ORMs with nary a reason to hand-code any SQL any more. As a small-business-focused consultant using Microsoft technologies I do realise this puts me in a different bracket than others using larger-scale datasets and so forth, however for me using an ORM makes my life easier, makes me more productive, and with a little attention to detail doesn't result in performance issues for clients.
- 10y ago
jpgvm 10y ago
I used to think I needed to learn an ORM to be able to write maintainable software. However time taught me writing maintainable SQL with good migration story is way better. ORMs make porting queries to another project that needs to use the same database difficult. It's less obvious what is really happening and the performance usually isn't as good as hand written SQL. Hand written SQL also means fine grained control over prepared queries, access to vendor specific features (advisory locks, LISTEN/NOTIFY, triggers), materialised views etc. You could argue these should be domain of DBA but in my opinion all devs should atleast know SQL at this level.
lmm 10y ago
Hibernate didn't ruin his career, SQL did. If he'd actually worked with Hibernate, rather than abandoning it for SQL at the first opportunity, he would have got a system that performed well for less effort, was database-independent (which makes it easier to e.g. have a better test suite, because you have a wealth of in-memory options for testing so you can afford to run more tests on each build) and was more maintainable. All too often I've seen it play out like this: 1. Hibernate system working great 2. Idiot notices that one of their queries is slow, blames Hibernate 3. Idiot writes their query in raw SQL because hurr durr SQL is faster than Hibernate. (Bonus points for never benchmarking anything. Extra bonus points for switching to SQL and adding an index at the same time, observing this makes it faster, and deciding it's probably the switch to SQL that made the difference) 4. Idiot notices their query is getting results that are inconsistent with recent changes that went via Hibernate. 5. Rather than making any effort to fix this properly, idiot disables all caching in Hibernate. There, I fixed it. 6. Idiot notices that Hibernate queries are now slow (gee, ya think?) and uses this as a reason to migrate all other queries to raw SQL. Hibernate doesn't save you from having to design a good data model, nor from having to tune it for performance. You can't turn off your brain when using Hibernate, you do still have to figure out which entities own which side of their relationships, and when you get to a scale where performance becomes an issue you do have to spend a bit of time doing performance tuning, just as you do when using SQL. It does genuinely simplify a lot of things and save you from writing a lot of boilerplate. But if you spend a week tuning your SQL query and no time tuning your Hibernate query and use that as your benchmark, no shit the SQL will be faster, and if your first resort whenever you hit a slow query is going to be to bypass Hibernate rather than working with it then yeah you probably shouldn't be using Hibernate in the first place.
- pvg 10y ago
  How is any of this a counterargument to the article? And the hypothetical developer in it is a woman. And in their (again, fictional) scenario, they struggled with Hibernate for four years.
  - lmm 10y ago
    The developers in the article make the same mistake - using native SQL "for performance" instead of working with Hibernate. I read the title as referring to the (male) author's career; I understood him to be telling his own story through these hypothetical characters.
yomly 10y ago
In this story, Monica was able to actually get to year 4. What's to say that if she went with raw SQL, the team never would have been productive enough to match their run rate. For every story there is of a successful team who rues using an ORM, how many teams are out there who are lost to the obscurity of failure thanks to not choosing a fast over correct solution. Now, this is not a judgment for or against SQL, given there are plenty of users of Hibernate, it has clearly worked for some teams. Equally, given people still write SQL, I am sure it has worked for many people. Fundamentally there are two questions to my post: 1 - how much could have been saved in this scenario by a better team 2 - how often is it that the right solution now becomes the wrong solution later?
- lucio 10y ago
  "raw sql"? SQL is not assembler. SQL is a descriptive lang a few steps higher in the abstraction ladder from any algol-derived lang as C,java,etc. If they had chosen to go with plain SQL, maybe the project would be finished successfully by year two.
huula 10y ago
I'm using scala Slick for huula, should I have this concern too since the development there seems really like just a one company effort.
lucio 10y ago
This article: http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... is 10 yrs old. It is clear and to the point. ORM is a bad choice. Take a little time to Learn SQL basics, it is easier than any programming language.
ransom1538 10y ago
Look, if you write clear sql anyone will be able to read it. ANSI sql can be read by people even from other languages. You need to wrap it layers of bizarre abstraction and tape on language specific orms. How else will you keep your job?
snarfy 10y ago
> We’re always struggling with lazy/eager fetching problems. At one point, we decided to do everything eagerly, but it seems suboptimal, and besides, sometimes it’s not possible to access some fields because there is no session, or something like that. Is that normal? WTF. No concept of the N+1 problem. > We’re still struggling with which database engine to use for the final deployment. I thought Hibernate was portable, but we have some native queries that use some MS SQL magic, and we’d actually like to go with MySQL in the production WTF. Why are you developing against MS-SQL then? > Sometimes we spend days looking for errors. It seems like we have to analyze Hibernate-generated SQL because we have no idea why it’s not working as expected and it’s producing unexpected results. WTF. If you don't understand your ORM you won't understand the queries it generates. > Can you help me understand how Hibernate cache works? I just don’t get it. There are some first/second level caches. What is this all about? WTF. No concept of using transactions. I've used ORMs longer than the term ORM existed. I've never once thought it as a replacement for SQL. It's a supplemental tool.
- JohnBooty 10y ago
  > WTF. No concept of the N+1 problem. Huh? I feel like I'm missing something. Eager loading, done right, is how you avoid the N+1 problem. In ActiveRecord, Customer.includes(:orders).where(customer_name: 'Fred') would execute, at most, two queries even if there are many Freds with many orders. The only real ORMs I've used are ActiveRecord and a tiny bit of EntityFramework. Is this kind of eager loading not common? Or did I misunderstand your remark?
  - snarfy 10y ago
    The N+1 problem is caused by lazy loading. It's when you have an entity, e.g. Customer which has a property Orders with a foreign key relationship to Customer. The property is not materialized until it's accessed, causing an extra (N+1) query to be run. This can be avoided with something like e.g. EntityFramework which is based on the IQueryable interface and expression trees. In EF it would be var query = DbContext.Customers.Include( c => c.Orders).Where( c => c.customer_name == "Fred"); The value of query is an expression until it is iterated or converted to e.g. .ToList(); The expression is built using the relationships defined in the mapping which allows EF to use a proper SQL join, avoiding two queries and the N+1 problem.
therealmarv 10y ago
Currently dealing with a simple user database in a backend, Play Framework (Java) for a website. After reading this I'm worried doing this with EBean ORM is not good. Any advice/comments from experts?
- flukus 10y ago
  Do you know sql/databases well? If not learn that because you'll have to anyway. Then learn how your ORM works and what problems it solves (and what it doesn't).
wtbob 10y ago
> I had to learn Hibernate architecture, configuration, logging, naming strategies, tuplizers, entity name resolvers, enhanced identifier generators, identifier generator optimization, union-subclasses, XDoclet markup, bidirectional associations with indexed collections, ternary associations, idbag, mixing implicit polymorphism with other inheritance mappings, replicating object between two different datastores, detached objects and automatic versioning, connection release modes, stateless session interface, taxonomy of collection persistence, cache levels, lazy or eager fetching and many, many more. Welcome to Java … I generally find that an ORM makes easy things easy and difficult things indescribably hard or impossible. Honestly, the relational model is great, and it's worth understanding well. Frankly, if you're a software developer and you can't learn SQL … you're not really a software developer.
- Gaelan 10y ago
  > makes easy things easy and difficult things indescribably hard or impossible I've found that nearly every abstraction does this in some form. In general, the easier the easy things are, the harder the hard things are. The trick is finding a good balance for your project.
- RhodesianHunter 10y ago
  "Welcome to Java …" Maybe in giant non-tech company legacy systems, or written by Indian off shore teams. These days with Java 8 there is almost none of that bull shit.
- flukus 10y ago
  > I generally find that an ORM makes easy things easy and difficult things indescribably hard or impossible. I agree, but raw sql makes the easy thing hard (or at least cumbersome), so the nice middle ground is to use hibernate for the easy things and sql for the hard things.
  - wtbob 10y ago
    With respect, I just don't find SQL that difficult, especially for the simple things that an ORM does a nice job with. "select foo, bar, baz from quux where uuid = '8bd67f1e-6bb8-4ccb-8ad4-fa631b36ab8e'" is easy.
intrasight 10y ago
I think ORMs are fine for greenfield CRUD apps done with code-first. SQL is the assembly language of the backend.
revetkn 10y ago
Shameless plug: if you're looking for a no-dependencies Java 8 JDBC wrapper, we have been using https://github.com/pyranid/pyranid https://github.com/pyranid/pyranid in production for a number of public-facing projects over a couple years and it has worked very well for us
carsongross 10y ago
A long time ago, in a programming language now forgotten (gosu) some interns and I created a SQL typeloader that allowed you to define your domain in SQL DDL files and then write query files in SQL that were accessible, type safe, directly from Gosu: https://github.com/gosu-lang/ragnardb https://github.com/gosu-lang/ragnardb https://github.com/gosu-lang/ragnardb-test https://github.com/gosu-lang/ragnardb-test No codegen, just made SQL resources a top level type safe resource you could work with. I liked the idea a lot.
jtchang 10y ago
Why does SQLAlchemy feel so much nicer than Hibernate? Is there something equivalent in the Java world?
- RhodesianHunter 10y ago
  Im a fan of JDBI http://jdbi.org/ http://jdbi.org/
azinman2 10y ago
I don't understand why SQL is avoided so much. Yes it can be a pain to get/transform types depending on the driver/adapter, but to me that's the whole of a thin wrapper. SQL is just code, not another API to learn, is typically just as self explanatory if not more, let's you use vendor-specific features easily, removes any voodoo so it's clearer what's going on, and isn't that hard to begin with.
jondubois 10y ago
I knew that ORMs where a bad idea since the first time I saw one many years ago. It never made any sense to me. I don't see how they simplify anything; even in the early stages. SQL is actually a really simple abstraction for fetching relational data.
725686 10y ago
If you need to map relational database to objects and don't use an ORM, you will eventually reinvent it, in a bad ugly and buggy way. ORM is hard. Hibernate is a fantastic robust thoroughly tested and massively successful framework. But as any power tool, in the wrong hands can be a disaster. https://martinfowler.com/bliki/OrmHate.html https://martinfowler.com/bliki/OrmHate.html
Terr_ 10y ago
A major red flag is if you hear any developers saying things like: "The ORM will abstract access to the database so that it's like everything's in memory."
jwatte 10y ago
"ORM" means "snake" in Swedish, and will bite you.
mnm1 10y ago
For our API, I've rewritten probably 2/3 of the public endpoints to use raw SQL. I'd like to rewrite the other apps as well. The non-ORM app has no issues whatsoever. I estimate probably an eighth to a quarter of the time I've spent in the last three years has been dealing with completely avoidable ORM issues. Yeah, I can relate. At least it wasn't my choice to use them. It's a minor consolation.
aisofteng 10y ago
Frankly, I've never understood the real-world utility of ORMs such as Hibernate. As far as I can tell, their purpose is to "abstract away" a database. But why? SQL isn't hard. Learning database optimization is nontrivial but doable for anyone. Why do we need ORMs? Why is it better to replace a "WHERE ..." clause with ".where(...)"? My personal impression is that these frameworks were developed for people that know how to write code in some language but don't know how databases work and want something easy instead of learning how databases work. It really feels very lazy to me. If you have a library or framework thatproperly prevents SQL injection attacks, why use an ORM unless you feel too lazy or scared to learn how to use a database properly?
- Daishiman 10y ago
  SQL cannot be trivially composed. If you want to dynamically build a query you're better off using a query builder to generate that SQL than trying to play around with strings. SQL lacks support for some pretty basic things like query aliases. Try writing 5 nested queries vs using variables to store the different criteria. SQL has unnecessary grammar restrictions. Where you're putting your ORDER BY should be irrevant. Join syntax is frankly horrendous. It's difficult to autocomplete. Embedding SQL in your code is a recipe for disaster. Your compiler does not understand it, therefore refactoring means going over every query you have and manually looking to see what changes to do. It cannot be validated in compile time. SQL strings have no knowledge of the backing domain until they're actually run. And finally, 99% of the time you really do want to fetch and object with relations from the DB, not simple maps of field names. Aliasing field names in SQL from joins is a waste of my time. Making the returned data map to whatever object actually contains the business logic I'm interested in gets old, fast.
  - aisofteng 10y ago
    >SQL cannot be trivially composed. If you want to dynamically build a query you're better off using a query builder to generate that SQL than trying to play around with strings. SQL isn't supposed to be composed. It is a query language for a relational database structure. What composition is to run of the mill programming languages is what relations are to databases, roughly speaking. >SQL lacks support for some pretty basic things like query aliases. Try writing 5 nested queries vs using variables to store the different criteria. "Basic things" that are basic things for programming languages. SQL has support for what it should have support for - having intermediary variables (in the sense that general purpose programming languages have variables) is not one of those things. This comment belies a lack of understanding of how databases work and why. >SQL has unnecessary grammar restrictions. Where you're putting your ORDER BY should be irrevant. Join syntax is frankly horrendous. It's difficult to autocomplete. The decision regarding where to order is absolutely relevant and is strongly dependent on your data model. Join syntax is a syntax to accomplish joins, which are fundamental to modeling of relational data. And, frankly, if autocomplete is a criteria for you, then, in the context of these tools, you are not a developer, you are an end user. >Embedding SQL in your code is a recipe for disaster. Your compiler does not understand it, therefore refactoring means going over every query you have and manually looking to see what changes to do. It cannot be validated in compile time. SQL strings have no knowledge of the backing domain until they're actually run. This statement makes it clear that you have not seriously developed an application that is strongly dependent on a serious database. At least almost everything you said here is "not even wrong": https://en.wikipedia.org/wiki/Not_even_wrong https://en.wikipedia.org/wiki/Not_even_wrong >And finally, 99% of the time you really do want to fetch and object with relations from the DB, not simple maps of field names. Aliasing field names in SQL from joins is a waste of my time. Making the returned data map to whatever object actually contains the business logic I'm interested in gets old, fast. I suggest you take a look at database design and relational information modeling. You really seem to not know what the problems are that relational databases solve, how to use them, or how to use them well.
bullen 10y ago
Having built my own ORM and my own distributed key/value JSON store with index over HTTP I can say SQL is the problem, SQL databases are older than the internet, they have not evolved since the 70s. You need async on the network preferably over HTTP (to be client agnostic) and almost no database provides that today. Heck no programming language provides multi threaded non blocking IO with shared memory, only C++ (and maybe modern attempts Rust, Go, Swift etc.) and Java (C#) are capable languages.
gentleteblor 10y ago
Does Java not have a good Micro ORMs (like Dapper, NPoco on the .Net side)? They can be a wonderful middle ground between completely custom sql and a full blown giant like Hibernate.

78 points by lightlyused 10y ago

Straw man script about what happens when you "blindly use Hibernate." I suppose there are lots of people in the world who do that. I would think that Hibernate isn't the sole problem in those cases.

NeutronBoy 10y ago
'How selecting a tool without understanding if it was the right tool to use was the wrong decision'
- raverbashing 10y ago
  "this just works, nobody needs to know theorical stuff anymore"

xyzzy4 10y ago

SQL is an amazing and very useful tool to work with. I will never understand why people want to abstract it away.

lostcolony 10y ago
"SQL seems hard" "Here's a tool that makes it so you don't have to use SQL" "Great! Let's use that" - without having done the work to determine if that tool is actually any simpler (hint: it's not)
bradmwalker 10y ago
SQL needs marketing. Become obsolete unless you understand this durable persistence and functional, high-leverage reporting service!
busterarm 10y ago
I understand why they do, but I don't understand why more developers don't learn SQL. _it's freaking easy_!!! I become the defacto SQL guy at every job I work because other people don't want to touch it for some reason. I write SQL (or SOQL...ugh, Salesforce) virtually every day on the job (I do a ton of ETL in Ruby) and use it to give valuable business intelligence. Constantly I see other programmers jump through all sorts of technical hoops to get things done that could be done in a DB query quicker with more accuracy and less mental overhead. Just write your own toy ORM sometime. Copy the most-common functions of ActiveRecord. It's that easy. That's all it takes.
nicolas_t 10y ago
I use ORMs (ActiveRecord in Ruby, Sequelize in node.js) but I strongly believe that the only way to correctly use an ORM is to have a strong understanding of SQL. The ORM is useful in that it makes some things faster to write, makes my code cleaner but I will often revert back to SQL for critical operations that I need to be fast and I also know enough about how the ORM writes SQL to make sure that it doesn't do stupid queries. TLDR: ORMs are a good tool but must never be used to avoid learning SQL. An SQL knowledge is necessary to not shoot yourself in the foot.
PretzelFisch 10y ago
I think it's like javascript, when you had to use one language on the server then switch to something else on the client it lead to many years of trying to abstract html and javascript into java/c#... Maybe it would help if languages would allow for first class integration with sql like asp did for html

pstuart 10y ago

I supported a deals site that used Hibernate with JBoss. We went through several years of scaling pain until a consulting engineer found that the Hibernate cache settings were left at their defaults.

ThomaszKrueger 10y ago

"To get a report, we have to wait two days!" Who in their right mind would use Hibernate (or any other ORM for that matter) for reporting?

koolba 10y ago
I think JIRA uses it. I vaguely remember the query format for it being a form of JPQL.
- busterarm 10y ago
  Funny that. The larger our (not particularly large) JIRA account gets, the slower it performs. Very noticeably so.
karlkatzke 10y ago
Java developers?

anthonybsd 10y ago

This doesn't look like it was a problem with Hibenrate, more of a "wrong tool for the job"-scenario. Reposting what I recently wrote on Reddit on a similar Hibernate discussion thread: In my experience, ORMs and specifically SpringData-JPA-Hibernate occupy this weird niche in the enterprise spectrum. They are an overkill for small projects and they become a hinderance for large projects, so they sort of sit there for medium projects. If you start with an ORM on a medium size project and it becomes a big project you can sometimes find yourself in an awkward spot where you are writing a lot of SQL (and not of the JPQL kind). With Hibernate/JPA specifically there are so many things that are broken that they just start getting in the way if your schemas become large enough. To me this is really just a manifestation of Behavioral Problem (Martin Fowler, Enterprise Patterns), where relational databases don't really map to objects at all when you get down to it. Basically, if you are going to do quite a bit of SQL, any ORM will just in the way. Should be plainly obvious to anyone with experience.

sametmax 10y ago
It depends a lot of the ORM. SQLAlchemy allows you to ditch the ORM when you need it. But instead of going back to raw sql, you just get a DSL like LINK, which is very flexible and can express most of the stuff you could do with manual SQL, while still retaining many benefits of using a wrapper. It's my understanding that Hibernate doesn't allow this. > Basically, if you are going to do quite a bit of SQL, any ORM will just in the way. Should be plainly obvious to anyone with experience. This is the problem you see : a lot of project don't have somebody very experienced with SQL anymore. Because they need to know a bit of sysadmin, and front en dev, and deployment, and CI, etc. So an ORM helps a lot in that regard, and will help most projects because the problems it causes are smaller that the ones it solves: - it forces people to put the schema, migrations and validation code in a centralized place. - it let you reuse your API knowledge instead of having to relearn the stuff for SQLite/Postgres/MySQL/Access. - it enforces good practices on security with data escaping and cleaning. - it let you benefit from your language tooling (analytics, linters, completions, doc, shells) to write queries that otherwise would be plain text in the middle of the file for most people. - it gives a structure to DB operations, so if you look for something, you know where and what to look for. - it gives you an event system to decouple queries and their effect. - it gives a common API so you can write easily libs targetting the ORM. This is why the django ecosystem is so rich : you can write an auth backend or a tagging system and know other people will be able to just plug it in. - it comes with tooling: auto generated admin, forms and APIs, migration manager, paginators... It does have a cost in perf and sometime flexibility. But for anything that doesn't have 1 million of users yet, it's worth it. Especially in a world where a daily salary can be more than a year of server time. I cache everything anyway :)

lowbloodsugar 10y ago

This page will serve as a very useful "Who not to hire" page.

quantumhobbit 10y ago

The idea of "use Hibernate so you don't have to write SQL" while being objectively wrong, also hits on an antipattern I've noticed over and over again. The "- so you don't have to -" anti pattern. Such as "we will configire this in xml so you don't have to write more code". Or "put some code in the database so you don't have to do a deployment process to make changes." You always end up having to do the thing you were trying to avoid plus deal with the middleman abstraction you introduced trying to avoid it. Anytime I hear someone say "- so you don't have to -" I wince and anticipate upcoming technical debt.

toast0 10y ago
I'm not sure "so you don't have to" is the problem; it's that do X so you don't have to do Y is only helpful if X costs less than Y. So use an ORM so you don't have to write and maintain SQL is bad, because writing and maintaining SQL is not expensive, but using an ORM is (at least in my experience: I've run into many cases where the ORM generates pathological queries that aren't fixable without throwing away all the code that was calling into the ORM; where a bad query in plain SQL is usually readily accessible). On the other hand, use Erlang's hot code loading so you don't have to restart nodes to update code is not bad: hot code loading isn't super expensive (you have to do a little bit of planning for some types of changes), but restarting nodes is (first you have to move all the traffic, then you have to actually restart it, then you have to move the traffic back).
- chii 10y ago
  my take on hibernate, or ORMs in general, is really to abstract the _differences_ between vendors' sql implementation (including creation, and upgrading of schema). If you have to ship a product that have to work under all database vendors, an ORM like hibernate is the only choice - otherwise, you'd have to write separate scripts for each vendor, and that just makes the job at least 5x harder (or more, assuming you go for more vendors). Not kwowing how to write proper SQL is a problem, and ORM won't solve that for you.
  - guelo 10y ago

sophiedeziel 10y ago

I suggest a better title for that article: "How I blame technology X of almost ruining my career when I am the only one to blame because I did not understand what I was doing"

quantumhobbit 10y ago
I sort of sympathize though because there is overwhelming pressure to use the latest fad in software engineering. At one point Hibernate was the cool new thing, so cool that even non technical managers heard of it. And you really don't want to have to explain to ever busybody non programmer why you aren't using the cool new thing they are reading about. Even if you do explain yourself well, there is a chance they won't understand and will just assume you are incompetent or behind the times for not using Hibernate. Much easier to just use the damned thing and hope for the best. If you doubt me on this, I challenge you to go to a typical enterprise and develop a web page with vanilla js or HTML forms today. Or build a data project without using something like Spark, even if you only have a few hundred MBs of data.
- Daishiman 10y ago
  > If you doubt me on this, I challenge you to go to a typical enterprise and develop a web page with vanilla js or HTML forms today. Or build a data project without using something like Spark, even if you only have a few hundred MBs of data. No, that problem is called "having shitty people skills that are so grave that you can't sell the benefits of mature technology and experience to people who leave and breathe cost-benefit analyses". The only common theme is developers who can't interact with non-technical staff. Most people out there are actually working with relatively mature and effective tools, it's just that the only way you notice people not catching on to fads is the dead silence of keeping your head down while solving real problems.

gpawl 10y ago

> Software Architect I found the problem.

hibikir 10y ago

Java circa 2005 had a whole lot of problems, but if you ask me, the biggest problem of it all was that many of the 'solutions' to the problems were worse than the disease. Back in the day, a friend of mine brought me in to write business software in Java for a small retail company. They didn't have much money, but they also didn't have any management that cared about our technical decisions, so we had a freedom that helped our careers tremendously: Nobody is making any less than 3x what they did then. But along with that freedom came the responsibility of getting the decisions right. Hibernate was a great improvement over the awfulness that was naked JDBC, but the risks to bad performance were so terrible that we ended up just writing some decorators to make JDBC usable instead. Years later, I went to a big enterprise place, and saw what happens when developers stop learning SQL, and use hibernate to run complex queries.... and then I learned how big of a bullet we dodged. Hibernate wasn't the only bullet though: One that Java is still suffering from is Spring. We decided that exchanging boilerplate you compile for XML was not a good tradeoff. Later they added annotations, but still, handing all of that wiring to the runtime is just not a good idea. Spring also taught people that it's easy to just have objects that can be constructed in ways that are broken (zero param constructors were easier to use), made application startup slower than even EJB, produce error messages that make the Clojure compiler seem friendly, and added all kinds of insane nonsense that made Rod Johnson quite rich, but didn't help Java itself move forward. Java 1.4 and java 5, out of the box, are like a person with a broken femur. Instead of fixing the bone, most of the ecosystem was just feeding the patient oxycodone: The result was that the patient still had a broken bone that was setting incorrectly, and the patient was now addicted to opiates. And yet, the people that wrote the bad tools that caused this have nice houses in Nob Hill and get to try to build new startups, now selling us their magical solution to the microservice problem. The Java ecosystem only started to move forward when Ruby on Rails came to town, and, despite all of it's own problems, made it clear that the whole thing had to move forward. Now the JVM has far better languages than Java, and Java itself has actually improved in important ways, but that was due to competition, not bad solutions to problems. I think we are back in the same boat with NoSQL databases: The companies selling tooling that did well didn't do so on good engineering, while the companies that did the best engineering struggle. But is the whole movement a good idea, or are we just going to see something like Spanner come in and the technologies that people got so excited about were just low quality solutions to problems that most of the time we didn't even have? I think there's more to learn from the pattern of how developer tools succeed (and fail to deliver), than from just the lesson of Hibernate's tremendous shortcomings for anything complicated.

gime_tree_fiddy 10y ago

Maybe this is out of inexperience, but having worked with Rails' and Django's respective ORMs, some of the things, about Hibernate, from this article like, lacking migration support seem a bit strange. And never having used it, feel like I am not seeing the complete picture. Anyone with having worked with both, care commenting ?

jpgvm 10y ago

I used to think I needed to learn an ORM to be able to write maintainable software. However time taught me writing maintainable SQL with good migration story is way better. ORMs make porting queries to another project that needs to use the same database difficult. It's less obvious what is really happening and the performance usually isn't as good as hand written SQL. Hand written SQL also means fine grained control over prepared queries, access to vendor specific features (advisory locks, LISTEN/NOTIFY, triggers), materialised views etc. You could argue these should be domain of DBA but in my opinion all devs should atleast know SQL at this level.

specialist 10y ago
ORMs also increase the cost of change, thwarting code evolution / refactoring.
- flukus 10y ago
  I'd definitely disagree there. It's a lot easier to refactor code than to refactor a multitude of sql statements.
  - specialist 10y ago
    How about when refactoring your database? How does that impact your mappings, DAOs, testing regiment?
mb_72 10y ago
> ORMs make porting queries to another project that needs to use the same database difficult. Wouldn't you have written a shared library through which both projects access the same database? I know SQL pretty well (20+ years experience), but still use ORMs with nary a reason to hand-code any SQL any more. As a small-business-focused consultant using Microsoft technologies I do realise this puts me in a different bracket than others using larger-scale datasets and so forth, however for me using an ORM makes my life easier, makes me more productive, and with a little attention to detail doesn't result in performance issues for clients.
10y ago

jpgvm 10y ago

lmm 10y ago

Hibernate didn't ruin his career, SQL did. If he'd actually worked with Hibernate, rather than abandoning it for SQL at the first opportunity, he would have got a system that performed well for less effort, was database-independent (which makes it easier to e.g. have a better test suite, because you have a wealth of in-memory options for testing so you can afford to run more tests on each build) and was more maintainable. All too often I've seen it play out like this: 1. Hibernate system working great 2. Idiot notices that one of their queries is slow, blames Hibernate 3. Idiot writes their query in raw SQL because hurr durr SQL is faster than Hibernate. (Bonus points for never benchmarking anything. Extra bonus points for switching to SQL and adding an index at the same time, observing this makes it faster, and deciding it's probably the switch to SQL that made the difference) 4. Idiot notices their query is getting results that are inconsistent with recent changes that went via Hibernate. 5. Rather than making any effort to fix this properly, idiot disables all caching in Hibernate. There, I fixed it. 6. Idiot notices that Hibernate queries are now slow (gee, ya think?) and uses this as a reason to migrate all other queries to raw SQL. Hibernate doesn't save you from having to design a good data model, nor from having to tune it for performance. You can't turn off your brain when using Hibernate, you do still have to figure out which entities own which side of their relationships, and when you get to a scale where performance becomes an issue you do have to spend a bit of time doing performance tuning, just as you do when using SQL. It does genuinely simplify a lot of things and save you from writing a lot of boilerplate. But if you spend a week tuning your SQL query and no time tuning your Hibernate query and use that as your benchmark, no shit the SQL will be faster, and if your first resort whenever you hit a slow query is going to be to bypass Hibernate rather than working with it then yeah you probably shouldn't be using Hibernate in the first place.

pvg 10y ago
How is any of this a counterargument to the article? And the hypothetical developer in it is a woman. And in their (again, fictional) scenario, they struggled with Hibernate for four years.
- lmm 10y ago
  The developers in the article make the same mistake - using native SQL "for performance" instead of working with Hibernate. I read the title as referring to the (male) author's career; I understood him to be telling his own story through these hypothetical characters.

yomly 10y ago

In this story, Monica was able to actually get to year 4. What's to say that if she went with raw SQL, the team never would have been productive enough to match their run rate. For every story there is of a successful team who rues using an ORM, how many teams are out there who are lost to the obscurity of failure thanks to not choosing a fast over correct solution. Now, this is not a judgment for or against SQL, given there are plenty of users of Hibernate, it has clearly worked for some teams. Equally, given people still write SQL, I am sure it has worked for many people. Fundamentally there are two questions to my post: 1 - how much could have been saved in this scenario by a better team 2 - how often is it that the right solution now becomes the wrong solution later?

lucio 10y ago
"raw sql"? SQL is not assembler. SQL is a descriptive lang a few steps higher in the abstraction ladder from any algol-derived lang as C,java,etc. If they had chosen to go with plain SQL, maybe the project would be finished successfully by year two.

huula 10y ago

I'm using scala Slick for huula, should I have this concern too since the development there seems really like just a one company effort.

lucio 10y ago

This article: http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... is 10 yrs old. It is clear and to the point. ORM is a bad choice. Take a little time to Learn SQL basics, it is easier than any programming language.

ransom1538 10y ago

Look, if you write clear sql anyone will be able to read it. ANSI sql can be read by people even from other languages. You need to wrap it layers of bizarre abstraction and tape on language specific orms. How else will you keep your job?

snarfy 10y ago

> We’re always struggling with lazy/eager fetching problems. At one point, we decided to do everything eagerly, but it seems suboptimal, and besides, sometimes it’s not possible to access some fields because there is no session, or something like that. Is that normal? WTF. No concept of the N+1 problem. > We’re still struggling with which database engine to use for the final deployment. I thought Hibernate was portable, but we have some native queries that use some MS SQL magic, and we’d actually like to go with MySQL in the production WTF. Why are you developing against MS-SQL then? > Sometimes we spend days looking for errors. It seems like we have to analyze Hibernate-generated SQL because we have no idea why it’s not working as expected and it’s producing unexpected results. WTF. If you don't understand your ORM you won't understand the queries it generates. > Can you help me understand how Hibernate cache works? I just don’t get it. There are some first/second level caches. What is this all about? WTF. No concept of using transactions. I've used ORMs longer than the term ORM existed. I've never once thought it as a replacement for SQL. It's a supplemental tool.

JohnBooty 10y ago
> WTF. No concept of the N+1 problem. Huh? I feel like I'm missing something. Eager loading, done right, is how you avoid the N+1 problem. In ActiveRecord, Customer.includes(:orders).where(customer_name: 'Fred') would execute, at most, two queries even if there are many Freds with many orders. The only real ORMs I've used are ActiveRecord and a tiny bit of EntityFramework. Is this kind of eager loading not common? Or did I misunderstand your remark?
- snarfy 10y ago
  The N+1 problem is caused by lazy loading. It's when you have an entity, e.g. Customer which has a property Orders with a foreign key relationship to Customer. The property is not materialized until it's accessed, causing an extra (N+1) query to be run. This can be avoided with something like e.g. EntityFramework which is based on the IQueryable interface and expression trees. In EF it would be var query = DbContext.Customers.Include( c => c.Orders).Where( c => c.customer_name == "Fred"); The value of query is an expression until it is iterated or converted to e.g. .ToList(); The expression is built using the relationships defined in the mapping which allows EF to use a proper SQL join, avoiding two queries and the N+1 problem.

therealmarv 10y ago

Currently dealing with a simple user database in a backend, Play Framework (Java) for a website. After reading this I'm worried doing this with EBean ORM is not good. Any advice/comments from experts?

flukus 10y ago
Do you know sql/databases well? If not learn that because you'll have to anyway. Then learn how your ORM works and what problems it solves (and what it doesn't).

wtbob 10y ago

> I had to learn Hibernate architecture, configuration, logging, naming strategies, tuplizers, entity name resolvers, enhanced identifier generators, identifier generator optimization, union-subclasses, XDoclet markup, bidirectional associations with indexed collections, ternary associations, idbag, mixing implicit polymorphism with other inheritance mappings, replicating object between two different datastores, detached objects and automatic versioning, connection release modes, stateless session interface, taxonomy of collection persistence, cache levels, lazy or eager fetching and many, many more. Welcome to Java … I generally find that an ORM makes easy things easy and difficult things indescribably hard or impossible. Honestly, the relational model is great, and it's worth understanding well. Frankly, if you're a software developer and you can't learn SQL … you're not really a software developer.

Gaelan 10y ago
> makes easy things easy and difficult things indescribably hard or impossible I've found that nearly every abstraction does this in some form. In general, the easier the easy things are, the harder the hard things are. The trick is finding a good balance for your project.
RhodesianHunter 10y ago
"Welcome to Java …" Maybe in giant non-tech company legacy systems, or written by Indian off shore teams. These days with Java 8 there is almost none of that bull shit.
flukus 10y ago
> I generally find that an ORM makes easy things easy and difficult things indescribably hard or impossible. I agree, but raw sql makes the easy thing hard (or at least cumbersome), so the nice middle ground is to use hibernate for the easy things and sql for the hard things.
- wtbob 10y ago
  With respect, I just don't find SQL that difficult, especially for the simple things that an ORM does a nice job with. "select foo, bar, baz from quux where uuid = '8bd67f1e-6bb8-4ccb-8ad4-fa631b36ab8e'" is easy.

intrasight 10y ago

I think ORMs are fine for greenfield CRUD apps done with code-first. SQL is the assembly language of the backend.

revetkn 10y ago

Shameless plug: if you're looking for a no-dependencies Java 8 JDBC wrapper, we have been using https://github.com/pyranid/pyranid https://github.com/pyranid/pyranid in production for a number of public-facing projects over a couple years and it has worked very well for us

carsongross 10y ago

A long time ago, in a programming language now forgotten (gosu) some interns and I created a SQL typeloader that allowed you to define your domain in SQL DDL files and then write query files in SQL that were accessible, type safe, directly from Gosu: https://github.com/gosu-lang/ragnardb https://github.com/gosu-lang/ragnardb https://github.com/gosu-lang/ragnardb-test https://github.com/gosu-lang/ragnardb-test No codegen, just made SQL resources a top level type safe resource you could work with. I liked the idea a lot.

jtchang 10y ago

Why does SQLAlchemy feel so much nicer than Hibernate? Is there something equivalent in the Java world?

RhodesianHunter 10y ago
Im a fan of JDBI http://jdbi.org/ http://jdbi.org/

azinman2 10y ago

I don't understand why SQL is avoided so much. Yes it can be a pain to get/transform types depending on the driver/adapter, but to me that's the whole of a thin wrapper. SQL is just code, not another API to learn, is typically just as self explanatory if not more, let's you use vendor-specific features easily, removes any voodoo so it's clearer what's going on, and isn't that hard to begin with.

jondubois 10y ago

I knew that ORMs where a bad idea since the first time I saw one many years ago. It never made any sense to me. I don't see how they simplify anything; even in the early stages. SQL is actually a really simple abstraction for fetching relational data.

725686 10y ago

If you need to map relational database to objects and don't use an ORM, you will eventually reinvent it, in a bad ugly and buggy way. ORM is hard. Hibernate is a fantastic robust thoroughly tested and massively successful framework. But as any power tool, in the wrong hands can be a disaster. https://martinfowler.com/bliki/OrmHate.html https://martinfowler.com/bliki/OrmHate.html

Terr_ 10y ago

A major red flag is if you hear any developers saying things like: "The ORM will abstract access to the database so that it's like everything's in memory."

jwatte 10y ago

"ORM" means "snake" in Swedish, and will bite you.

mnm1 10y ago

For our API, I've rewritten probably 2/3 of the public endpoints to use raw SQL. I'd like to rewrite the other apps as well. The non-ORM app has no issues whatsoever. I estimate probably an eighth to a quarter of the time I've spent in the last three years has been dealing with completely avoidable ORM issues. Yeah, I can relate. At least it wasn't my choice to use them. It's a minor consolation.

aisofteng 10y ago

Frankly, I've never understood the real-world utility of ORMs such as Hibernate. As far as I can tell, their purpose is to "abstract away" a database. But why? SQL isn't hard. Learning database optimization is nontrivial but doable for anyone. Why do we need ORMs? Why is it better to replace a "WHERE ..." clause with ".where(...)"? My personal impression is that these frameworks were developed for people that know how to write code in some language but don't know how databases work and want something easy instead of learning how databases work. It really feels very lazy to me. If you have a library or framework thatproperly prevents SQL injection attacks, why use an ORM unless you feel too lazy or scared to learn how to use a database properly?

Daishiman 10y ago
SQL cannot be trivially composed. If you want to dynamically build a query you're better off using a query builder to generate that SQL than trying to play around with strings. SQL lacks support for some pretty basic things like query aliases. Try writing 5 nested queries vs using variables to store the different criteria. SQL has unnecessary grammar restrictions. Where you're putting your ORDER BY should be irrevant. Join syntax is frankly horrendous. It's difficult to autocomplete. Embedding SQL in your code is a recipe for disaster. Your compiler does not understand it, therefore refactoring means going over every query you have and manually looking to see what changes to do. It cannot be validated in compile time. SQL strings have no knowledge of the backing domain until they're actually run. And finally, 99% of the time you really do want to fetch and object with relations from the DB, not simple maps of field names. Aliasing field names in SQL from joins is a waste of my time. Making the returned data map to whatever object actually contains the business logic I'm interested in gets old, fast.
- aisofteng 10y ago
  >SQL cannot be trivially composed. If you want to dynamically build a query you're better off using a query builder to generate that SQL than trying to play around with strings. SQL isn't supposed to be composed. It is a query language for a relational database structure. What composition is to run of the mill programming languages is what relations are to databases, roughly speaking. >SQL lacks support for some pretty basic things like query aliases. Try writing 5 nested queries vs using variables to store the different criteria. "Basic things" that are basic things for programming languages. SQL has support for what it should have support for - having intermediary variables (in the sense that general purpose programming languages have variables) is not one of those things. This comment belies a lack of understanding of how databases work and why. >SQL has unnecessary grammar restrictions. Where you're putting your ORDER BY should be irrevant. Join syntax is frankly horrendous. It's difficult to autocomplete. The decision regarding where to order is absolutely relevant and is strongly dependent on your data model. Join syntax is a syntax to accomplish joins, which are fundamental to modeling of relational data. And, frankly, if autocomplete is a criteria for you, then, in the context of these tools, you are not a developer, you are an end user. >Embedding SQL in your code is a recipe for disaster. Your compiler does not understand it, therefore refactoring means going over every query you have and manually looking to see what changes to do. It cannot be validated in compile time. SQL strings have no knowledge of the backing domain until they're actually run. This statement makes it clear that you have not seriously developed an application that is strongly dependent on a serious database. At least almost everything you said here is "not even wrong": https://en.wikipedia.org/wiki/Not_even_wrong https://en.wikipedia.org/wiki/Not_even_wrong >And finally, 99% of the time you really do want to fetch and object with relations from the DB, not simple maps of field names. Aliasing field names in SQL from joins is a waste of my time. Making the returned data map to whatever object actually contains the business logic I'm interested in gets old, fast. I suggest you take a look at database design and relational information modeling. You really seem to not know what the problems are that relational databases solve, how to use them, or how to use them well.

bullen 10y ago

Having built my own ORM and my own distributed key/value JSON store with index over HTTP I can say SQL is the problem, SQL databases are older than the internet, they have not evolved since the 70s. You need async on the network preferably over HTTP (to be client agnostic) and almost no database provides that today. Heck no programming language provides multi threaded non blocking IO with shared memory, only C++ (and maybe modern attempts Rust, Go, Swift etc.) and Java (C#) are capable languages.

gentleteblor 10y ago

Does Java not have a good Micro ORMs (like Dapper, NPoco on the .Net side)? They can be a wonderful middle ground between completely custom sql and a full blown giant like Hibernate.