We now accept Object-typed values to allow broader reuse of QuerydslPredicateBuilder. The conversion into the actual value considers the origin type and checks assignability before employing the ConversionService.
Closes#2573
Let List… interface variants extend their base parent so that List-based variants participate in the type hierarchy.
See #2538
Original pull request: #2538.
This introduces the interfaces
* `ListCrudRepository`
* `ListQuerydslPredicateExecutor`
* `ListQueryByExampleExecutor`
They return `List` instead of `Iterable` when returning multiple entities.
They can be used in the same way the interfaces without the `List` prefix can be used.
Closes#2535.
Original pull request: #2538.
Use var instead of explicit local types where applicable. Use pattern variable instead instanceof and cast. Prefer loops and nullable types over Stream and Optional. Convert classes to records where applicable.
See #2465
FluentQuery allows extending a query specification initially defined by a Example probe or a Querydsl Predicate and fetching the actual result through a functional programming model:
interface PersonRepository extends QuerydslPredicateExecutor<Person> {
<S extends T, R> R findBy(Predicate predicate, Function<FluentQuery.FetchableFluentQuery<S>, R> queryFunction);
}
PersonRepository repo = …;
List<PersonProjection> result = repo.findBy(QPerson.person.name.eq("Walter"), q -> q.sort(Sort.by("lastname")).as(PersonProjection.class).all());
Closes: #2228
Original pull request: #2421.
We now consider a qualified property path when registering and querying `QuerydslBindings` to ensure that paths matching various domain types do not accidentally get applied for a different type than they were registered for.
Previously, a binding for `Address.description` would be also applied to `User.description` as only the property path `description` was considered when looking up bindings.
Closes: #2418
Original Pull Request: #2422
We now no longer return a null Predicate from QuerydslPredicateBuilder.getPredicate(…) if the input values are empty or if the constraints are empty. Instead, we return an empty BooleanBuilder instance to avoid null handling on the calling side.
HandlerMethodArgumentsResolvers for QuerydslBindings retain their null/Optional.empty semantics.
Closes#2396
We now consider default Querydsl bindings when registering a DefaultQuerydslBinderCustomizer bean. The default bindings are applied before applying type-specific bindings.
Closes#206.
Original Pull Request: #2292
Introduce factory methods on Pageable, PageRequest, and QPageRequest to construct PageRequest objects. Replace builder with with…(…) methods.
Closes#322.
Update classes so that each member is declared on its own line. This
help to make them slightly easier to see when not using an IDE.
Original pull request: #448.
QuerydslPredicateArgumentResolver now properly handles predicate lookups that result in null values. The semantics of a handler method parameter of type of Querydsl's Predicate have been tightened to always see a non-null Predicate by default. Users that want to handle the absence of predicates explicitly can opt into seeing null by annotating the parameter with @Nullable or use Optional<Predicate>.
QuerydslPredicateBuilder now consistently returns null in case the original parameter map is entirely empty or consists of only keys with empty value arrays as empty form submissions do. This partially reverts the work of DATACMNS-1168, which moved into the direction of returning a default Predicate value for empty maps in the first place. That however prevents us from producing empty Optionals.
Related tickets: DATACMNS-1168.
We now explicitly rejects null values for the Sort parameters in the constructor of PageRequest to avoid the creation of invalid instances if the IDE validation of nullability constraints is not in use.
We now use StringUtils.hasLength(…) in the check whether to drop request elements from binding instead of ….hasText(…) as the latter drops blank strings so that's impossible to search for properties that contain a blank.
Align Javadoc to reflect the non-null contract for Predicate arguments.
Mention unpaged/unsorted factory methods for Pageable/Sort arguments.
Related ticket: DATACMNS-1114.
Marked all packages with Spring Frameworks @NonNullApi. Added Spring's @Nullable to methods, parameters and fields that take or produce null values. Adapted using code to make sure the IDE can evaluate the null flow properly. Fixed Javadoc in places where an invalid null handling policy was advertised. Strengthened null requirements for types that expose null-instances.
Removed null handling from converters for JodaTime and ThreeTenBP. Introduced factory methods Page.empty() and Page.empty(Pageable). Introduced default methods getRequiredGetter(), …Setter() and …Field() on PersistentProperty to allow non-nullable lookups of members. The same for TypeInformation.getrequiredActualType(), …SuperTypeInformation().
Tweaked PersistentPropertyCreator.addPropertiesForRemainingDescriptors() to filter unsuitable PropertyDescriptors before actually trying to create a Property instance from them as the new stronger nullability requirements would cause exceptions downstream.
Lazy.get() now expects a non-null return value. Clients being able to cope with null need to call ….orElse(…).
Original pull request: #232.
We now return Optional<T> for QuerydslPredicateExecutor.findOne(Predicate) aligning the return type to the ones used in CrudRepository.
Original pull request: #215.
We now follow a more consistent naming scheme for the methods in repository that are driven by the following guidelines:
* Methods referring to an identifier now all end on …ById(…).
* Methods taking or returning a collection are named …All(…)
That results in the following renames:
* findOne(…) -> findById(…)
* save(Iterable) -> saveAll(Iterable)
* findAll(Iterable<ID>) -> findAllById(…)
* delete(ID) -> deleteById(ID)
* delete(Iterable<T>) -> deleteAll(Iterable<T>)
* exists() -> existsById(…)
As a side-effect of that, we can now drop the Serializable requirement for identifiers.
Updated CRUD method detection to use the new naming scheme and moved the code to Java 8 streams and Optional. Adapted RepositoryInvoker API to reflect method name changes as well.
We now support Order creation with Order.asc(String) and Order.desc(String) factory methods as shortcut to constructor creation via new Order(Direction, String).
Sort.by(Order.asc("age"), Order.desc("name"));
Deprecated Order(String) constructor in favor of the Order.by(String) factory method. Replace references to new Order(String) with Order.by(String).
Original pull request: #211.
