Class DeletionAwareFinderValidator

java.lang.Object
su.onno.spring.DeletionAwareFinderValidator
All Implemented Interfaces:
org.springframework.beans.factory.SmartInitializingSingleton

public class DeletionAwareFinderValidator extends Object implements org.springframework.beans.factory.SmartInitializingSingleton
Boot-time guardrail against the soft-delete footgun. Catalogs/documents are soft-deleted (deletionMark); the inherited repository finders (findAll()/findById()/ findByCode()/findByNumber()) return those tombstones by design (so RefResolver can resolve a Ref<T> to a deleted target, and restore/admin can reach them). A hand-written finder that forgets to exclude them silently feeds "deleted" rows into business logic — auth/login admission, posting, totals, picker option lists. Spring Data JDBC has no global soft-delete filter (no JPA @Where equivalent), so this scans every CatalogRepository/DocumentRepository at startup and flags any consumer-declared finder that returns entities without being deletion-scoped.

A finder is considered safe when its name carries a DeletionMark predicate (e.g. findByExternalNumberAndDeletionMarkFalse), its @Query text references the deletion_mark column, or it is annotated IncludesDeleted to declare it intends to see tombstones. The framework's own inherited finders (findActiveBy*, findByCode, …) are never flagged.

Controlled by onno.repository.deletion-check: warn (default — log a warning), strict (fail startup), or off.

  • Constructor Details

    • DeletionAwareFinderValidator

      public DeletionAwareFinderValidator(org.springframework.beans.factory.ListableBeanFactory beanFactory, DeletionAwareFinderValidator.Mode mode)
  • Method Details

    • afterSingletonsInstantiated

      public void afterSingletonsInstantiated()
      Specified by:
      afterSingletonsInstantiated in interface org.springframework.beans.factory.SmartInitializingSingleton