DATACMNS-966 - Add annotation that specify allowed sort properties. #190
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Repository methods can now return JavaSlang's Option as alternative to JDK 8's Optional or Guavas Optional.
Removed Spring 4.2 guard from QueryExecutionConverter and its unit tests.
…n type. Mentioned the support for Scala's Option type, too.
We now no longer attempt query creation for static methods declared on a repository interface. This allows static method usage inside of repository interfaces.
interface PersonRepository extends CrudRepository<Person, String> {
static String createId() {
// …
}
default Person findPerson() {
return findOne(createId());
}
}
Using a lower case "s" now.
…erloads. We now try to look up a target class method based on concrete name and parameter type before falling back on the more expensive type matches. This also eliminates the possibility of invalid method matches as described in the ticket.
…nt resolvers. We now provide HandlerMethodArgumentResolver interfaces to resolve Sort and Pageable method arguments with typed return values.
Minor JavaDoc stuff.
Introduced @DomainEvents usable on a method of an aggregate root. The method will be invoked when the aggregate is passed to a repository to save and its returned value or values will be exposed via an ApplicationEventListener. Also, the aggregate can expose a method annotated with @AfterDomainEventPublication which will be invoked once all events have been published.
Additional JavaDoc and @SInCE tags. Minor additions to AbstractAggregateRoot.
We now publish events for all methods named "save" on the repository. Fundamentally, that's in place to capture calls to CrudRepository.save(Iterable entities), too. Some minor refactorings to the internal setup of EventPublishingMethodInterceptor. More JavaDoc.
…nd Period. Original pull request: #186.
Switched to parameterized tests for newly introduced Converters. Fixed imports and JavaDoc. Original pull request: #186.
…der for internal extension points. Both the configuration code looking up Spring Data specific Jackson modules as well as the code detecting whether we have multiple Spring Data modules on the classpath used component scanning. That can have quite significant impact on startup times. This commit replaces the classpath scanning with the use of SpringFactoriesLoader that now requires modules that want to extend the behavior of Spring Data's web configuration or indicate a repository implementation being present by shipping a file called META-INF/spring.factories. Spring Data relies on the following keys: - org.springframework.data.web.config.SpringDataJacksonModules - list the Spring configuration classes that will expose additional Jackson modules that are supposed to be registered for Spring Data's Jackson web support - org.springframework.data.repository.core.support.RepositoryFactorySupport - list the Spring Data repository factory implementation class that implements repository support for your module. The general detection and configuration mechanism for user repositories is not affected by this. Currently Spring Data only uses the pure number of different entries for that key to switch into strict configuration mode in case we find more than one entry.
…ues now. Previously a null value was added to the list of associations if it was handed to BasicaPersistentEntity.addAssociation(…). We now drop those null values and log a warning as it usually indicates a MappingContext implementation identifying a property as association but subsequently failing to look it up.
We now really use exact matching for a match setup requesting exact matching. Previously, we erroneously set up the matching with a startsWith().
We now support downcasts (e.g. user.as(QSpecialUser.class).…) expressions in Querydsl web binding. We do so by skipping the introduced intermediate step in the path when calculating the dot path. Refactored the internals of the binding to now work based on a PathInformation implementation for which either a Querydsl Path or a Spring Data PropertyPath can be used. This allows us to reuse the paths of predefined bindings. A bit of Lombok cleanup in internal implementations.
… types. Javaslang's collection and map types can now be used on repository query methods and get adapted similarly to nullable wrapper types (like JDK's Optional). Also made TypeInformation infrastructure aware of the map type so that a value type lookup gets handle correctly.
…m collections. The nullable wrapper types now expose whether they're a single value type or a multi value type. This is necessary as Javaslang's Option implements Iterable (something we previously checked for to detect a collection query) and the custom collections potentially being usable within other wrapper types (e.g. Future<Seq<User>>).
…actorySupport. Its usage is recommended over using the instance as advice.
…detect transactions. The interceptor discovers whether a transaction was running before the call entered the repository proxy and exposes that fact via ….isSurroundingTransactionActive() for donwstream usage. Related ticket: DATAJPA-1023.
…anSupport. RepositoryFactoryBeanSupport now takes the repository interface as a constructor argument instead of as a setter. This makes sure that the container induced type prediction for factory beans actually wires the interface *before* it calls getObjectType() on the instance. This allows us to remove the extra infrastructure we had in place to predict the bean types and autowiring will just work out of the box. Adapted infrastructure code accordingly, removed obsolete infrastructure code and adapted test cases accordingly.
We now manually filter already gathered property names in ReturnedInterface.getInputProperties() as we have to deal with duplications for properties with the same name at different levels of the inheritance hierarchy.
Aloren
pushed a commit
to Aloren/spring-data-commons
that referenced
this pull request
Jun 20, 2019
The fix for spring-projectsgh-153 was sensible, but has now exposed another issue which is that the bootstrap initializers, whilst they are now only created once, actually only get applied to the parent context in a hierarchy. Most of the time this doesn't matter because the child contexts all benefit from environment changes and additional beans added to the parent. If the children are supposed to actually have different environments, though, there is a problem. So this change locates the existing bootstrap context and applies it to each new context created separately. Unfortunately we have to use reflection to do that for now because there is no way to discover the parent with a public API before the context is refreshed. See spring-projectsgh-190
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've fixed the DATACMNS-966.
Please review.