Java + Spring + Jakarta Validation. Самописный «аддон» для валидации Entity через БД и EntityManager

Вступление

Вот и моя первая статья на Хабре.

Посвящена она будет презентации своего небольшого решения для валидации моделей с использованием запросов к БД и EntityManager.

Вариант этот пока черновой, "на коленке" и будет развиваться. Критика и рекомендации горячо приветствуются. Пока что мне важно понять, есть ли у сообщества запрос на что-то подобное и имеет ли смысл как-то публично развивать это решение.

Понятно, что статья рассчитана на тех, кто уже знаком с той же Jakarta Validation.

Для чего вот это вот все

Допустим, мы пишем свой CRUD для какой-то сущности с обилием связей.

Из чего будет состоять процесс валидации?

Условно, ее можно разделить на две части.

Первая и самая простая - это валидация на уровне исключительно входных данных. Всякие проверки на NotNull, NotBlank, возможно и какие-нибудь Regex-ы и пр.

Вторая, чуть посложнее - это валидация на стыке входных данных и текущего состояния БД, не пересекающаяся с первой (потому notnull-констрейнты, например, здесь можно не рассматривать - их можно отсеять и на первом этапе). Здесь можно было бы выделить такие наиболее типичные операции:

• Проверка поля на уникальность при создании новой сущности (записей со значением X поля N на момент сохранения быть не должно).

• Проверка поля на уникальность при обновлении сущности (при обновлении запись со значением X поля N должна оставаться только одна).

• Проверка существования проставленных FK-связей.

• Проверка существования самой сущности в случае обновления (делается, как правило, по ее ID-шке).

• Возможно, проверка unmodified-полей для обновления, т.е. если поле неизменяемое, но во входных данных мы пытаемся его изменить - исключение.

Надеюсь, ничего не забыл)

Валидацию (по моему опыту) в Spring-приложениях либо пишут сами (создавая, например, отдельный слой самописных валидаторов в стиле "if-else"), либо все же используют jakarta-решение (или что-то по-старше), представленное, например, в последних версиях spring-boot-starter-validation.

Рассмотрим "красивый" второй вариант.

Валидации "первого круга" в jakarta.validation представлены прекрасно. Это и есть всякие NotNull, NotBlank и пр. аннотации. Ну и, соответственно, реализация валидаторов от того же Hibernate. Валидации "второго круга", насколько мне удалось выяснить - никак не представлены. Что с этим делать?

Можно полагаться целиком на СУБД и выставленные для таблиц констрейнты. Это иногда сомнительный вариант. Во-первых, получается некоторое "смешение" подходов к валидации, а на мой взгляд лучше, когда все решается в одном стиле. Во-вторых, СУБД ругается не очень "удобными" сообщениями, еще и разными от СУБД к СУБД. Нужно как-то отдельно предусматривать какой-то "декодинг" этих сообщений, если мы хотим приводить их к более понятному для нас/пользователя формату.

Можно опять-таки смешать стили. Операции "первого круга" - через анноташки. Для операций "второго круга" - отдельный слой своих валидаторов. Но опять-таки, мне кажется, что лучше уж все делать в одном стиле. Да и писать придется многовато.

Ну а можно попытаться дополнить механизм проверки через Jakarta Validation собственными аннотациями, предназначенными для валидации "второго круга". Что я и попытался сделать.

Попытка реализации

Здесь я не буду сильно вдаваться в детали реализации - их можно будет посмотреть в моем репозитории. Больше остановлюсь на "спецификации".

Проверка констрейнта на уникальность.

На это есть следующая аннотация.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = UniqueValidationConstraintValidator.class)
public @interface UniqueValidationConstraints {

    String message() default "{com.ismolka.validation.constraints.UniqueValidationConstraint.message}";

    Class<?>[] groups() default { };

    Class<? extends Payload>[] payload() default { };

    ConstraintKey[] constraintKeys() default {};
}

Где ConstraintKey - это

