Spring Data JDBC is, by default I believe, backed by a full on ORM, that being Hibernate.
I'm open to different opinions on this, but I dislike Hibernate because of the complexity and the pains it causes when trying to do simple things. Hibernate, and Spring's use of it, is a leaky abstraction. When running into bugs, just trying to use a flow like, read sql row to POJO -> update POJO -> Save POJO to DB, using Spring JPA repository interfaces, I find myself needing to know about Hibernate internals, like the persistence context, how it relates with transactions, when objects are merged vs saved vs are they already in the persistence context or not? Plus Hibernate docs suck in my opinion.
One time we hit a bug in Hibernate. This was within the last two years, using a newer version of Spring Boot. We read a row from SQL in a transaction. Later in time, in a whole different Transaction, we read the same row. We read it with an annotation on the query method, "@LockType(PESSIMISTIC_WRITE)". We were using MSSQL and this sends table hints like "(updlock, rowlock, holdlock)". So essentially we wanted exclusive access to this row for the length of the transaction. But the data we were getting in the row didn't make any sense? We could see the sql query with the table hints hitting the sql server, but Hibernate was giving us a cached POJO!? If we "evicted" the pojo before we queried then it worked right. Again, this was at the very beginning of a fresh transaction. Wtf.
I'm open to different opinions on this, but I dislike Hibernate because of the complexity and the pains it causes when trying to do simple things. Hibernate, and Spring's use of it, is a leaky abstraction. When running into bugs, just trying to use a flow like, read sql row to POJO -> update POJO -> Save POJO to DB, using Spring JPA repository interfaces, I find myself needing to know about Hibernate internals, like the persistence context, how it relates with transactions, when objects are merged vs saved vs are they already in the persistence context or not? Plus Hibernate docs suck in my opinion.
One time we hit a bug in Hibernate. This was within the last two years, using a newer version of Spring Boot. We read a row from SQL in a transaction. Later in time, in a whole different Transaction, we read the same row. We read it with an annotation on the query method, "@LockType(PESSIMISTIC_WRITE)". We were using MSSQL and this sends table hints like "(updlock, rowlock, holdlock)". So essentially we wanted exclusive access to this row for the length of the transaction. But the data we were getting in the row didn't make any sense? We could see the sql query with the table hints hitting the sql server, but Hibernate was giving us a cached POJO!? If we "evicted" the pojo before we queried then it worked right. Again, this was at the very beginning of a fresh transaction. Wtf.