You inspired me to see if this could be done to "unlock" tables to a rest-interface on a more general level, and it can be done: github.com/fwi/db2rest
It is far from "feature complete" but that was not the point: while writing the source code the benefits you outline in your conclusion (ease of use, code that does what it says) started to become apparent. I think I will venture forward in this direction.
OMG I have felt this way for years now about a lot of orms, well the 3 I have used (Django was another), but hibernate combined with spring plus jersey plus jax-rs plus javax.servlet 1.19 oh wait now I have to use 2.2, plus jetty for local but not jetty 8 because I had to switch to java 1.8 for something and so now I need jetty 9.2 but oh oops you arent using intellij jetty-runner I hope pal! There some bug so upgrade to 9.4 but then oh wait servlet standard 2.0 isn't working now in jetty, better say f-it and just ftp war file to aws instance oh thats better but then ohno wait now I have java 9 code from something wtf is osgi? wtf is asm? wtf is any of these 100s of dependencies???- thats a load of misery there, and then I really hope you didn't run this on wsl on windows because work makes you use windows and then you are running a windows intellij and a linux-kindof maven, OOPS!, and then I really hope you didn't have to wait until the last minute to upgrade the super old spring versions and swagger that your old boss who quit put in, and then someone upgraded bamboo to maven 3 and everything broke, and ......
it goes on from there. I am up at 3am for the 3rd week in a row trying to get this mess straightened out. It's a nightmare. This article gave me my first laugh in a week :D thank you and sorry for the rant
Hehe, I call this frustration driven development. First you get mad, then you fix it, and then you fix it properly. I recognize several of the things you are getting frustrated about (jersey is indeed a mess of dependencies). Tip, have less of that in your life and you'll feel better. In the case above, drop hibernate and it goes away. There's nothing it does that I need or miss in my life.
I can empathize with the frustrations of Hibernate. When I get to the point of: "OK, screw this, I need my native SQL, please." I tend to reach for jOOQ because I can get a much larger subset of SQL w/ clear, concise transactional semantics and the type-safe, SQL-like DSL that gives me that peace-of-mind about SQL injection. Since the DSL is code-generated during build time off of your schema, you get that extra layer of sturdiness by knowing at build-time (as opposed to at runtime, w/ string SQL) if your queries have invalid syntax. I'm not a jOOQ contributor, I just really like it.
We've been doing a fair bit of content recently over on TheServerSide about Hibernate and JDBC and was wondering if you might be interested in reprising the thoughts expressed here into an article we could publish on the site? I know the JPA vs JDBC vs Spring JDBC exactly the type of thing our readership is struggling with.
, sure. Contact me at jilles AT jillesvangurp.com to discuss further.
Hey guys, greate post. I feel the same as you 😅 the main problem imho is the API. Its just too error prone and complex.
The learning curve is way too steep.
But its possible to create well performing applications, it just needs hibernate experts (hard too find 😆)
That‘s why i created spot-next.io. Its a framework based on hibernate, but fixes most of its problems.
I know it sounds weird, fixing hibernate by adding more layers on top 😂
But maybe you are curious and wanna try it out? Feedback is very welcome.
At this point I'm using Kotlin. Basically hibernate doesn't solve any problem I have, creates a huge potential for problems, I definitely don't need, all while trying to solve things that are definitely not problems in a way that creates more problems than it is worth.
I and many others feel your pain. I've also had many challenges with Hibernate and JPA in general and "upgraded" to JdbcTemplate.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.