Nested @MappedCollection is not loaded correctly, unless it is a collection

[bent-lorentzen]

This problem was introduced in spring-data-jdbc version 3.2.0 It is still present in version 3.2.6 and 3.3.0.
It works correctly for versions 3.1.x

data class Booking(
    @Id
    val id: Long = 0,
    @MappedCollection(idColumn = "booking_id")
    val leg: Leg,
)

data class Leg(
    @Id
    val id: Long = 0,
    @MappedCollection(idColumn = "leg_id")
    val payments: Set<Payment> = emptySet(),
)

data class Payment(
    @Id
    val id: Long = 0,
)

@SpringBootApplication
class ApplicationTest

fun main(args: Array<String>) {
    SpringApplicationBuilder().run(*args)
}

@Repository
interface BookingRepository : CrudRepository<Booking, Long>

@ExtendWith(SpringExtension::class)
@SpringBootTest(classes = [ApplicationTest::class], webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class BookingRepositoryTest {

    @Autowired
    lateinit var bookingRepository: BookingRepository

    @Test
    fun `insert successfully inserts a booking in the DB`() {
        val booking =
            Booking(
                id = 0,
                leg = Leg(
                    id = 0,
                    payments = setOf(
                        Payment(id = 0)
                    )
                ),
            )

        bookingRepository.save(booking)
        val bookingFromFind = bookingRepository.findByIdOrNull(1L)!!

        bookingFromFind.leg.payments.size shouldBe 1
    }
}

In this example the booking from the find operation has an empty set for payments. and the test fails. The test completes if spring-boot-starter-data-jdbc is dowgraded to 3.1.12 or val leg: Leg is changed to val leg: Set

[vpmuli]

Why are you using @MappedCollection for val leg: Leg? Is this some way of using @MappedCollection I'm not aware of? I don't use any annotation for 1:1 relations in Java.

Your issue might be related to my issue #1802. The table structures and the versions that work and don't work are the same.

[bent-lorentzen]

@vpmuli Whether the relation is 1:1 or 1:N you only really need it to specify the foreign key name, in my case booking_id as opposed to the default booking.
But I think you might be right about the relation to your issue. I erroneously thought the error was caused by my use of uuid primary keys because my tests worked fine when I changed to a numeric primary key. However when I changed the sequences of the numeric primary key to start at 10, 100 and 1000 to make sure no table had matching primary keys they failed. This lead me to the conclusion that the wrong key was used for the relation somehow.

[schauder]

This seems indeed to be a duplicate of #1802. There is a PR and a matching snapshot available. Please give that a try.

If this does not resolve the issue, please let us know. Otherwise the issue will get closed.

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.