Idk, I for one prefer hibernate’s, magic strings(@query). I just can’t imagine a SQL query taking up a whole page/file. In my application I have to write hundreds of long sql queries. I do agree that they may be hard to maintain, but when I write magic strings in a reasonably sized repository, I find it pretty easy to maintain.
Jesus Christ, we have SQL, why are people so obsessed to complicate things so much. They literally created a thing that replicates SQL when we can just use SQL and map the result to a class
I think this was a great talk, but I think the framing of it as a battle between J00Q and JPA did not do him any favors. I think people would have been more receptive if he would have framed it as “Hey did you know JOOQ could do X?”, people could then draw their own conclusions
What battle are you referring to? The talk explains how jOOQ works and in which scenarios it may be a better fit. Please tell me your thoughts so I can improve my talk. Thanks
@@simonmartinelli First, as I mentioned I really enjoyed this talk. You highlighted some great usages of JOOQ, which is a cool technology. However, the "tone" of the talk, came off as being a shot at JPA. Some of it is not your fault though, it's just a sensitive topic to some (for some reason 🤣)
It is better only on the paper and for small or pet projects. When you have large project you will have to spend too much time for maintaining and writing tests not to miss something on the repository layer, because after couple of years you will not be sure that when you add something in one place other won't be broken, same as in mybatis. JPA\Hibernate is more predictable and well stande for long distance. If you need something tricky just use native queries, that's all. Really don't recommend JOOQ, MyBatis or something similar if you are not just playing with pet project.
Maintaining JPA entities relationships are very hard and you don't know if you fetch one entity and it will also fetch dependent entities which we don't want. SQL like syntax will always be good. Love JOOQ.
@@praveens2272 It is not hard if you use tool correct, all possible cases are 100 times discussed and all solutions\workarounds provided. But when using tools like JOOQ you'l never know what will fail\broke in runtime on production in next release.
@@ilyaivanov3365 as an example you have lots of entities and join queries between them, and map result to different DTO's, after some time you add new field, and can easily miss new field at some place, because you forgot to add this new field to some query. This mistake will be found only during runtime. Due to that you have to write 10500 tests for CRUD operations, and I would say for everything in data layer. At the end you will be writing more tests other then useful code. Same for field deletion, and especially for any deletion, you can get constraint violation for child, dependendent entities only at runtime. JPA\Hibernate manages this more easy, etc. I'm not saying it is impossible to leave(manage) with that, but main point is not to make persistent layer pain in the ass.
@@alexandr7686 About addition of new field - you should be fine. Mapping to DTOs does not blow up if query result has more fields than your DTO. So if your code worked fine without that new field it will continue to work. About the deletion of a field. If it was in use it will break things certainly. But jooq should be used with generated schema classes, you have to regenerate them whenever you do a db schema change. This will update your pojos removing the field and you get compilation error where you have referenced it. If it was never referenced - you are good, no code changes needed. How would JPA/Hibernate handle the field deletion?
That... is a lot of effort for something you could do in a few dozen lines with Spring Data JDBC / Spring Data R2DBC. Even if you consider JPA to be evil, which is fair enough, reverting to slightly glorified SQL is a vast overkill. CRUD is not interesting. Explicitly writing Java code for CRUD is wasted effort, and that code is incredibly fragile. I have used JOOQ in production, and I would never do it again.
You can't do arbitrary joins with Spring Data JDBC. Of course you can hardcode SQL within @Query annotations, but a) this throws away all sorting, paging, criteria etc features of Data b) the queries are static. So your either have to copy-paste gazillion repository methods for every permutation of query criteria or fall back to jdbcTemplate and concatenation SQL strings by hand. All leading to maintenance hell in no time. I have not used JOOQ but the idea of programmatically building query is looking nice just for the case I have described.
Got burned once to many. And just to be clear. Conceptually I prefer the model of Maven over gradle. But the latter actually does compile avoidance. And understands dependencies. Maybe the maven has improved since the last time I used it, maybe not. Will leave it to someone else to play with it.
Thanks for the great session.
Thank you!😁
Do any of you suggest implementing JOOQ to a project with Hibernate already implemented? Or is it more like a migration from Hibernate to JOOQ?
Was waiting for this
JOOQ looks really nice. I hope I'll have a chance to try it at work :)
Idk, I for one prefer hibernate’s, magic strings(@query). I just can’t imagine a SQL query taking up a whole page/file. In my application I have to write hundreds of long sql queries. I do agree that they may be hard to maintain, but when I write magic strings in a reasonably sized repository, I find it pretty easy to maintain.
Jesus Christ, we have SQL, why are people so obsessed to complicate things so much. They literally created a thing that replicates SQL when we can just use SQL and map the result to a class
I think this was a great talk, but I think the framing of it as a battle between J00Q and JPA did not do him any favors.
I think people would have been more receptive if he would have framed it as “Hey did you know JOOQ could do X?”, people could then draw their own conclusions
What battle are you referring to? The talk explains how jOOQ works and in which scenarios it may be a better fit.
Please tell me your thoughts so I can improve my talk. Thanks
@@simonmartinelli First, as I mentioned I really enjoyed this talk. You highlighted some great usages of JOOQ, which is a cool technology. However, the "tone" of the talk, came off as being a shot at JPA. Some of it is not your fault though, it's just a sensitive topic to some (for some reason 🤣)
It is better only on the paper and for small or pet projects. When you have large project you will have to spend too much time for maintaining and writing tests not to miss something on the repository layer, because after couple of years you will not be sure that when you add something in one place other won't be broken, same as in mybatis. JPA\Hibernate is more predictable and well stande for long distance. If you need something tricky just use native queries, that's all. Really don't recommend JOOQ, MyBatis or something similar if you are not just playing with pet project.
Maintaining JPA entities relationships are very hard and you don't know if you fetch one entity and it will also fetch dependent entities which we don't want. SQL like syntax will always be good. Love JOOQ.
@@praveens2272 It is not hard if you use tool correct, all possible cases are 100 times discussed and all solutions\workarounds provided. But when using tools like JOOQ you'l never know what will fail\broke in runtime on production in next release.
@@alexandr7686 Can you elaborate more on 'you'l never know what will fail\broke in runtime on production in next release'? What makes you think so?
@@ilyaivanov3365 as an example you have lots of entities and join queries between them, and map result to different DTO's, after some time you add new field, and can easily miss new field at some place, because you forgot to add this new field to some query. This mistake will be found only during runtime. Due to that you have to write 10500 tests for CRUD operations, and I would say for everything in data layer. At the end you will be writing more tests other then useful code. Same for field deletion, and especially for any deletion, you can get constraint violation for child, dependendent entities only at runtime. JPA\Hibernate manages this more easy, etc. I'm not saying it is impossible to leave(manage) with that, but main point is not to make persistent layer pain in the ass.
@@alexandr7686
About addition of new field - you should be fine. Mapping to DTOs does not blow up if query result has more fields than your DTO. So if your code worked fine without that new field it will continue to work.
About the deletion of a field. If it was in use it will break things certainly. But jooq should be used with generated schema classes, you have to regenerate them whenever you do a db schema change. This will update your pojos removing the field and you get compilation error where you have referenced it. If it was never referenced - you are good, no code changes needed. How would JPA/Hibernate handle the field deletion?
That... is a lot of effort for something you could do in a few dozen lines with Spring Data JDBC / Spring Data R2DBC. Even if you consider JPA to be evil, which is fair enough, reverting to slightly glorified SQL is a vast overkill. CRUD is not interesting. Explicitly writing Java code for CRUD is wasted effort, and that code is incredibly fragile. I have used JOOQ in production, and I would never do it again.
You can't do arbitrary joins with Spring Data JDBC. Of course you can hardcode SQL within @Query annotations, but a) this throws away all sorting, paging, criteria etc features of Data b) the queries are static. So your either have to copy-paste gazillion repository methods for every permutation of query criteria or fall back to jdbcTemplate and concatenation SQL strings by hand. All leading to maintenance hell in no time.
I have not used JOOQ but the idea of programmatically building query is looking nice just for the case I have described.
Do you really need JOOQ?
Thanks but no thanks.
Maven ... lost me there.
You dismiss the entire talk because he do not use your favorite build tool? That has not logic and is neither a constructive critique.
Got burned once to many. And just to be clear. Conceptually I prefer the model of Maven over gradle. But the latter actually does compile avoidance. And understands dependencies. Maybe the maven has improved since the last time I used it, maybe not. Will leave it to someone else to play with it.
You can use jooq easily with gradle