Thanks!

What else needs to covered?

I’d start with Spring Data JPA. Get your feet wet with JPA. It’s a very commonly used library. No harm learning. But it can also let you learn the shortcomings of JPA and what in turn; what Spring Data JDBC has to offer.

JPA is a bit tricky in these scenarios. JPA is simply a higher level query language translated into SQL by the JPA provider, so in the end, it becomes JDBC. The simplest queries would be probably be identical. Ensuring you have the right indexes and are running stats on the database are important. But when it comes time to "tune" your query based upon DBA feedback, it may be trickier to tune JPQL (or not). Again, depends on the scenario. This level of separation between written and actual query is what I feel made people VERY interested in Spring Data JDBC, and willing to trade in some of the JPA's feature set to get a little more control over the SQL.

Took a peek. Interesting approach. Unfortunately it only has one committer and no changes for 8 months. As for “better than those”, Persism uses JDBC under the hood. Just check out github.com/sproket/Persism/blob/persism2/src/net/sf/persism/ConnectionType.java. Also, if I may add, kind of strange to bake in all your supported platforms instead of making it open ended.

Awesome! Is there something else you've been eager to see that would be handy as a video?

Hmm, maybe some information about feignclients would be great. Btw thanks.

Glad you liked the video. And you have some very valid points (thanks for writing them in such detail). I'll try to respond to each one below: #1 - Agreed. Changing the backend is VERY rare. #2 - Agreed. I was trying to speak to the point where you get sold this bill of goods about "JPA protects you from the underlying DB." Companies don't REALLY change that much. But developers seem prone to lap this one up, as if writing JPA is somehow "easier" than writing for the platform that you're on. #3 - This is indeed true. Most of the "core" SQL stuff we use today works pretty well on all of them. It's just little stuff like "string concatenation" I've stumbled across is NOT portable. Also, some of the newer features like JSON operators tends to be platform-specific and NOT found across all the platforms. And yes, the era I wrote gobs of SQL was early 2000s, so when I'd spend weeks working on Oracle and then attempt to fashion a query for some business analyst in MS Access, I'd get burned on little stuff. #4 - I got called in plenty of times for the database being maxed out. Sometimes during the day. But often it would happen at night. Once, I was called in 3x on the same night, albeit not for being out of cursors. But the "forgot to close your cursors" thing was real for not just me but others on our team. And it would hit us again. Probably because we would implement three queries at once and "forget" to properly close all three. Murphy's Law?? Anyway, one would be the breaking point. We'd fix it. And it would take 6-12 weeks for the NEXT one to reach some breaking point. Rinse/repeat. This was a mixture of good ole J2EE back in the day for one app, and a non-Java app for another, we'd see the problem on both. Tools like Spring's JdbcTemplate, were it adopted, would eliminate a whole class of errors from ever happening. Pretty good bargain in my book. #5 - Yes, stored procedures and views and other things that move stuff INSIDE the DB typically are more performance. But you tend to migrate toward a different development style. We frankly would have required more time contribution from our DBA team to do that. And we had a limited budget. App developers writing SQL queries in their applications was an agreeable approach compared to stuffing everything into stored procedures and then tapping the DBA team when the stored procedure had to be patched/updated. At that point, you aren't really DOING data persistence in your application. You're just invoking remote APIs through the database driver. And this can be done with either JPA or JDBC. The differences between the two kind of dwindle in that context. As for how "easy" that approach is well...I watched someone that was supposedly better at SQL/PLSQL than me build a query by joining multiple views together to get the results he needed. Guy didn't realize he was joining the same table 20 times, thus causing the query to take 20 minutes to run. When he rolled off the contract and I picked up his app, it took me three weeks to grok it and then rewrite it. Query went sub-second and the department using it gave me a cute certificate award. Not everyone comprehends relational databases. Part of my point of this video is that developers, for years, were pitched that JPA/Hibernate makes it where you don't HAVE to understand the database. And that is simply wrong. #6 - That is a VERY valid point. If the database is simply the raw data and each app is gluing it together differently, you run the risk of not upholding the contract. We had the fortune of having one person from the DBA team assigned to the developers team so that we could ensure that ALL of us were doing the "same thing" with regarding to the data. The fact that we couldn't practically adopt stored procedures nor were we all even using the same technology (Java vs. Non-Java apps) meant we REALLY had to ensure our queries & views were properly aligned. And this guy helped us do just that. I'm hoping to not purport myths but instead address some of the assumptions people make with what JPA is and what JDBC is. And that by digging a little deeper, and understanding a little more, people can better use both of these technologies to achieve their solutions. Thanks for stopping by. Hope you'll tune in for more of my videos!

@@ProCoderIO very good stuff here seriously. Thanks for the detailed response. Im a full stack developer but a deep data engineer and architect w heavy RDBMS background... I guess I personally at these persistence layers at being allot more complex vs leveraging the RDBMS directly. As to where others might feel it's easier the other way.