@Target(ElementType.ANNOTATION_TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface ConstraintKey {
    String[] value();
}

ConstraintKey перечисляет все поля нашей Entity, входящие в констрейнт.

UniqueValidationConstraints, соответственно, агрегирует все наши констрейнты.

Когда аннотация проверяется - в БД через EntityManager формируется запрос с условием вида (table.field1Constraint1 = value1Constraint1 AND table.field2Constraint1 = value2Constraint1...) OR (...другой констрейнт) ...

В случае первого совпадения оно вернет нам boolean-кортеж для совпавшей по какому-то констрейнту/констрейнтам записи, где каждый элемент равен true, если определенный констрейнт нарушен. Дальше при обработке негативного результата для каждого нарушенного констрейнта мы кладем в HibernateConstraintValidatorContext для violation следующие параметры: constraintErrorFields - перечисление полей в констрейнте через запятую, constraintErrorFieldsValues - перечисление значений в констрейнте через запятую.

Пример.

@UniqueValidationConstraints(constraintKeys = {
        @ConstraintKey("libraryCode"),
        @ConstraintKey({"name", "authorName"})
})
public class Book {

    private Long id;

    private String libraryCode;
    
    private String name;
    
    private String authorName;
}

Инвентарный номер книги уникален, так же уникальна связка "название книги - автор книги".

Для создания все работать будет хорошо. Но как быть с обновлением? При обновлении-то данные с таким констрейнтом в БД могут существовать (когда, скажем, передаем на обновление нашу запись, но не меняем в ней этот констрейнт), но после обновления мы должны гарантировать, что он будет оставаться в таблице только один.

Первое, что пришло в голову: можно добавить поле в аннотацию UniqueValidationConstraints вроде groupWithIgnoringOneMatch. Обозначаем таким образом, для какой группы мы будем игнорировать одно вхождение. И передаем туда группу, отвечающую за обновление. В валидаторе же получим группы, с которыми его дернули, и проверим, есть ли среди них указанная. Если есть - тогда игнорируем.

Но, увы, судя по всему получить в валидаторе группы, с которыми он дернулся - невозможно. Потому родилась идея для другой аннотации.

Проверка констрейнта на лимит вхождений.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = LimitValidationConstraintValidator.class)
public @interface LimitValidationConstraints {

    String message() default "{com.ismolka.validation.constraints.LimitConstraint.message}";

    Class<?>[] groups() default { };

    Class<? extends Payload>[] payload() default { };

    LimitValidationConstraintGroup[] limitValueConstraints() default {};

    boolean alsoCheckByUniqueAnnotationWithIgnoringOneMatch() default false;
}

@Target(ElementType.ANNOTATION_TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface LimitValidationConstraintGroup {
    ConstraintKey[] constraintKeys();
    int limit() default 1;
}

Эта аннотация работает похожим образом, но теперь проверяет не просто единственное вхождение, а нарушение определенного лимита вхождений. Все констрейнты теперь группируются в LimitValidationConstraintGroup, где как раз для всех перечисленных констрейнтов будет указан лимит вхождений. Если лимит достигнут - тогда уже исключение. В качестве дополнения к уже существующим параметрам для violation добавился еще limit.

alsoCheckByUniqueAnnotationWithIgnoringOneMatch - своеобразная "интеграция" с UniqueValidationConstraints. Если выставляется в true - тогда заодно валидатор берет информацию из UniqueValidationConstraints и делает отдельный чек с игнорированием записи по ID. Таким образом, проблему, описанную для обновления и UniqueValidationConstraints можно решить так:

@LimitValidationConstraints(alsoCheckByUniqueAnnotationWithIgnoringOneMatch = true, groups = { Validation.Update.class })
@UniqueValidationConstraints(constraintKeys = {
        @ConstraintKey("libraryCode"),
        @ConstraintKey({"name", "authorName"}),
}, groups = { Validation.Create.class })
public class Book {

    private Long id;

    private String libraryCode;

    private String name;

    private String authorName;
}

Проверка существования связей.

Это уже дело посложней.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = CheckRelationsExistsConstraintsValidator.class)
public @interface CheckRelationsExistsConstraints {

