We now provide a KProperty extension leveraging KProperty references to express a property path. Using Kotlin property references (such as Author::name that translates to `book` or Book::author / Author.name translating to `book.author`) is refactoring-safe as the property expressions are part of the Kotlin language. We render KPropertyPath using the same semantics as our PropertyPath so that store-specific modules can leverage either property paths or accept KProperty directly.
In contrast to the previous implementation, KPropertyPath is private and the rendering function was renamed to toDotPath to align with PropertyPath.toDotPath.
Related ticket: DATAMONGO-2138 (spring-projects/spring-data-mongodb#3515)
Original Pull Request: #478Closes: #2250
Allow obtaining an EvaluationContext with a reduced set of extensions that are required for ExpressionDependencies instead of initializing all extensions.
CrudRepository and ReactiveCrudRepository now expose a deleteAllById(Iterable<ID>) method to delete multiple entities by their Id.
Original pull request: #476.
We now report the first generic parameter for collection-like types to use the behavior that was previously in place. We will address the issues resulting of the intent to report the correct component type of Iterable in a later change.
Instead of using the first generic type parameter of a parameterized type as Map component type, we now explicitly lookup the super type's Map-specific generics configuration and use its first generic type parameter. The same for collection like types falling back to the parameter type bound to Iterable.
This avoids module cycles when it is used from a template.
The old version is still there, deprecated and delegates to the new version.
Original pull request: #472.
We're now awaiting completion of the underlying Publisher to ensure all completion tasks have finished before continuing with the execution. This is to avoid completion running in parallel to the actual coroutine as not awaiting completion can result in race conditions.
Fixes the problem of the "Using filters" link jumping to the top of
the document. There was another of these ("Configuration") later in
the document, and this commit fixes that one, too.
Original pull request: #470.
We now consider reactive wrapper types in all areas that previously relied on QueryExecutionConverters to handle reactive type information correctly. Specifically, we call supports(…) and perform type unwrapping to ensure to detect the correct return type.
Reviewed visibility modifiers manually introduced constructors previously provided by Lombok. Also some nullability constraints have been accidentally changed by that.
We now perform type unwrapping and introspection for reactive types for method return types and method arguments after decoupling QueryExecutionConverters.supports(…) from ReactiveWrapperConverters.
We now support nullable wrappers for projection interfaces. Getters are inspected whether their return type is a supported nullable wrapper. If so, then the value can be wrapped into that type. Null values default in that case to their corresponding empty wrapper representation.
Original Pull Request: #459
Nullable wrappers such as Java 8 Optional, Guava Optional, Scala Option and Vavr Option are now handled in NullableWrapperConverters and are no longer coupled to QueryExecutionConverters so that this functionality can be reused.
Original Pull Request: #459
ReactiveWrappers doesn't belong in there in the first place so we're removing ReactiveWrappers support from QueryExecutionConverters so ReactiveWrappers is used from parts that need to be reactive-aware.
Original Pull Request: #459
Mark Paluch
Michael Simons
Jens Schauder
Vedran Pavic
Mark Paluch
Oliver Drotbohm
John Blum
Alec Landow
Jay Bryant
Christoph Strobl
Henning Rohlfs
Wim Deblauwe