Mark Paluch

Alright, we're on the same page now. Care to remove the commented-out XML bits so I can merge the PR without polishing it? Happy to keep the explanatory comment though.

I'd vote to deprecate that method altogether as it retains the settings from the `Order` in a weird way for a collection of new property names.

This change was introduced in https://github.com/spring-projects/spring-data-envers/pull/195. I agree that this isn't ideal, it would sense to lookup the `@RevisionTimestamp` property and use its name.

Can you provide us with a bit more context along with a bit of code how you intend to use `Specification` so we get a better understanding?

I filed a ticket to update our docs. By default, the mapping layer does not define a root object as we need to construct column and table names before even...

Care to include the full stack trace?

`CustomerDetailsPair` uses overridden properties. That's not supported as Kotlin creates two properties without being able to set reliably both. Without the `override` keyword, I'm not able to reproduce the issue.

You do not use the property that you think you're using. The property is declared with the name `isActive` while your query method uses a property named `active`. Kotlin renders...

Is there some Kotlin documentation that explains `isFoo` to `Foo` property name rewriting?

We are currently in the process of refactoring our converters with #1618. The recent changes have cleaned up our code by unifying several approaches into a single one. Looking forward,...