Можно ли заставить doctrine валидировать поля при создании сущности?

Question

[galliard]

Доктрина создает сущности при помощи рeфлексии, в обход конструктора и сеттеров. Видимо предполагается, что состояние, хранящееся в БД, всегда валидно. Но так бывает не всегда. Иногда приходится лазить в БД в обход всей бизнес-логики, что в свою очередь иногда приводит к ошибкам.

Например, в БД есть nullable поле `name`, которое в сущности не должно быть nullable, и в геттере указано public function getName(): string, и если в БД руками проставить null, то ошибка возникает только при запросе этого геттера. А мне бы хотелось бы выбросить какой-нибудь эксепшн ещё в момент создания сущности.

Answer 1

[voronkovich]

1. Вы можете реализовать свой гидратор (hydrator). Гидраторы как раз и занимаются созданием сущностей. Только официальной документации по созданию гидраторов нет. Есть это: https://www.doctrine-project.org/projects/doctrine...
Есть еще старая статья: https://techpunch.co.uk/development/create-custom-...
И статья про гидраторы от Marco Pivetta: https://ocramius.github.io/blog/doctrine-orm-optim...

2. Вы можете подписаться на событие postLoad: https://www.doctrine-project.org/projects/doctrine... и бросать исключение сразу же после создания объекта.

Но, на мой взгляд подобное решение приведет к плохим последствиям т.к. исключение будет бросаться в самых неожиданных местах. Как вы будете его обрабатывать?
Лучше локализуйте проблему там, где она возникает, бросая исключения в коде, не допускающем null-значений:

class UserNotfier
{
    public function notifyUser(User $user): void
    {
        if (null === $user->getEmail()) {
            throw new \Exception('User must have an email!);
        }
        
         // ...
    }
}

Comments

[Алексей Скобкин]

Лучше локализуйте проблему там, где она возникает, бросая исключения в коде, не допускающем null-значений

Судя по тому, что автор пишет, ему там нужны эти NULL-значения. А если они ему нужны - абсолютно непонятно, почему сущность не может возвращать NULL в геттере.
Не знаю, как у вас, а у меня этот вопрос вызывает полное непонимание происходящего в проекте у автора вопроса.

[voronkovich]

Алексей Скобкин, я полностью согласен с вами, ему нужно позволить геттеру возвращать null, а там где null не допустим, бросать исключения. Либо фильтровать сущности с null-значениями еще на стадии выборки.

Полагаю, что часть данных у него приходит из внешних источников и он не может контролировать появление null-значений в базе. Но не хочет с этим смириться :)

[Алексей Скобкин]

voronkovich,

Либо фильтровать сущности с null-значениями еще на стадии выборки.

Да чёрт побери, пройтись миграцией по базе, выпилить оттуда NULL и сделать поле NOT NULL в конце концов, если его там быть не должно. В базе просто не должно быть невалидных данных.

Полагаю, что часть данных у него приходит из внешних источников и он не может контролировать появление null-значений в базе. Но не хочет с этим смириться :)

Добавить постобработку данных из внешних источников. Либо, если NULL убрать нельзя - тогда и сущность должна полностью отражать схему БД, то есть позволять содержать в себе (и возвращать в геттере) NULL.

[voronkovich]

Алексей Скобкин, Да, я полностью согласен, что ему нужно позволить NULLам быть. Это самое лучшее что он может сделать.

Но если человеку очень хочется выстрелить себе в ногу, пусть сделает через гидраторы, события, __wakeUp или что-нибудь в этом роде. Я не против.

[galliard]

1. Вы можете реализовать свой гидратор (hydrator). Гидраторы как раз и занимаются созданием сущностей. Только официальной документации по созданию гидраторов нет. Есть это: https://www.doctrine-project.org/projects/doctrine...
Есть еще старая статья: https://techpunch.co.uk/development/create-custom-...
И статья про гидраторы от Marco Pivetta: https://ocramius.github.io/blog/doctrine-orm-optim...

Спасибо. Не знаю, что получится в итоге, но выглядит интересным.

Хотя я, признаюсь честно, ожидал более простого решения, типа "добавить такую-то аннотацию".

2. Вы можете подписаться на событие postLoad: https://www.doctrine-project.org/projects/doctrine... и бросать исключение сразу же после создания объекта.

Мне этот вариант показался слишком грязным, придется в каждом методе описать функцию постлоЛоада. Проблему решит, но не красиво.

Но, на мой взгляд подобное решение приведет к плохим последствиям т.к. исключение будет бросаться в самых неожиданных местах. Как вы будете его обрабатывать?
Лучше локализуйте проблему там, где она возникает, бросая исключения в коде, не допускающем null-значений:

Это как раз то, чего хочется избежать. Уж очень много таких ифов придется по коду размазать. Да и "неожидано" сущности вроде нигде не появляются, их запрос всегда явный.

[voronkovich]

Мне этот вариант показался слишком грязным, придется в каждом методе описать функцию постлоЛоада. Проблему решит, но не красиво.

galliard, В каждой сущности добавлять методы для постзагрузки не надо, т.к. в Doctrine есть диспетчер событий, аналогичный Symfony. Вы можете создать один подписчик, в котором проверять все необходимые сущности:

<?php

namespace App\EventSubscriber;

use Doctrine\Common\EventSubscriber;
use Doctrine\ORM\Event\LifecycleEventArgs;
use Doctrine\ORM\Events;

class InvalidEntitySubscriber implements EventSubscriber
{
    public function getSubscribedEvents(): array
    {
        return [ Events::postLoad ];
    }

