voronkovich

На мой взгляд их лучше не использовать вообще.

1. Эта идея была взята из Hibernate. Но, Java позволяет в последствии сделать дозагрузку данных которые не были загружены изначально. Т.е. использование partial objects не может привести к ошибке. В PHP у объектов нет API аналогичного Java. У меня есть подозрение, что именно поэтому partial objects будут убраны из Doctrine 3, как это стало с поддержой операций detach/merge.

2. Реализация partial objects в Doctrine противоречит принципу "Модель всегда должна быть валидна"

Кстати, вы забыли про вариант с использование легковесного DTO (см. паттерн Flyweight), вместо массивов. См. https://www.doctrine-project.org/projects/doctrine...

Когда можно использовать массивы?

Массивы легко сериализуются, например, с ними можно быстро сделать API:

public function api(EntityManagerInterface $entityManager): Response
{
    $posts = $entityManager->createQuery('SELECT p FROM App\Entity\Post p')->getArrayResult();

    return new JsonResponse($posts);
}

Вы запрос неправильно составляете. Должно быть примерно так (полагаю, у вас сконфигурирована связь @ManyToOne между Employee и Department):

SELECT MAX(employee.salary)
FROM AppBundle:Employee employee
JOIN employee.department department
WHERE department.id = :id

Можно сделать без доп. соединения, если использовать DQL-функцию IDENTITY:

SELECT MAX(employee.salary)
FROM AppBundle:Employee employee
WHERE IDENTITY(employee.department) = :id

Я бы использовал оба способа одновременно:

• Указывать значение по умолчанию в сущности необходимо, т.к. сущность всегда должна быть валидна;
  
• Указывать значение по умолчанию для столбца тоже необходимо, т.к. бывают случаи когда приходится работать с "голым" SQL.
  

<?php

namespace App\Entity;

/**
 * @Entity
 */
class User
{
    const DEFAULT_ROLE = 'user';

    /**
     * @Column(type="string", options={"default": User::DEFAULT_ROLE})
     *
     * @var string
     */
    private $role = self::DEFAULT_ROLE;
}

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!);
        }
        
         // ...
    }
}

Там имеется ввиду выставить data_class, для поля cover. Посмотрите сюда: https://github.com/symfony/symfony/blob/833909bd68...

Видите, там data_class выставляется в Symfony\Component\HttpFoundation\File\File

Попробуйте так:

->add('cover', FileType::class, [ 'data_class' => null ])

UPD: И вообще вы неправильно загрузку делаете. См. здесь https://symfony.com/doc/current/controller/upload_...

В представленном коде должно затираться свойство fileName, т.к. оно у вас указано в форме TaskType. Вообще говоря, в него должен сохраняться экземпляр UploadedFile (или null если поле не было заполнено при отправке формы), а у вас в аннотации указано, что это строковое поле.

Вам не нужно делать "мэппинг" поля с файлом в сущность (укажите 'mapped' => false):

public function buildForm(FormBuilderInterface $builder, array $options)
{
    $builder
        ->add('taskName',TextType::class)
        ->add('file', FileType::class, [ 'mapped' => false, 'label' => 'Документ'])                
    ;
}

Экземпляр UploadedFile можно получить вручную:

$uploadedFile = $form['file']->getData();

$fileName = 'myfile.txt';

$uploadedFile->move('public/uploads', $fileName);

$task->setFileName('public/uploads/'.$fileName);

Доктрина не умеет делать соединение внутри DELETE т.к. это не поддерживается всеми производителями БД. Например, это не умеет SQLite: https://www.sqlite.org/lang_delete.html

На мой взгляд, лучшее, что вы можете сделать - переписать запрос на DQL для удобочитаемости. Вам точно нужны конструкции вида: $qb->expr()->neq?

Translatable behavior extension for Doctrine 2

Виталий Сорокин, Ответы здесь:
https://github.com/doctrine/doctrine2/blob/master/...
https://github.com/doctrine/doctrine2/blob/master/...

/**
 * Only flushes the given entity according to a ruleset that keeps the UoW consistent.
 *
 * 1. All entities scheduled for insertion, (orphan) removals and changes in collections are processed as well!
 * 2. Read Only entities are skipped.
 * 3. Proxies are skipped.
 * 4. Only if entity is properly managed.
 *
 * @param object $entity
 *
 * @return void
 *
 * @throws \InvalidArgumentException
 */
private function computeSingleEntityChangeSet($entity)

Фильтры доктрины в данном случае использовать не стоит. Если проект учебный, можете посмотреть этот пулл-реквест. Там как раз "учебная" реализация.