I want to give a bit more context here, in case my response yesterday was a bit too simplistic:
Repositories are a *very* opinionated minefield. Just look at what is happening now that Jakarta Data adds "repositories", but does it differently from Spring Data: https://x.com/maciejwalkowiak/status/1846838343973126187 There is absolutely no consensus over what these made-up things that aren't real should be or shouldn't be. Proponents of architectural styles continue to block each other on Twitter, based on heated debates: https://x.com/maciejwalkowiak/status/1775596270716883019 This is the very reason why I have always regretted adding DAOs to jOOQ as per the linked article from yesterday: https://blog.jooq.org/to-dao-or-not-to-dao These "convenient" things are bottomless pits that make everyone equally unhappy, because they never suffice. Sure, they do simplify some very boring CRUD tasks, and sure, there are tons of folks who simply don't care about anything other than making their very simple CRUD app work as quickly as possible. And that's fine. That's why Spring Data adds value, and so will Jakarta Data. Btw, ouside of the devrel bubble, I personally doubt that many Spring Data users really care the least bit about DDD. They just want a path of least resistance, so IMO Jakarta Data was reasonably pragmatic here by not following DDD at all. Now, these two things are *frameworks*, not libraries. They are allowed to be highly opinionated because they will infiltrate your application's every aspect. They will make you read 1741 page bibles and documentation and manifestos, so you can design your application *exactly* like some luminary envisioned (or not, and then endlessly bikeshed the True Way Of Things. Just look at REST, which is another such minefield). jOOQ is a simple library. jOOQ has a very simple goal: Better integrate SQL with Java (or Kotlin, Scala). SQL is quite straightforward and extremely powerful. Every standard or vendor specific SQL goodie is a great candidate for support in jOOQ. Bottomless architectural pits are not, because they will distract energy from very useful SQL-in-Java-integration towards endless debates about what "simplification" of SQL could be added to the DAO. Pagination is one such thing. It looks reasonable to add to a Repository / DAO, but then: 1. It would have to be added to *all* fetch methods (jOOQ generates these, they're not hand written and proxied, so this is one reason why DAO feature additions are not so practical in jOOQ) 2. We would have to start a conversation about alternative ways to write fetch methods because: a) We can only filter on one column, currently (I shiver at the thought of Spring Data's method name convention queries!) b) We cannot sort, either! c) We cannot group, aggregate, or project expressions! And the answer to all of the above is always: Why not just write a query? If jOOQ is strong at one thing, then it's exactly that: Writing queries. If queries are so painful, then there's still Spring Data, or since recently, Jakarta Data to do the boring CRUD stuff. Why should jOOQ compete with them on this topic? Now, sure, pagination can become repetitive, but then, is Spring's Pageable API really good enough? 1. It can do offset pagination, but can it do keyset pagination as well? 2. Can it avoid extra roundtrips as suggested here, and interact with *arbitrary* queries? https://blog.jooq.org/calculating-pagination-metadata-without-extra-roundtrips-in-sql 3. Can it embed expressions in pagination (even subqueries)? 4. Can it do fancy pagination, such as FETCH NEXT n PERCENT ONLY or FETCH NEXT n ROWS WITH TIES? I don't think it is a good enough abstraction for a library like jOOQ. I can imagine it is good enough for simple CRUD apps where every screen is paginated without giving the topic more thought. Because often, pagination is a smell, in my opinion: https://blog.jooq.org/why-most-programmers-get-pagination-wrong I have accepted jOOQ's fate of never being able to deprecate / remove the DAO API again: https://github.com/jOOQ/jOOQ/issues/5984 But I do believe that jOOQ really shouldn't invest much more into this DAO API. If users want Spring Data features, why not just use Spring Data. I hope this makes sense? Lukas On Tuesday, October 22, 2024 at 10:06:44 AM UTC+2 Lukas Eder wrote: I don't think we should invest a ton of time in weird (and very incomplete) querying utilities that solve problems that are very easy to solve with... a query! See also: https://blog.jooq.org/to-dao-or-not-to-dao Of course, there's a very slight chance of the community convincing me otherwise (e.g. with an issue on github and with 372 upvotes on the issue), always keeping in mind that queries are extremely powerful, and "repositories" / "DAOs" are very dumb -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/7dd70899-6d42-48eb-aff0-3f988284ad66n%40googlegroups.com.