    public function postLoad(LifecycleEventArgs $args): void
    {
        $entity = $args->getEntity();

        if ($entity instanceof User) {
            if (null === $user->getEmail()) {
                throw new InvalidEntityException();
            }
        }

        // И так для каждой сущности
    }
}

Ну и тег надо добавить:

services:
    App\EventSubscriber\EntityNullValueSubscriber:
        tags: ['doctrine.event_subscriber']

Подробнее см. документацию: https://symfony.com/doc/current/doctrine/event_lis...

Answer 2

[Алексей Скобкин]

Доктрина создает сущности при помощи рeфлексии, в обход конструктора и сеттеров.

С помощью десериализации. (UPD: см. комменты, уже не актуально)

Видимо предполагается, что состояние, хранящееся в БД, всегда валидно. Но так бывает не всегда.

Это ваша задача этого не допускать. Если вы это допустили, ошибки Doctrine - это меньшее, что может вылезти.

Например, в БД есть nullable поле `name`, которое в сущности не должно быть nullable

Ну так может быть стоит привести схему и сущность с маппингом в соответствие друг другу, а не отстреливать симптомы?

public function getName(): string
и если в БД руками проставить null, то ошибка возникает только при запросе этого геттера.

Решается это так:
public function getName(): ?string

Я сначала было хотел вам предложить валидировать данные на входе в сущность (конструктор), но потом читая ваш вопрос дальше, понял, что вы вообще используете Doctrine очень странно и ждёте, что сама Doctrine будет вам предоставлять средства для ухода от возникающих проблем.
Первое и самое важное: Doctrine - это Data Mapper. Если у вас маппинг и сущность не соответствуют схеме - работать ничего нормально не будет. Лечите заболевание, а не симптомы.

Comments

[galliard]

Это ваша задача этого не допускать. Если вы это допустили, ошибки Doctrine - это меньшее, что может вылезти.

Дык я и не допускаю, проблема в том, что есть ещё команда индусов, которая периодически туда срет, и я никак не могу на это повлиять.

Ну так может быть стоит привести схему и сущность с маппингом в соответствие друг другу, а не отстреливать симптомы?

Базу я трогать не могу, а сущности менять не хочу, так как они как раз корректно описывают предметную область.

Решается это так:
public function getName(): ?string

Ну во первых это костыль, во вторых это не корректно с точки зрения предметной обрасти, а в третьих это вообще был абстрактный пример, там есть и более сложные бизнес-правила.

Я сначала было хотел вам предложить валидировать данные на входе в сущность (конструктор)

Я был бы рад, если вы покажете как заставить доктрину использовать конструктор при загрузке данных из БД. Сам я об этом информации не нашел.

вы вообще используете Doctrine очень странно и ждёте, что сама Doctrine будет вам предоставлять средства для ухода от возникающих проблем.
Первое и самое важное: Doctrine - это Data Mapper. Если у вас маппинг и сущность не соответствуют схеме - работать ничего нормально не будет. Лечите заболевание, а не симптомы.

Ну нимагу я этого сделать, это не мой pet-проект, не решаю я такие вопросы. Я могу только купировать эти проблемы в рамках моего микросервиса, что и пытаюсь сделать.

[Алексей Скобкин]

Дык я и не допускаю, проблема в том, что есть ещё команда индусов, которая периодически туда срет, и я никак не могу на это повлиять.

Базу я трогать не могу, а сущности менять не хочу, так как они как раз корректно описывают предметную область.

Тут нужно выбирать. Либо вы устраняете индусов и приводите базу в порядок, либо вы приводите сущности и их маппинг к схеме, которая в базе. Всё остальное - борьба с симптомами и не приведёт ни к чему хорошему.
Возможно индусы вообще являются частью предметной области (раз они есть - значит они нужны бизнесу) и тогда ваши доводы про то, что это ей не соответствует неверны.

Я был бы рад, если вы покажете как заставить доктрину использовать конструктор при загрузке данных из БД. Сам я об этом информации не нашел.

Речь была о валидации данных до записи в БД. В самой же БД они уже должны быть валидны. И ваша проблема не в Doctrine и отсутствии валидации, а в том, что в БД невалидные данные. Бороться надо с этим. Сделайте в БД поле NOT NULL и пусть индусы не кладут туда его. Или же, если не можете, сделайте сущность, которая может работать с NULL.

[galliard]

Алексей Скобкин, индусы были до меня и будут после меня, наверное они важны для бизнеса, не суть важно. Я действую в ограниченном контексте вверенного мне участка работ.

В самой же БД они уже должны быть валидны. И ваша проблема не в Doctrine и отсутствии валидации, а в том, что в БД невалидные данные. Бороться надо с этим.

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

Сделайте в БД поле NOT NULL и пусть индусы не кладут туда его. Или же, если не можете, сделайте сущность, которая может работать с NULL.

Если бы меня устраивал один из этих вариантов - я бы этот вопрос не задавал. Но я хочу найти третий.

[voronkovich]

galliard, А как вашу проблему решит бросок исключения? Вы же не сможете обрабатывать данные.
Может вам лучше фильтр использовать, чтобы исключить сущности с недопустимыми null-значениями. Примерно так, как это делает SoftDeleteable? https://www.doctrine-project.org/projects/doctrine...

[galliard]

voronkovich, а я и не хочу их обрабатывать, я поймаю исключение еррор хендлером и сообщу пользователю о поврежденных данных. Ну и лог запишу. На этом все.

Отображать не полный набор данных в моем случае будет не корректно.

[voronkovich]

galliard, Ну тогда, слушатель postLoad события будет для вас самым простым решением.

[Алексей Скобкин]

С помощью десериализации.

Кстати, если мне не изменяет память, эта пометка уже не актуальна.