We now fetch mapping contexts from Iterable<MappingContext> later, when accessing PersistentEntities API to defer potential resolution when e.g. obtaining beans from a BeanFactory.
Closes#3310
If the collection type is not a store-native type, we no longer issue a warn log. Converters can be registered for List or Collection types and convert into a different, non-collection type while being a support converter instead of forcing a specific write type.
This is e.g. the case for MongoDB where a List of numbers is converted to the Vector type.
Closes#3306
>> There are no guarantees on the type, mutability, serializability, or thread-safety of the List returned
`Collector.toList()` doesn't guarantee mutability, then passing it to `Collections.reverse()` is not safe.
Signed-off-by: Yanming Zhou <zhouyanming@gmail.com>
Closes#3304
The ProxyHandlerMethodArgumentResolver now avoids matching multipart parameters annotated with @ModelAttribute. This allows multipart parameters to be handled by RequestParamMethodArgumentResolver which properly handles multipart arguments.
Also, the `@ProjectedPayload` annotation can now be used on parameters. This prepares for the upcoming removal of support for non-annotated projections.
Fixes#3258
Related tickets #2937
Original pull request: #3277
Signed-off-by: Chris Bono <chris.bono@broadcom.com>
The documentation now clarifies that entity might get loaded and therefore possibly OptimisticLockingFailureException might get thrown.
Closes#3280
Original pull request: #3281
Introduces a more convenient API to simplify the caller side especially for conditionals that want to determine whether a parameter name is present.
Closes#3088
Original pull request: #3272
Examples for limiting queries with and without a property argument are now better mixed.
This makes it more clear that limiting and filtering by property are orthogonal concerns.
Closes#3268
Original pull request #3269
This cleans up a couple of classes by removing unused imports.
Original pull request: #3240
Signed-off-by: Tran Ngoc Nhan <ngocnhan.tran1996@gmail.com>
We now use a refined strategy to cache RepositoryInformation and RepositoryComposition.
Previously, RepositoryComposition wasn't cached at all and store modules that e.g. contributed a Querydsl (or a different) fragment based on the interface declaration returned a new RepositoryComposition (and thus a different hashCode) each time RepositoryInformation was obtained leading to memory leaks caused by HashMap caching.
We now use Fragment's hashCode for the cache key resulting in RepositoryComposition being created only once for a given repository interface and input-fragments arrangement.
Closes#3252