Ported the projection infrastructure previously residing in Spring Data REST and extended it by defaulting to a Map-backed source to store and retrieve data.
Separated out the SpEL based functionality mostly for SOC-reasons and easier testability.
Related tickets: DATAREST-437, DATACMNS-618, DATACMNS-89.
Extended the implementation of DomainClassConverter to also support converting domain types into their identifier types and transitively convertible types.
Ported Spring Data REST's converters for Distance and Point and turned them into Formatter instances. Extended Metric interface to return an abbreviation. Added getUnit() to Distance and tweaked Jackson setup to ignore the additional property.
We now automatically register the news introduced Formatters when using @EnableSpringDataWebSupport so that Point and Distance values can be parsed and printed from and to Strings out of the box.
We now make the field detected by the callback accessible so that the value lookup doesn't fail for private fields. Added a few more unit tests to verify behavior.
PageImpl now makes sure that the total given to the constructor is never less than then number of items given to make sure we do not mask broken count calculation by creating an actually invalid instance.
Related ticket: DATAMONGO-1120.
To be able to verify the conversion of List based query execution results into Sets I extracted a QueryExecutionResultHandler that applies the already implemented handling for Optional types and eventually general prost processing in case the return type declared at the repository query method doesn't match the returned value.
Added additional unit tests for Optional handling.
RepositoryConfigurationExtensionSupport.registerBeansForRoot(…) now hands the extracted source of the configuration to the bean registration for the RepositoryInterfacePostProcessor.
The bean definitions that were registered for a repository configuration setup we registered once for every usage of the repository configuration element (annotation or XML). This caused multiple registrations of the very same bean definition which - as in case of the RepositoryInterfaceAwareBeanPostProcessor - apparently leads to performance problems in the container startup. Feedback for the latter claim is already asked for but we improved the registration setup nonetheless.
Introduced a registerIfNotAlreadyRegistered(…) method on RepositoryConfigurationExtensionSupport to allow easy registration of to-b-registered-once-and-only-once beans. We now hint towards the newly introduced method in registerWithSourceAndGeneratedBeanName(…).
Added key/value specific PersistenceExceptionTranslator and use it within KeyValueTemplate. Fixed some todos in JavaDoc and added missing tests. Renamed test class for SimpleKeyValueRepository according to the changed name.
Original pull request: #95.
Extracted KeySpaceUtils from KeyValueTemplate and pulled in the copy of MetaAnnotationUtils to hide it from the outside. Separated related test cases into dedicated test class.
Renamed BasicMappingContext to KeyValueMappingContext and BasicPersistentProperty to KeyValuePersistentProperty. Fixed spelling in SpelQueryCreatorUnitTests.
Moved MappingContext into separate package to satisfy architectural guidelines. Created dedicated KeyValueRepositoryNamespaceHandler to avoid a circular reference between commons and the key-value subsystem.
Made the query creator type an annotation on @EnableKeyValueRepositories so that it's not exposed to the user to be configured. Added the necessary ImportBeanDefinitionRegistrars to the Hazelcast and EhCache implementation. Removed @since tags from those modules at they're not going to make it into Spring Data Commons. Renamed EnableEhCacheRepsotoriesUnitTests to EnableEhCacheRepositoriesIntegrationTests as well as the same for the Hazelcast specific test.
The KeyValueRepositoryConfigurationExtension now explicitly registers a KeyValueMappingContext unless one is already registered. AnnotationRepositoryConfigurationSource now explicitly exposes an AnnotationMetadata instance for the annotation that triggered the configuration.
Turned SpelCriteriaAccessor and SpelPropertyComparator into classes to be able to pass them a SpelExpressionParser to be able to get rid of SpelExpressionFactory eventually. Made both classes as well as SpelQueryEngine package protected for now.
Moved repository implementations into support package. Updated architcture description JavaDoc polish, spacing, blank lines. Added TODOs.
Original pull request: #95.
Added basic infrastructure for repositories on top of key-value data stores. For more details see the original pull request.
Original pull request: #95.
PersistentEntity now exposes an getIdentifierAccessor(…)-method that allows obtaining the identifier of an entity without using a PersistentProperty instance. This allows advanced scenarios (like multi-property identifiers). Also we can use store specific means to optimize id lookups to e.g. avoid proxy initialization for lazy loading proxies.
BasicpersistentEntity now allows subtypes to be handed into the PersistentPropertyAccessor lookup to support inheritance hierarchies as well as interface based PersistentEntity scenarios.
To be able to customize the lookup of bean properties by persistent store we now expose a getPropertyAccessor(Object entity) method on PersistentEntity. It returns a PersistentPropertyAccessor which is basically an interface with a simplified API of BeanWrapper.
Reduced the plain BeanWrapper to not perform any type conversion to be able to drop the ConversionService dependency. To compensate for that we introduced a ConvertingPropertyAccessor that takes a ConversionService and delegates to a standard PersistentPropertyAccessor and applies conversions if necessary.
Refactored client APIs to use the PersistentPropertyAccessor instead of referring to BeanWrapper directly. Deprecated BeanWrapper.create(…) for removal in RC1.
Made DefaultCrudMethods public to support better testing. Components that are based on CrudMethods can be tested easier if DefaultCrudMethods is public, so that an instance can easily be set up by using a DefaultRepositoryMetadata instance.
Polished JavaDoc and copyright headers.
The initial setup of the type variable map now unfolds the detected types in the map to make sure we detect all type variables present in the current scope.
Added caching of component and map value TypeInformation instances to avoid repeated creation.
Replaced CrudInvoker with the more sophisticated and flexible RepositoryInvoker originating from Spring Data REST. Slightly refined the API and added a lot more unit tests. Refactored usage of CrudInvoker to use a DefaultRepositoryInvokerFactory and create RepositoryInvokers for the domain types.
So far, the lookup of the type variable map was preferring the type variable maps detected on parent types in nested structures. This caused the concrete type variables in nested types not being considered correctly which caused the type resolution to fall back to the generic bounds.
We now accumulate the type variable maps to avoid having to lookup a certain map in the nesting hierarchy. The core fix is in ParentTypeAwareTypeInformation's constructor and mergeMaps(…) respectively. Simplified the handling of type variable maps and made proper use of generics throughout the class hierarchy.
We now support the keyword NotContaining in query methods for repositories. This is achieved by adding NOT_CONTAINING to the Part.Type enum with the variants 'IsNotContaining', 'NotContaining', 'NotContains'. Added a dedicated toString() method to ease debugging to Part.Type.
Original pull request: #100.
DomainClassConverter now returns input when the source type is identical to the target type. Previously we erroneously tried to convert the sourceType to the idType of the targetType's backing repository. As a side effect we also avoid performing some unnecessary converter hops.
Original pull request: #101.
Added some JavaDoc where missing. Better variable names and slightly parameter ordering changes. Formatting in the unit tests and reference to the original ticket.
Original pull request: #98.
Introduced BytecodeGeneratingEntityInstantiator which dynamically generates classes to speed up the dynamic instantiation of objects. Since we cannot support every use case with byte code generation we gracefully fallback to the ReflectiveEntityInstantiator.
BytecodeGeneratingEntityInstantiator has support for unboxing of constructor parameters and more robust handling for cases where we cannot generate a custom ObjectInstantiator.
Original pull request: #98.
Clarified return values if predicates don't match or return multiple results (for the findOne(…) method). Copied summary to the @return tag.
Original pull request: #96.
The detection of the custom implementation has now been moved into the Bean base class to avoid calls to BeanManager.getBeans(…) (which are necessary to pick up the configuration class defining postfixes and the like) happen to early in the CDI container lifecycle.
Related ticket: DATACMNS-557.
Previously we only allowed to sort by QueryDsl path expressions. With this change we now also support ordering by operator expressions, e.g. yearMonth() on a date property.
Original pull request: #94.
The type detection for entity candidates of PersistentProperty instances now consistently handles collection types even if they're used als collection or map values.
Annotations used on both fields and accessors are now only rejected if they're Spring Data annotations (i.e. from the org.springframework.data namespace) and the configurations of these annotations differ.
Renamed CdiRepositoryConfigurationSource to CdiRepositoryConfiguration. Turned anonymous inner default implementation into dedicated enum to avoid repeated instantiation.
Changed the CdiRepositoryBean to rather take a Bean instance of the custom implementation instead of the resolved object to make sure both instances (the custom implementation and the repository proxy) are instantiated at the same time.
Fixed imports. Some early returns to avoid unnecessary nesting.
Adapted architecture description to allow CDI module accessing the configuration module.
Related pull request: #92.
The CDI extension now discovers a custom implementation class similarly to the detection when using Spring Data in a Spring container. Extracted the custom implementation detection for re-use. The CDI extension discovers the potentially available bean and hands it to the CdiRepositoryBean for further usage.
Implementations should implement the extended variant of the create(…) method we introduce with this commit to be able to forward the resolved custom implementation bean.
Original pull request: #92.
