Fix: add support for Kotlin data classes without PersistenceConstructor

[dirkluijk]

When using a Kotlin data class without PersistenceConstructor, it picks the incorrect internal Kotlin constructor which leads to errors.

This improvement uses PreferredConstructorDiscoverer from Spring Data Common to find the preferred constructor, which supports Kotlin (source).

[lpandzic]

Tests are failing...

[dirkluijk]

Oops, I only tested it in my own project. I'll check it.

[dirkluijk]

Okay, so this was a bit of a puzzle.

This is how Spring Data resolves constructors:

- If there is a single constructor, it is used.
- If there are multiple constructors and exactly one is annotated with @PersistenceConstructor, it is used.
- If there’s a no-argument constructor, it is used. Other constructors will be ignored.

(taken from reference docs)

With this logic now in place, there were two problems with NoArgsEntity and QueryDSL:

1. first of all, it now wants to use the no-args constructor new NoArgsEntity(). However, this constructor is package-private and thus not detectable by QueryDQL. Making this constructor public fixed all tests in this project (except for one, see next comment).

2. There was one other test failing: QuerydslJdbcRepositoryTest.shouldSupportMultipleConstructors(). For two reasons. First of all, the constructorExpression for a no-arg entityProjection creates an invalid query. It seems QueryDSLs AbstractSQLQuery does not work very well with no-arg constructors. And that makes sense, because the no-arg thingy in Spring Data is probably meant to support JPA, which does not use the AbstractSQLQuery in QueryDSL (I think?). Secondly, looking at that test, it expects all arguments to be set and that the constructor with all the arguments should be used. According to Spring Data JDBC, we should add the @PersistenceConstructor in that case. So that's what I did, and it fixed that test.

3. Because of the @PersistenceConstructor, the no-args constructor doesn't have to be public anymore.

[lpandzic]

Tests pass and I agree with your reasoning and conclusion. I don't remember exactly why I implemented it the way I did other than for no arg entities support - I assume it's lack of time to research the underlying logic at the time.

[dirkluijk]

Cool, thanks! This allows me to use plain data classes in Kotlin without @PersistenceConstructor, which makes it a little bit cleaner. :)

I might have another contribution, I will look into it anytime soon.

[lpandzic]

FYI, 6.1.1 has been released.

[lpandzic]

Cool, thanks! This allows me to use plain data classes in Kotlin without @PersistenceConstructor, which makes it a little bit cleaner. :)

I might have another contribution, I will look into it anytime soon.

Thanks for contributing. :)