Care to see as well how strategies can be implemented with spring batch. For one thing using lazy loading and batch size for the entities in the first level cache seems pretty handy to me..
I use hibernate to persists data and use it to read data back where i need to fetch by id to update. Other than that all views are Sql Coded in mybatis. I like the approach that gives me full control on sql when I have multiple joins. I dont get compile time type safety in mybatis, but my tests help to remove any errors that might arise in runtime
100%. If you truly have the sprawling complexity where Hibernate makes sense, then by all means use spring data jpa. But for most of us, there’s JavaOOQ, MyBatis, Spring Data JDBC, etc., all of which cost less in terms of performance and give us as good or better simplicity upfront. The nice thing about Spring Data is that the boring stuff looks basically the same if you ever need to move to JPA. You’d only have to worry about the complexity of entities and queries
ugh, lost my reply. Short version. this is opinion and theory. I have decades of hands on real world experience that says otherwise. I use JPA with small and large apps. Works great. It is performant. But I dont treat it like an Object Database. The issue is that people dont learn to use the tools wisely and blame the tool. We swtiched from JPA to JDBC and it was not a minor change though still easier with Spring Data and we had flat models. It wasnt more peformant. the things you meantioned are options but ones MMV. there are trade offs
How would you import this project into a spring-boot project such that spring-boot doesnt demand that the classes in your JdbcApplication have to be defined as Beans?
You should consider jooq instead of jdbc. You wouldn't be getting "bad sql" errors at runtime like you got and it is also not using reflection, etc. and you are no longer limited to the crud operations that you are limited to here
if someone wants this, they can use ...i forget the name right now, but it can generate query models and it works with SPring Data and is true opensource.
the spring docs say (or use to) that for most apps reactive is mostly YAGNI and adds complexity. That is my experience over the decades. Code for maintenance. Optimize where needed.
I'd love to share this Josh but the comments about Hibernate are not accurate. I've done RDBMS without and with Hibernate for 30 years. I don't want to go back. That being said, where there are issues is when you have an existing db that is poorly designed. Recently I had to switch to Spring Data JDBC because of this. But only because Hibernate made some change that seems to cache data types and our db deployments are not consistent and so it would occasionally blow up queries.This is not Hibernate's fault.
No it shouldn't. You should be able to explain why you need Hibernate. Majority of time Hibernate is net negative when compared to JDBC. You end up with more code, and worse problems.
@@bariole that is theory or your experience. Spring Data JDBC is not just JDBC. If you do raw Hibernate, potentially. But ORMs exist to reduce the code you'd need to write without it. We just converted from Spring Data JPA to Spring Data JDBC. It was not less code. FWIR it was more. If we had not treated JPA as a table mapper, it for sure would have been.
@javasoccernut Experience. Properly written Hibernate results in more code, as you need a lot of code to handle level 1 cache issues and navigate the idiosyncrasies of the context-dependent grammar of JPA/Hibernate mapping. You also need to enforce a bunch of rules, such as updates from the root, which can be challenging to explain to users who "just need SQL," etc. For the majority of people, merges seem to work like "magic." Additionally, if the application is written by relatively inexperienced individuals (which is why you are here fixing it), it will likely contain more queries than necessary, regardless of whether they are SQL or HQL. However, it is much easier to clean up directly mapped code, such as ActiveRecord, JDBC, JdbcTemplate, or MyBatis. In my 20 years of experience, I have encountered maybe five projects where the ObjectMapper pattern implementation made sense, primarily due to practical reasons such as "I need to generate SQL for multiple backends," "I need optimistic locking," or "I am using JHipster, and that is what it uses." Even Martin Fowler, the person who invented the whole pattern, stated back in 2012 that the way to fix ORMs is by keeping your model flat and in a direct one-to-one mapping with rows. Essentially, this involves fully ignoring relation mapping and relegating Hibernate's role to a "SQL generator." This approach is similar to what is presented here but without all the double-state management issues of ORMs. Most of the time, Hibernate/JPA/EclipseLink are more complex than the problems they are trying to solve.
Thanks, Josh. Software solutions design/architecture should always be guided by "Make it Simple" attitude in priority! You rock man
Care to see as well how strategies can be implemented with spring batch. For one thing using lazy loading and batch size for the entities in the first level cache seems pretty handy to me..
Please Josh do some tutorial about composed primary keys and this embededable thing. I think many devs are looking for it
I use hibernate to persists data and use it to read data back where i need to fetch by id to update. Other than that all views are Sql Coded in mybatis. I like the approach that gives me full control on sql when I have multiple joins. I dont get compile time type safety in mybatis, but my tests help to remove any errors that might arise in runtime
I tried to explain this to everyone, nobody paying attention, they are happy with hibernate complexity 😢
It isnt that complex. Spring Data JDBC has its own complexities. Trade offs.
100%. If you truly have the sprawling complexity where Hibernate makes sense, then by all means use spring data jpa. But for most of us, there’s JavaOOQ, MyBatis, Spring Data JDBC, etc., all of which cost less in terms of performance and give us as good or better simplicity upfront. The nice thing about Spring Data is that the boring stuff looks basically the same if you ever need to move to JPA. You’d only have to worry about the complexity of entities and queries
I wish we move away from hibernate but I don’t think that’s going to happen any time soon
ugh, lost my reply.
Short version. this is opinion and theory. I have decades of hands on real world experience that says otherwise.
I use JPA with small and large apps. Works great. It is performant. But I dont treat it like an Object Database.
The issue is that people dont learn to use the tools wisely and blame the tool.
We swtiched from JPA to JDBC and it was not a minor change though still easier with Spring Data and we had flat models. It wasnt more peformant.
the things you meantioned are options but ones MMV. there are trade offs
Thanks，Josh. What's is uao command?
Thanks for the demo.
Does data jdbc support composite primary keys and json fields?
no support for composite primary keys
What keyboard are you using? And keyboard switches?
How would you import this project into a spring-boot project such that spring-boot doesnt demand that the classes in your JdbcApplication have to be defined as Beans?
The Profile field is not embedded inside the Customer object; how is it possible to save both of them with one repository using spring data jdbc?
What about Mybatis? We are using it in my current position but I don't know to which extent can we mix both for repositories
Can you provide your schema somewhere so that we can easily follow your tutorial?
You should consider jooq instead of jdbc. You wouldn't be getting "bad sql" errors at runtime like you got and it is also not using reflection, etc. and you are no longer limited to the crud operations that you are limited to here
what are the Cons?
Cons are that it’s expensive as hell if you are not using an open source DB
if someone wants this, they can use ...i forget the name right now, but it can generate query models and it works with SPring Data and is true opensource.
Do you recommend that people use this and not use reactive drivers and all that anymore now that we have loom
the spring docs say (or use to) that for most apps reactive is mostly YAGNI and adds complexity.
That is my experience over the decades.
Code for maintenance. Optimize where needed.
Where is join cases?
What is mean repository?
21:00 if using chances in java , then do not use the default serilizer of java.
That was good, but why do you always write all the code in one file?
I wish spring boot data jdbc was earlier than hibernate ....
spring kafka teacher oi,
I'd love to share this Josh but the comments about Hibernate are not accurate.
I've done RDBMS without and with Hibernate for 30 years. I don't want to go back.
That being said, where there are issues is when you have an existing db that is poorly designed.
Recently I had to switch to Spring Data JDBC because of this. But only because Hibernate made some change that seems to cache data types and our db deployments are not consistent and so it would occasionally blow up queries.This is not Hibernate's fault.
Data JPA should still be the default for most medium to big apps. Using Data JDBC may be premature optimization.
You say "should". Care to explain that value judgement?
In my humble experience (3 decades) this is the case. YMMV.
No it shouldn't. You should be able to explain why you need Hibernate. Majority of time Hibernate is net negative when compared to JDBC. You end up with more code, and worse problems.
@@bariole that is theory or your experience. Spring Data JDBC is not just JDBC. If you do raw Hibernate, potentially. But ORMs exist to reduce the code you'd need to write without it. We just converted from Spring Data JPA to Spring Data JDBC. It was not less code. FWIR it was more. If we had not treated JPA as a table mapper, it for sure would have been.
@javasoccernut Experience. Properly written Hibernate results in more code, as you need a lot of code to handle level 1 cache issues and navigate the idiosyncrasies of the context-dependent grammar of JPA/Hibernate mapping. You also need to enforce a bunch of rules, such as updates from the root, which can be challenging to explain to users who "just need SQL," etc. For the majority of people, merges seem to work like "magic." Additionally, if the application is written by relatively inexperienced individuals (which is why you are here fixing it), it will likely contain more queries than necessary, regardless of whether they are SQL or HQL. However, it is much easier to clean up directly mapped code, such as ActiveRecord, JDBC, JdbcTemplate, or MyBatis.
In my 20 years of experience, I have encountered maybe five projects where the ObjectMapper pattern implementation made sense, primarily due to practical reasons such as "I need to generate SQL for multiple backends," "I need optimistic locking," or "I am using JHipster, and that is what it uses." Even Martin Fowler, the person who invented the whole pattern, stated back in 2012 that the way to fix ORMs is by keeping your model flat and in a direct one-to-one mapping with rows. Essentially, this involves fully ignoring relation mapping and relegating Hibernate's role to a "SQL generator." This approach is similar to what is presented here but without all the double-state management issues of ORMs. Most of the time, Hibernate/JPA/EclipseLink are more complex than the problems they are trying to solve.
19:36 cheating 😄
Nah, He reads yt commands!.
All those things that you explained will be in future automatically handled by AI