-
Notifications
You must be signed in to change notification settings - Fork 349
Home
The idea behind Spring Data JDBC is to provide an alternative for users who for one reason or the other don’t want to use JPA but still want to use a relational database and the Spring Data abstraction.
Spring Data JDBC does not intend to be a complete ORM but instead provides a structure for the persistence layer of your application where you can define the details using plain SQL and Java code or third party libraries like MyBatis or JOOQ
Note that for all stated problems there are ways to solve them using JPA. But at some point, one puts more work into working around the framework, then working with the framework at which one might want to consider an alternative.
This article describes a couple thing one should do to one’s domain model in order to get the behavior out of Hibernate.
The huge amount of StackOverflow questions regarding NonUniqueObjectException or LazyInitializationException indicates that many developers have a hard time understanding the basics of how Hibernate works. While many probably have similar problems with SQL or JDBC concepts like say joins there is an important difference. The chances that you use a join in a way that looks like it’s working for some time and then breaks when some other change somewhere in the application is introduced is slim. Also, when using JPA one still has to understand SQL anyway.
While the automatic detection of changed enties is nice in many cases. In the cases where it isn’t it is hard to control what get’s persisted and what not.
To avoid conflicts with the original database operation that fires the entity lifecycle event (which is still in progress) callback methods should not call EntityManager or Query methods and should not access any other entity objects.
While one can always fall back on using SQL, it is not feasible to customize just a part of the package, while still using parts orthogonal to that feature. For example one can not easily and precisely control the SQL statement used to updated an entity, without also loosing caching, dirty tracking and cascading.
Good support for a Domain Driven Design approach to software design. Relevant abstractions like Repository and Aggregate and AggregateRoot should be easy to support in a natural way.
Early first version. We need all the input we can get to arrive at a design that supports many use cases. Therefore we should thrive to get something usable out in the hands of the users ASAP.
Encourage good design by making the right choices the easy ones.
Be incrementally customizable, i.e. avoid situations where one has to do either something one doesn’t like or don’t use Spring Data JDBC at all.
Spring Data JDBC is not intended as a drop in replacement for JPA or similar ORMs. Especially it won’t provide the following features in order to limit complexity.
Dirty Tracking: Dirty tracking requires that entities are somehow controlled by Spring Data JDBC which introduces a complexity we want to avoid. This means that by default it has to assume it doesn’t know what the current state of the database is compared to the current state of an aggregate in memory.
Caching: Caching should not be implemented as part of Spring Data JDBC. Instead repositories should allow to integrate with existing caching solutions.
It is assumed that the table for the referenced enity contains the foreign key column.
Current choice: Everything reachable is part of the aggregate
Reason: easy to implement