Jens Schauder

icon indicating a website link http://blog.schauderhaft.de icon indicating an email [email protected]

icon company Broadcom icon location Cottbus, Germany

Results 356 comments of Jens Schauder

Implicit join on one-to-many relations

duplicate of #592

withId is required for aggregate root when the referenced table has @Id [DATAJDBC-558]

Closing as this issue was resolved by something else.

Introduce support to compare two columns in `Criteria`

We already have a ticket for merging the `QueryMapper` classes: https://github.com/spring-projects/spring-data-relational/issues/1504

What should root.getJoins return after a root.get("x")?

Related issue in the EclipseLink issue tracker: https://bugs.eclipse.org/bugs/show_bug.cgi?id=413892

Tighten the spec on EntityManager.getReference(…) in error scenarios

> There will always be situations where it could happen that an object is not available anymore during lazy loading. True. But what percentage of the applications are prepared to...

method annotated with @Transactional(isolation = Isolation.READ_COMMITTED) returns uncommitted data

Please simplify the reproducer, so it can be run locally without all that Docker overhead. You shouldn't need a web application either. A simple integration test should do.

method annotated with @Transactional(isolation = Isolation.READ_COMMITTED) returns uncommitted data

The reproducer is broken. In the first example you call `Thread.start()` https://github.com/jvanheesch/spring-boot-isolation/blob/SpringBootTest/src/test/java/io/github/jvanheesch/ExampleIT.java#L15 In the second example you call `Thread.run()` https://github.com/jvanheesch/spring-boot-isolation/blob/SpringBootTest/src/test/java/io/github/jvanheesch/ExampleIT.java#L26 This does NOT start a new thread, but runs the...

method annotated with @Transactional(isolation = Isolation.READ_COMMITTED) returns uncommitted data

Ok, that is strange. I massaged the tests a little to use `CountDownLatch` for synchronization. And also added a test to demonstrate the behaviour with just JDBC, which behaves as...

SQL query not optimized when using Projection with a Specification (FetchableFluentQuery)

Related: https://github.com/spring-projects/spring-data-jpa/issues/1524

Native query projection with record

This **should** work if you define the proper `@SqlResultMapping`. Unfortunately it doesn't as I discovered when I tried to produce an example. Reproducer can be found here: https://github.com/schauder/issue-jpa-2757-sqlresultmapping I guess...