Completely rewrote namespace bean definition parsing to be extendable more easily. Separated XML concerns from annotation based configuration. The central point to extend the namespace parsing for a certain module is now hidden behind the RepositoryConfigurationExtension interface (have a look at the RepositoryConfigurationExtensionSupport base class as well).
The id properties are now discovered by the BasicPersistentEntity during the call to addPersistentProperty(…). Beyond that the method rejects the id property if one was already set.
Added RepositoryPopulator abstraction and implementations based on Spring OXM Unmarshallers as well as Jackson. This allows arbitrary repositories being populated with data pulled from XML / JSON, no matter what store they are actually backed. The populator will eventually populate the repositories held in a Repositories instance. It can be used like this:
Repositories repositories = new Repositories(applicationContext);
ResourceReader reader = new JacksonResourceReader();
ResourceReaderRepositoryPopulator populator = new ResourceReaderRepositoryPopulator(reader);
populator.setResourceLocation("classpath*:data.json");
populator.populate(repositories);
The ResourceReader defines what technology shall be used to read the data from the file into objects. The ResourceReaderRepositoryPopulator uses the reader and can either get a set of Resource instances configured or is able to lookup resources using a location string. The actual Repositories instance captures all CrudRepository instances contained inside an ApplicationContext.
The populators can also be used from within XML configuration though the repository namespace elements shown below:
<repository:jackson-populator location="classpath:org/springframework/data/repository/init/data.json" />
<repository:unmarshaller-populator location="classpath:org/springframework/data/repository/init/data.xml" unmarshaller-ref="unmarshaller" />
Updated reference documentation accordingly.
So far we have considered Java transient fields as transient through the isTransient() method on PersistentProperty. This resulted in the properties not being persisted eventually. We now consider all fields as non-transient by default as we actually have to persist them as the object cannot be re-created completely without doing so as the usage of the transient keyword might rely on the readObject(…) method inside the object which would actually reconstitute the transient field's state but we of course cannot call this method actually.
So far the domain classes to be added to the mapping context initially were added in afterPropertiesSet() of InitializingBean. This had the drawback that although the MappingContext is already set up properly the actual listeners of the events fired (e.g. index creating ones) might not have been set up properly. We list to the ContextRefreshedEvent indicating the entire ApplicationContext being set up completely. Thus all infrastructure components are set up properly and the timing issues doesn't exist anymore.
Introduced PropertyReferenceException to capture the invalid property and the base PropertyPath a property expression could be resolved into. Introduced getLeafProperty() to be able to access the leaf property of a property path being created.
Fixed minor performance problems discovered by the fix for DATAMONGO-439. We're now caching the information whether a constructor parameter is an enclosing class parameter. PersistentEntityParameterValueProvider is throwing an exception now if the parameter is not referring to a property of the entity (via the parameter name).
If a type implemented Iterable<…> it was currently treated as a collection which might cause inappropriate conversion in the mapping sub-system. We now consider types collection like if they're either Iterable directly or assignable to Collection.
Renamed methods in RepositoryMetadata to be consistent with EntityMetadata. Changed return type of RepositoryMetadata.getIdType() to Class<? extends Serializable>. Changed RepositoryFactoryInformation interface to expose RepositoryInformation rather than just the repository interface. Added exposing the QueryMethod instances as well. Adapter Repositories wrapper and it's clients accordingly.
Supposed you have a base repository interface declaring a method:
interface BaseRepository<T, ID extends Serializable> extends Repository<T, ID> {
T myGenericMethod();
}
as well as a concrete repository redeclaring this method to annotate a query on it:
interface ConcreteRepository extends BaseRepository<User, Long> {
@Query("…")
User myGenericMethod()
}
Until now we both returned the intermediate method as well as the concrete one which might cause failures as in this case a query derivation would be attempted for the intermediate method which will fail for obvious reasons. The fix now starts with looking up the most specific method when iterating over the repository's methods which causes the intermediate method to be skipped in case it was overridden.
With the fix for DATACMNS-151 we apparently broke the generic parameter type matching for methods that carry the domain class type parameter as argument. We now inspect the bound and make sure we compare the name of it if it's a TypeVariable or use the plain parameter type if its not.
PersistentProperty now exposes isEntity(). Mapping context now allows accessing a PersistentEntity referred to from a PersistentProperty. JavaDoc cleanups in MappingContext interface.
Method signatures of save(…) methods in CrudRepository now return the concrete type passed in. This way subtypes can be persisted without casting the result back.
class Contact { … }
class Person extends Contact { … }
interface ContactRepository extends CrudRepository<Contact, Long> { … }
Before:
Person person = new Person();
person = (Person) repo.save(person);
^^^^^^^^
Now:
Person person = new Person();
person = repo.save(person);
When trying to access an inexistent property starting with an underscore (e.g. _id) PropertyPath.create(…) ran into a StackOverflowException. Changed the traversing regular expression to expect at least one capital letter for further traversals.
Just mentioned method threw a NullPointerException when the property was backed by an untyped Map or Collection as TypeInformation.getActualType() returns null in this case. Changed that to correctly return false.