    String message() default "{com.ismolka.validation.constraints.CheckRelationsExistsConstraints.message}";

    Class<?>[] groups() default { };

    Class<? extends Payload>[] payload() default { };

    RelationCheckConstraint[] value();
}

@Target(ElementType.ANNOTATION_TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface RelationCheckConstraint {

    String relationField() default "";

    RelationCheckConstraintFieldMapping[] relationMapping() default {};

    Class<?> relationClass() default Object.class;

    String message() default "{com.ismolka.validation.constraints.inner.RelationCheckConstraint.message}";

    String relationErrorMessageNaming() default "";
}

@Target(ElementType.ANNOTATION_TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface RelationCheckConstraintFieldMapping {

    String fromForeignKeyField();

    String toPrimaryKeyField();
}

Все FK-констрейнты мы перечисляем для CheckRelationsExistsConstraints в value.

RelationCheckConstraint содержит информацию о конкретном релейшене, который нужно проверить. Здесь мы можем указать поле-источник для relationField (можно заполнять, когда в сущности есть поле с релейшеном, помеченное как OneToOne, JoinColumn и пр.); relationClass (необязательно, если указан relationField); relationMapping (можно вручную расписать, как будет осуществляться сопоставление); relationErrorMessageNaming - можно отдельно обозначить для violation, как показывать в сообщении нарушенный релейшен.

Все работает в один запрос и выглядит, например, вот так

//...
@CheckRelationsExistsConstraints(
        value = {
                @RelationCheckConstraint(
                        relationField = "country",
                        relationMapping = {
                                @RelationCheckConstraintFieldMapping(fromForeignKeyField = "countryId", toPrimaryKeyField = "id")
                        }
                )
        }, groups = { CommonValidationGroups.OnCreate.class, CommonValidationGroups.OnUpdate.class }
)
public class District {

    //...

    @Column(name = "country_id")
    private Long countryId;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "country_id", referencedColumnName = "id", insertable = false, updatable = false)
    private Country country;

    //...
}

И для violation представлены параметры relationDoesntExist - какой релейшен нарушен, relationDoesntExistField - по какому полю, relationDoesntExistFieldValue - с каким значением.

Проверка существования сущности по констрейнту + unmodifiable

А вот и босс моей качалки.

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = CheckExistingByConstraintAndUnmodifiableAttributesValidator.class)
public @interface CheckExistingByConstraintAndUnmodifiableAttributes {

    String message() default "{com.ismolka.validation.constraints.ExistsByConstraint.message}";

    Class<?>[] groups() default { };

    Class<? extends Payload>[] payload() default { };

    ConstraintKey constraintKey();

    UnmodifiableAttribute[] unmodifiableAttributes() default {};

    UnmodifiableCollection[] unmodifiableCollections() default {};

    boolean stopUnmodifiableCheckOnFirstMismatch() default false;

    boolean loadByConstraint() default false;

    String loadingByUsingNamedEntityGraph() default "";
}

