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[] 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[] 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[] 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[] 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 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[] payload() default { };
Class>[] value() default {};
}И на такой интерфейс.
public interface ValidationChainElement {
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-ам (по крайней мере пока). Но в целом — это уже минимально-рабочий вариант, который можно пощупать.
Пишите свои мысли на счет этой либы и ее надобности. Рекомендации и замечания по коду тоже приветствуются.
Всем спасибо!
