المواصفات والتصفية الديناميكية القائمة على المعايير

Real applications rarely query with fixed criteria. A product search screen might filter by name, category, price range, or any combination the user picks at runtime.

Writing a separate repository method for every combination explodes fast: findByName, findByNameAndCategory, findByCategoryAndPriceBetween... This does not scale.

Spring Data JPA's Specification API lets you compose type-safe query fragments at runtime and combine them with and() / or(). In this lesson you'll build dynamic predicates the clean way.

To use Specifications, your repository must extend JpaSpecificationExecutor<T> in addition to JpaRepository.

This adds overloaded methods such as findAll(Specification<T>), findAll(Specification, Pageable), findOne(Specification), and count(Specification).

A Specification<T> is a functional interface with one method:

Predicate toPredicate(Root<T> root, CriteriaQuery<?> query, CriteriaBuilder cb)

• root — the entity you query from; use root.get("field") to reference columns.
• query — the overall CriteriaQuery (for ordering, distinct, grouping).
• cb — the CriteriaBuilder factory that builds Predicate objects like equal, like, greaterThan.

Here is a Specification that filters products by an exact category name. A common idiom is to expose factory methods returning Specifications.

Notice root.get("category") walks into the related Category entity, then .get("name") reaches its field.

The power of Specifications is composition. Use the static and instance helpers on the interface:

• Specification.allOf(...) / Specification.anyOf(...) — combine many.
• spec.and(other) — logical AND.
• spec.or(other) — logical OR.
• Specification.not(spec) — negation.

Each combinator returns a new Specification, so chaining stays immutable and readable.

The real win is assembling a Specification only from the filters the user actually supplied. Start from an empty conjunction and append non-null criteria.

In Spring Boot 4, Specification.unrestricted() returns a no-op base that matches everything — the ideal neutral starting point.

The CriteriaBuilder exposes the building blocks you need for flexible text and numeric filters:

• cb.like(cb.lower(root.get("name")), "%" + term.toLowerCase() + "%") — case-insensitive contains.
• cb.between(root.get("price"), min, max) — inclusive range.
• cb.greaterThanOrEqualTo(...) / cb.lessThanOrEqualTo(...) — open-ended bounds.

A neat alternative to if guards: let each factory return null when its input is absent. Spring Data treats a null Specification (and a null returned from toPredicate) as "no restriction" and skips it during composition.

This keeps the builder flat, but be explicit — returning null can surprise readers, so document it.

For collection associations or to avoid lazy-loading pitfalls, create an explicit Join from the root. This generates a SQL JOIN and lets you filter on the related entity's columns.

Tip: when a join can multiply rows, call query.distinct(true) to avoid duplicate parents in the result.

Specifications combine seamlessly with paging. Pass a Pageable alongside the Specification and Spring Data applies WHERE, ORDER BY, LIMIT, and OFFSET in one query.

The returned Page also runs a count query (using the same Specification) so you get total elements for free.

Specifications are lambdas, so the composition logic itself is plain Java you can reason about without a database. This runnable example mirrors how and()/or() short-circuit by composing boolean predicates the same way.

It demonstrates the mental model: a Specification is a deferred predicate that you combine before executing.

You are building a dynamic filter where each optional criterion may or may not be present. You want a neutral base Specification that matches all rows, then conditionally add restrictions. Which is the correct Spring Boot 4 starting point?

You learned how to build runtime-driven, type-safe filters with the JPA Specification API:

• Extend JpaSpecificationExecutor to unlock findAll(Specification, ...).
• A Specification is a lambda over (root, query, cb) returning a Predicate.
• Compose with and(), or(), not(), and start from Specification.unrestricted().
• Add restrictions conditionally so only supplied filters affect the query.
• Use cb.like/cb.lower, cb.between, and explicit root.join(...) with query.distinct(true) for richer queries.
• Pass a Pageable for paging, sorting, and an automatic count query.

This pattern replaces dozens of hand-written finder methods with one clean, composable builder.