`Specification.where(spec)` is deprecated without further notice

[albertus82]

Hi,

I just noticed that static <T> Specification<T> where(@Nullable Specification<T> spec) is deprecated but no information is provided on how to fix the code, so a compiler warning is triggered and apparently there's nothing I can do to fix it. Am I missing something?

Thanks.

[mp911de]

Thanks for letting us know that the deprecation isn't expressive enough. The where method merely caters for the broken nullability allowance and is replaced by where(PredicateSpecification) in 4.0. Let me add a bit of documentation.

[r-gruber]

@mp911de I understand that "where(...)" should not accept null in the future.
There are a lot of guides out there (specifically when dealing with building dynamic queries based on varying input data) which suggest to use the following pattern:

Specification<Audit> where = Specification.where(null);
if (type != null) {
    Specification<Audit> s = (root, query, cb) -> cb.equal(root.get("type"), type);
    where = where.and(s);
}
if (op != null) {
    Specification<Audit> s = (root, query, cb) -> cb.like(root.get("operation"), "%" + op + "%");
    where = where.and(s);
}
if (.......

Here the "where(...)" is used to have a common starting point to dynamically attach specific conditions to.
If "where(...)" does not support null anymore, will there be an other option to get such an empty starting-specification in order to keep this kind of simple code structure which dynamically adds conditions on the fly?

[mp911de]

Thanks for reaching out. We've introduced Specification.unrestricted() and PredicateSpecification.unrestricted() as entry points for specification composition (and to reduce null usage in calling code).

Let me know whether this helps or whether there is something we can improve.

[r-gruber]

Thanks, I found the Specification.unrestricted() on the master branch. It does not seem to be available on the 3.5.x branch. It seems to be exactly what I was looking for though.
Any plans on putting Specification.unrestricted() onto the 3.5.x branch? In that case we could already prepare our business logic and don't have to do all the code changes during the update to 4.0. Also you could maybe add a note to the @deprecated that unrestricted() is the suggested replacement for where(null)

Anyway, thank's for the info!

[r-gruber]

I created a pull request as a suggestion: #3941
But please feel free to discard it if you don't plan to backport it. Thanks

[mp911de]

Makes sense, I've created (and resolved) #3942.

[codingtim]

Hi, we also use this method to create a specification:

    Predicate predicate = cb.equal(root.get(CODE_FIELD), codeValue);
    if (StringUtils.isNotBlank(queryString)) {
        predicate = cb.and(
                predicate,
                cb.like(cb.lower(root.get(SUMMARY_FIELD)), "%" + queryString.toLowerCase() + "%")
        );
    }
    return predicate;
}),

I understand that there is a workaround for the Specification.unrestricted(), but is there also a new method on 3.5.x branch to use when actually creating a predicate?
I have read in some replies about PredicateSpecification but that is not yet available in 3.5.x branch
Will the Specification.where(..) be removed completely in 4.x or just the null support in that method?