springDao generates @null instead of @Transactional

[Simon Martinelli]

Hi,

I just tried out springDao generation and it produces uncompilable code:

@null(readOnly = true)
@Override
public long count() {
return super.count();
}

Did I miss something?

Thanks, Simon

[Lukas Eder]

Hi Simon,

Thanks for your message. I can see how this can happen when you activate the <springDao/> flag, but not the <springAnnotations/> flag. Obviously a bug:

https://github.com/jOOQ/jOOQ/issues/17477

Best Regards,

Lukas

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/7ce626b3-6df2-4bd1-8131-6da439b0496an%40googlegroups.com.

[Simon Martinelli]

Hi Lukas,

I see. Thanks for creating the issue.

What’s the purpose of only having springAnnotations true?

[Lukas Eder]

One flag was there before the other.

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/70980132-D8E1-4754-91B2-B581BA854F2C%40gmail.com.

[Simon Martinelli]

I'm a bit confused.

To get the Spring DAOs I need to configure

<springAnnotations>true</springAnnotations>
<springDao>true</springDao>
<daos>true</daos>

Why? I mean if I don't set daos=true only the AbstractSpringDAOImpl would be generated.

I was assuming that daos and springDao (why is one in pluarl and one in singular) would not generate the same DAOs.

But it looks like springDao is a configuration for daos.

IMO springDaos (to make it consistent) should generate the daos without the need to add daos=true.

[Lukas Eder]

On Tue, Oct 22, 2024 at 9:42 AM Simon Martinelli <simon.ma...@gmail.com> wrote:

I'm a bit confused.

To get the Spring DAOs I need to configure

<springAnnotations>true</springAnnotations>
<springDao>true</springDao>
<daos>true</daos>

Why? I mean if I don't set daos=true only the AbstractSpringDAOImpl would be generated.

I was assuming that daos and springDao (why is one in pluarl and one in singular) would not generate the same DAOs.

The springDao flag as per the Javadoc and documentation in the XSD does:

"Generate an AbstractSpringDAOImpl as a base class for other DAO classes, containing @Transactional annotations, etc."

 

But it looks like springDao is a configuration for daos.

IMO springDaos (to make it consistent) should generate the daos without the need to add daos=true.

There's a non-zero (though not far beyond 1) percent chance that someone would want to generate *only* the AbstractSpringDAOImpl, no?

[Simon Martinelli]

Good point! That could be the case, yes. So it’s perfect as it is.

Another question:

It generates fetchRange, which is great. But most Spring Data users are used to having paging with a Pageable.

Could this be a useful addition? I know that this will bind it to Spring Data so maybe this must be a separate module?

https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/domain/Pageable.html

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO6-9RRPx87Qx9u2ouXUtPjP3N6e0%3DXTe7kA7BJXJj_Ubw%40mail.gmail.com.

[Lukas Eder]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/DDA67C8B-09D5-431E-888B-855414A28615%40gmail.com.

[Lukas Eder]

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

[Kian Farah]

Spot on!  The DAO/Repository debate highlights the inherent complexity of these patterns.  jOOQ's strength is direct SQL integration; diverting resources to emulate Spring Data features sounds  counterproductive to me. Thanks for the clear explanation.

--

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+...@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.