@Target(ElementType.ANNOTATION_TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface UnmodifiableAttribute {
    String value();

    String equalsMethodName() default "equals";

    String message() default "{com.ismolka.validation.constraints.inner.UnmodifiableAttribute.message}";

    String attributeErrorMessageNaming() default "";

    String[] equalsFields() default {};
}

@Target(ElementType.ANNOTATION_TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface UnmodifiableCollection {

    String value();

    String equalsMethodName() default "equals";

    Class<?> collectionGenericClass() default Object.class;

    String[] fieldsForMatching() default {};

    String message() default "{com.ismolka.validation.constraints.inner.UnmodifiableCollection.message}";

    String collectionErrorMessageNaming() default "";

    CollectionOperation[] forbiddenOperations() default { CollectionOperation.REMOVE, CollectionOperation.ADD, CollectionOperation.UPDATE };

    String[] equalsFields() default {};
}

public enum CollectionOperation {

    ADD,

    REMOVE,

    UPDATE
}

Первое, что нас интересует - это CheckExistingByConstraintAndUnmodifiableAttributes, наш каркас, и constraintKey.

По constraintKey, собственно, и будет проверяться существование нашей сущности.

В дополнение к этому сделаны два поля.

• loadByConstraint - entityManager в этом случае вернет не просто boolean, а наш объект. Полезно. Вдруг захотим, чтобы загруженная сущность после успешной валидации уже лежала в кэше, скажем? А для проверки неизменяемых полей (о которой чуть ниже) - так и вовсе обязательно true.

• loadingByUsingNamedEntityGraph - указываем, с каким NamedEntityGraph нам стоит подгружать "под капотом" нашу сущность. На всякий.

• stopUnmodifiableCheckOnFirstMismatch - останавливать проверку unmodifiable-полей на первом несовпадении (своеобразный break в случае, если у нас, например, в коллекциях подразумевается куча элементов).

И самое интересное - неизменяемые атрибуты/коллекции.

Начнем с атрибутов (UnmodifiableAttribute).

• value - тут будет лежать название нашего поля.

• equalsMethodName - определяет, по какому методу внутри класса поля будет идти сопоставление. Если оно вернет false - значит, все плохо и атрибут был изменен. Таким образом, сопоставление можно кастомизировать, использовать не "дефолтный" equals, а что-то свое.

• если такой вариант кастомизации не устраивает - есть еще equalsFields. Тут перечисляются поля, по каким будет идти Objects.equals. Чтобы не пришлось писать какой-то свой "кастомный" equals внутри класса, а определить это на уровне анноташки.

• attributeErrorMessageNaming - "кастомное" название атрибута для violation.

И переходим к коллекциям (UnmodifiableCollection).

• value, equalsMethodName, equalsFields, collectionErrorMessageNaming - все аналогично с UnmodifiableAttribute.

• fieldsForMatching - мы определяем, по какому ключу будут сопоставляться элементы в рамках коллекции. Т.е. если данные поля совпадают - значит, эти элементы можно сопоставлять уже по equalsFields/equalsMethodName. Если оно не определено - в качестве ключа будет "номер" элемента в коллекции.

• forbiddenOperations - какие операции в коллекции запрещены. По умолчанию запрещены все. Это операция ADD - добавление нового элемента; REMOVE - удаление; UPDATE - изменение существующего.

• collectionGenericClass - информация про generic-класс коллекции. По умолчанию Object.

Пример с коллекциями.

//...
@NamedEntityGraph(name = "test", attributeNodes = {
        @NamedAttributeNode(value = "testSubList", subgraph = "test.sub")
        },
        subgraphs = {
        @NamedSubgraph(name = "test.sub", attributeNodes = {
                @NamedAttributeNode("test")
        })
})
@CheckExistingByConstraintAndUnmodifiableAttributes(
        constraintKey = @ConstraintKey("id"),
        unmodifiableCollections = {
                @UnmodifiableCollection(value = "testSubList",
                        collectionGenericClass = TestSub.class,
                        equalsFields = {
                            "value"
                        },
                        fieldsForMatching = {
                            "id"
                        }
                )
        },
        loadingByUsingNamedEntityGraph = "test",
        loadByConstraint = true,
        groups = CommonValidationGroups.OnCreate.class
)
public class Test {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @OneToMany(mappedBy = "test")
    public List<TestSub> testSubList;
  
    //...
}

//...
public class TestSub {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
  
    @ManyToOne
    @JoinColumn(name = "test_id", referencedColumnName = "id", insertable = false, updatable = false)
    private Test test;

    private String value;

    //...
}

Ну и параметры для violation-ов.

• doesntExistFields - по какому констрейнту не существует.

• doesntExistFieldValues - по каким значениям констрейнта не существует.

• fieldDiffName - какое поле не совпадает.

• fieldDiffValueNew - новое значение

• fieldDiffValueOld - старое значение

Цепочка простых "кастомных" валидаторов

Здесь стоит обратить внимание на такую аннотацию.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Constraint(validatedBy = ValidationChainValidator.class)
public @interface ValidationChain {

    String message() default "{com.ismolka.validation.constraints.ValidationChain.message}";

    Class<?>[] groups() default { };

    Class<? extends Payload>[] payload() default { };

    Class<? extends ValidationChainElement<?>>[] value() default {};
}

И на такой интерфейс.

public interface ValidationChainElement<T> {

    boolean isValid(T object, ConstraintValidatorContext context);
}

Для аннотации ValidationChain в value можно передать классы-реализации данного интерфейса. Валидатор получает бины этих классов, организуя из них своего рода chain-of-responsibility. Объект прогоняется через эту цепочку, и на первом негативном результате возвращается false.

Подобное может пригодиться, если у нас есть логика валидации, не укладывающаяся в предыдущие кейсы. Наши "самописные" валидаторы (не завязанные на те или иные аннотации) будут существовать в виде полноценных бинов, где прописана какая угодно логика валидации, но по итогу все равно оказываются встроенными в инфраструктуру Jakarta-валидации и "пользуются" благами вроде ConstraintValidatorContext.

Заключение

Как примерно в итоге будет выглядеть сущность со всеми этими "наворотами" - можно увидеть тут.

@Entity
@Table(name = "district")
@Data
@NoArgsConstructor
@AllArgsConstructor
@LimitValidationConstraints(alsoCheckByUniqueAnnotationWithIgnoringOneMatch = true, groups = CommonValidationGroups.OnUpdate.class)
@UniqueValidationConstraints(constraintKeys = {
        @ConstraintKey({"name"})
}, groups = CommonValidationGroups.OnCreate.class)
@NamedEntityGraph(name = "district.eg", attributeNodes = {
        @NamedAttributeNode("country")
})
@CheckExistingByConstraintAndUnmodifiableAttributes(
        constraintKey = @ConstraintKey("id"),
        groups = CommonValidationGroups.OnUpdate.class,
        loadingByUsingNamedEntityGraph = "district.eg",
        loadByConstraint = true
)
@CheckRelationsExistsConstraints(
        value = {
                @RelationCheckConstraint(
                        relationField = "country",
                        relationMapping = {
                                @RelationCheckConstraintFieldMapping(fromForeignKeyField = "countryId", toPrimaryKeyField = "id")
                        }
                )
        }, groups = { CommonValidationGroups.OnCreate.class, CommonValidationGroups.OnUpdate.class }
)
public class District {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @NotNull(message = "{id.null}", groups = { CommonValidationGroups.OnUpdate.class })
    private Long id;

    @NotBlank(message = "{district.name.blank}", groups = { CommonValidationGroups.OnCreate.class, CommonValidationGroups.OnUpdate.class })
    private String name;

    @Column(name = "country_id")
    @NotNull(message = "{district.country.null}", groups = { CommonValidationGroups.OnCreate.class, CommonValidationGroups.OnUpdate.class })
    private Long countryId;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "country_id", referencedColumnName = "id", insertable = false, updatable = false)
    private Country country;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        District district = (District) o;
        return Objects.equals(id, district.id);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id);
    }
}

Конечно, блок с аннотациями большой, но это, наверное, все еще более выигрышно, нежели прописывать все это руками.

Репозиторий можно посмотреть по этой ссылке.

Все пока черновое и не задокументированное. Нужно будет как минимум подумать, как лучше внедрять в валидаторы EntityManager. Так же покрыть разными unit-тестами, особенно уделив внимание всяким null-ам (по крайней мере пока). Но в целом - это уже минимально-рабочий вариант, который можно пощупать.

Пишите свои мысли на счет этой либы и ее надобности. Рекомендации и замечания по коду тоже приветствуются.

Всем спасибо!