Experience with Spring Data JDBC?

[Adam Zell]

I have read a little about https://spring.io/projects/spring-data-jdbc .  The project simplifies the JPA implementation and targets domain driven design (DDD) architectures.  Has anyone used it, and if so, how does it compare to jOOQ?

https://docs.spring.io/spring-data/jdbc/docs/2.0.1.RELEASE/reference/html/#jdbc.entity-persistence.types has limited support for hydrating relations, somewhat similar to jOOQ:

The handling of referenced entities is limited. This is based on the idea of aggregate roots as described above. If you reference another entity, that entity is, by definition, part of your aggregate. So, if you remove the reference, the previously referenced entity gets deleted. This also means references are 1-1 or 1-n, but not n-1 or n-m.

If you have n-1 or n-m references, you are, by definition, dealing with two separate aggregates. References between those should be encoded as simple id values, which should map properly with Spring Data JDBC.

[Lukas Eder]

Hi Adam,

A comparison between Spring Data XYZ APIs and jOOQ necessarily leads to a comparison between DDD and relational algebra+, where the + means that SQL is an "algebra" that enhances the relational one in many non-relational ways.

Both modelling frameworks are very opinionated, although, contrary to what one might believe when reverse engineering DDD from opinionated implementations like Spring Data, DDD is not really about data modelling. It is more about problem modelling. The way I understand it, it would be perfectly possible to implement an ubiquitous language and clearly bounded context of a system without being too opinionated about persistence strategies and data modelling within a domain. Here are some resources that could be used to back my claim:

- https://softwareengineering.stackexchange.com/q/305061/9411

- https://softwareengineering.stackexchange.com/q/123023/9411

In my own opinion, the relational model is the best way to model data that we have had in the last 50 years. It solved a lot of problems that pre-date the relational model (e.g. the ones of the hierarchical and networked models), and no attempt to tackle modelling after the relational model came even close to it. JPA is pretty much a Java client implementation of the relational model, with a relatively humble way of implementing the algebra (JPQL compared to SQL). jOOQ models the algebra without being too opinionated about the modelling and the persistence.

Spring Data builds on top of a variety of "protocols" (e.g. JDBC, JPA, etc.) to implement something entirely different, a consolidated view of how to deal with aggregates on top of pretty much any data store. You could build a Spring Data jOOQ implementation that uses jOOQ behind the scenes to implement loading aggregates.

Of course, most people who use Spring Data XYZ use it mainly because it simplifies a few repetitive tasks, not because they actually believe in the paradigms assumed by Spring Data. Just like they use JPA for that very reason, and given how popular jOOQ's org.jooq.DAO are, they even do that with jOOQ as well.

Unless you "just" want some convenience (as shown above), you're not really comparing Spring Data JDBC and jOOQ specifically. You're going to compare two architectural approaches and paradigms. In a "pure" Spring Data world, you *want* to work with the way they think about aggregates. In a "pure" jOOQ world, you *want* to embrace relational algebra, set theory, etc. to interact with your data.

Hope this helps

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/23390dcb-2500-4612-b5fe-5261e36036f7o%40googlegroups.com.