voronkovich

Сборку фронтенда лучше делать локально. Я, например, обычно для таких вещей использую Ansible.

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

#!/bin/sh

# Создание временной директории
cd "$(mktemp --directory)";

# Клонирование репозитория во временную директорию
git clone https://github.com/symfony/demo .;

# Извлечение ветки для релиза
git checkout master;

# Установка зависимостей фронтенда
npm install

# Сборка фронтенда
node_modules/.bin/encore production

# Загрузка кода из временной директории на сервер при помощи rsync

# Остальные действия производятся уже на сервере

Я повторил ваши шаги на чистой установке. Всё работает нормально.

1. Попробуйте очистить кэш: rm -rf var/cache.

2. В Symfony есть несколько команд для отладки подобных ошибок:

$ bin/console debug:config

$ bin/console debug:config gesdinet_jwt_refresh_token

Посмотрите, что они выведут.

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

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);
}

Вам нужно создать расширение для Twig и реализовать функцию там. См. https://twig.symfony.com/doc/2.x/advanced.html#id2

Попробую привести очень примитивный пример. Допустим, мы делаем простое приложение для микроблоггинга. Каждая сущность будет иметь вид:

class Tweet
{
    private $id;
    private $content;

    public function __construct(int $id, string $content)
    {
        $this->id = $id;
        $this->content = $content;
    }

    public function getId(): int
    {
        return $this->id;
    }

    public function getContent(): string
    {
        return $this->content;
    }

    public function setContent(string $content): void
    {
        $this->content = $content;
    }
}

Схема данных:

CREATE TABLE tweets (
    id INTEGER PRIMARY KEY,
    content VARCHAR(255) NOT NULL
)

Следующая реализация UnitOfWork будет иметь несколько ограничений:

1. Она умеет работать только с Tweet;
   
2. Она умеет только загружать сущности и сохранять произведённые в них изменения.
   

class UnitOfWork
{
    private $connection;
    private $identityMap;
    private $data;

    public function __construct(\PDO $connection)
    {
        $this->connection = $connection;
        $this->identityMap = [];
        $this->data = [];
    }

    public function find(int $id): Tweet
    {
        if (isset($this->identityMap[$id])) {
            return $this->identityMap[$id];
        }

        $query = $this->connection->prepare('SELECT * FROM tweets WHERE id = ?');
        $query->execute([ $id ]);

        if (false === $data = $query->fetch()) {
            throw new \Exception(\sprintf('Tweet with id "%d" not found.', $id));
        }

        $id = (int) $data['id'];

        // Исходные данные сохраняются для того, чтобы в дальнейшем вычислить изменения.
        $this->data[$id] = $data;

        $tweet = new Tweet($id, $data['content']);

        $this->identityMap[$id] = $tweet;

        return $tweet;
    }

    public function commit(): void
    {
        // Вообще говоря, лучше вычислить все изиенения, создать один "большой" запрос
        // и выполнить его внутри транзакции, но для простоты мы сделаем для каждого
        // изменения отдельный запрос
        $query = $this->connection->prepare('UPDATE tweets SET content = ? WHERE id = ?');
        foreach ($this->identityMap as $tweet) {
            if ($tweet->getContent() !== $this->data[$tweet->getId()]['content']) {
                $query->execute([ $tweet->getContent(), $tweet->getId() ]);
            }
        }
    }
}

Полный пример можете скачить и посмотреть тут: https://gist.github.com/voronkovich/d35cdcdf6eb09e...

Можно попробовать определить отдельный интерфейс для "команд":

<?php

namespace App;

interface CommandHanderInterface
{
    public function __invoke(object $message): void;
}

И создать собственную реализацию HandleMessageMiddleware:

<?php

namespace App;

class HandleMessageMiddleware implements MiddlewareInterface
{
    private $messageHandlerResolver;

    public function __construct(HandlerLocatorInterface $messageHandlerResolver)
    {
        $this->messageHandlerResolver = $messageHandlerResolver;
    }
    
    function handle($message, callable $next)
    {
        $handler = $this->messageHandlerResolver->resolve($message);

        if (!$handler instanceof CommandHandlerInterface) {
            throw new InvalidHandlerException('Handler must implement CommandHandlerInterface.');
        }

        $result = $handler($message);
        $next($message);

        return $result;
    }
}

Аналогично сделать для "запросов".

UPD. Возможно, лучше просто сделать два middleware и "прицепить" к соответствующим шинам:

class CommandMiddleware implements MiddlewareInterface
{
    public function handle($message, callable $next)
    {
         if (null !== $next($message)) {
             throw new ReturningValueForbiddenException($message);
         }
    }
}

class QueryMiddleware implements MiddlewareInterface
{
    public function handle($message, callable $next)
    {
         if (null === $result = $next($message)) {
             throw new ReturningValueRequiredException($message);
         }

         return $result;
    }
}

Оба способа правильные. Просто второй более устойчив к CSRF-атакам. Например, компонет форм по умолчанию использует имя класса формы для поля "intention" ("ключевое слово", если использовать ваше определение): https://github.com/symfony/form/blob/a0386553fabb5...

С другой стороны, есть мнение, что использование различных токенов, не делает приложение более безопасным. См. https://github.com/symfony/symfony/issues/18115

Лично я использую первый вариант т.е. один токен на все приложение.

Вы запрос неправильно составляете. Должно быть примерно так (полагаю, у вас сконфигурирована связь @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

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

$client = self::createClient();

$client->setServerParameter('HTTP_HOST', 'symfony-test');

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

Лучше всего использовать очереди типа beanstalkd и ему подобные.

Олдскульный вариант. Если файлов несколько сотен, их можно обработать, запуская процессы параллельно по 10-50 штук, в зависимости от количества оперативной памяти (fork/exec/wait). Для этого можно использовать библиотеку, наподобии spatie/async.

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

• Указывать значение по умолчанию в сущности необходимо, т.к. сущность всегда должна быть валидна;
  
• Указывать значение по умолчанию для столбца тоже необходимо, т.к. бывают случаи когда приходится работать с "голым" 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;
}

В простейшем случае, вы можете вынести обработку OPTIONS в отдельный метод:

<?php

namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Annotation\Route;

/**
 * @Route("/blog")
 */
class BlogController extends AbstractController
{
    /**
     * @Route("/", methods="OPTIONS")
     */
    public function options(Request $request): Response
    {
        $response = new Response();

        $response->headers->set('Access-Control-Allow-Methods', 'OPTIONS, GET');

        return $response;
    }

    /**
     * @Route("/", methods="GET", name="blog_index")
     */
    public function index(Request $request): Response
    {
        return $this->json([
            'message' => 'hello',
        ]);
    }
}

1. Создаете директорию для бандлов (например, bundles как предлагает Максим Федоров)

2. Создаете директорию бандла. Например, bundles/AcmeBundle

3. В composer.json добавляете:

"autoload": {
    "psr-4": {
        "App\\": "src/",
        "AcmeBundle\\": "bundles/AcmeBundle/"
    },
}

4. В директории бандла создаете его класс:

<?php

namespace AcmeBundle;

use Symfony\Component\HttpKernel\Bundle\Bundle;

class AcmeBundle extends Bundle
{
}

5. Регистрируете бандл в файле config/bundles.php:

return [
    Symfony\Bundle\FrameworkBundle\FrameworkBundle::class => ['all' => true],
    AcmeBundle\AcmeBundle::class => ['all' => true],
];