Migrating from (Spring Data) JPA to Spring Data JDBC by Jens Schauder @ Spring I/O 2024

Spring I/O 2024 - 30-31 May, Barcelona
Slides: 2024.springio....
A long long time ago in a city far away Jens Schauder started coding on a desktop calculator programmable in assembly. Over 30 years later, after almost 20 years as a consultant working mostly with huge enterprises, he joined the Spring Data Team. Here he works mainly on the “JPA” and “JDBC” modules and tells about it at conferences or helps other developers on StackOverflow. In his spare time he spends time running, bouldering, playing games, torturing himself with Freeletics. And eventually he will write a book about Spring Data JDBC.

[@jesprotech]

I can understand why some people would be wandering off to another session just by reading the title and indeed: "why would anyone spend their time migrating from JPA to JDBC?". It contradicts the whole idea of having created JPA in the first place! But I think Jens explain well why this could be a possibility. Great work!

[@michachlebikpiotrowski7713]

Based on my experience - for simple pet-projects, or greenfield microservice-style that would work perfectly. For the long-developed humongous monoliths, it's just impossible to introduce. It's not just a code/persistence layer change, but also a mental switch from anemic model to richer model (in DDD style) plus teaching a lot of people what aggregates, bounded contexts or ACLs are. And I know that the author admits that it's a lot of work, but in general - for big monoliths, it would be time better spend introducing strangler pattern, and just eventually migrating to microservices.

[@soheiljahangirie2477]

That was a great presentation. learned a lot

[@walterkivindu1470]

I have just watched the video but I don't agree with his mapping between Shipment and Item domain model. I don't know you can achieve One--to-Many entity relationship between Shipment and Item, such that a shipment can have many items, with that mapping.

[@hardcorecode]

JDBC have no support for composite keys or embeddables... so how is JPA to JDBC migration going to work?

[@sonayyalim]

It does have support for embeddables. Not sure about composite keys, there is a way I imagine it could be done but can't guarantee it will be as smooth as hibernate does.

[@hardcorecode]

@@sonayyalim No support for simple composite keys I checked!

[@HeyHoLetsGo32]

Composite keys are almost a code smell to me. They introduce business logic, and that should be part of the service layer. Technical IDs should totally suffice, and if you can't ensure some stuff from service layer for some reason, there is still an optioin of introducing unique constraints, for example. Ever tried to "foreign key reference" something that has a composite key? Becomes messy quickly.

[@hardcorecode]

@@HeyHoLetsGo32 completely disagree, nevertheless I should have the option to choose. yes, I have tried to foreign key reference a composite key. it was trivial with JPA!

[@HeyHoLetsGo32]

@@hardcorecode well you most certainly can choose jpa, no one deprecates it. Just from experience with large projects, „over-engineering“ most certainly creates hard to understand code over time. With fluctuations and „fresh“ devs every now and then, less magic tends to „work out“ nicer. But of course, if you have devs well trained in JPA, and will have in the future, it’s a viable option. My main pain point of JPA are the mutable entity classes anyway.

[@Mig440]

Keep your @java annotations away from MY domain model please and please don't infect my domain model with persistence concerns.

[@roman-proshin]

That's a big step forward JDBC does comparing to JPA: entities are now real objects, not magical proxies created by Hibernate. And there is another huge advantage not mentioned in the video: entities can now be immutable! Which is hardly achievable with JPA.

[@Mig440]

@@roman-proshin That is nice indeed, it would just be nice if you could programmatically separate the mapping logic from the entity type and not having to mix the two. I would probably be on the cautious side and choose to separate domain entities from persistence entities since they each serve different purposes. That keeps the annotations away and having to take on a dependency to Spring JDBC inside the core domain.

[@roman-proshin]

@@Mig440 yes, I definitely agree: it’s a definitive solution when domain classes have no “database” details at all. However, sometimes compromises are an unavoidable evil 🤷‍♂️ As otherwise a converter for every “entity - DB mapping” is required.

[@Mig440]

@@roman-proshin Sure but then your are explicitly tying YOUR domain with that of Spring JDBC. That can be OK, but then you are expressing a willingness to follow and always be compliant with whatever spring JDBC decides to do in all future iterations. If you are prepared for such effort, that is fine, but I think creating mappers between independent domain objects and persistence objects is a small price to pay for independence. I like to not mix the two if I can help it, but for the regular CRUD apps most are building you are just putting a fancy dressing on SQL anyhow. In fact if that is all you do, why are you then not using something much more simple than a whole web tech stack on top. You might aswell just use postGREST then; no need for a separate web application tier.

[@abccbaandy]

@@roman-proshin Agree, never understand why hibernate do so many magic in default. Just google "LazyInitializationException", you will find you are not the only one who get fucked by hibernate. But JPA concept is fine though.

[@NeerajKumar-ej8yo]

I am not going to migrate to Spring JDBC, even in new projects I am using JPA ;)

[@AgroTuna]

I migrated a medium sized project to spring data jdbc and was impressed by how straightforward it was. Sure there were some things that had to be changed, ran into a few footguns along the way, but in the end it simplified the code and opened my eyes to all of the "magic" that was happening behind the scenes in the JPA implementation.

[@xmicore]

simply schauderhaft

[@Mihey77]

Spring Data JDBC has a lot of limitations, which are not explicitly documented, e.g. no derived delete clauses. But the most excruciating part is deleting and inserting child entities on updates, since SD JDBC is unable to track what changed and what did not. This all seemed fine when the project just started, but what I see through these years is that the development speed has slowed down and there aren't many improvements lately.

[@pierrelaurensflorez2273]

I haven't watched the video yet, but my first question is.... why would I migrate from JPA to JDBC?

[@AntonArhipov]

And that's the question Jens asks from the audience right in the beginning :)

[@zombi1034]

Most likely if you encounter problems with your JPA implementation which you (think you) can’t solve with JPA.

[@walterkivindu1470]

For speed and reduce memory footprint

[@HeyHoLetsGo32]

For me, the main reason is that now I can annotate records with @Table. No need for mutability with a no-args constructor and setters as JPA requires. Takes away a whole level of mapping for me.