Как в Doctrine, в DBAL указать PDO::ATTR_PERSISTENT => true?

Question

[HellWalk]

В тестах получаю ошибку:

[Doctrine\DBAL\Exception\ConnectionException] An exception occurred in driver: SQLSTATE[08006] [7] ВАЖНО: извините, уже слишком много клиентов

Соответственно нужно указать доктрине, чтобы она использовала одно подключение на все запросы. Напрямую через php это делается так:

$connection = new PDO('DSN', 'user', 'password', [PDO::ATTR_PERSISTENT => true]);

Но как указать аналогичный параметр в доктрине?

Comments

[FanatPHP]

не нужно это делать

[HellWalk]

FanatPHP, т.е. вы предлагаете забить на падающие тесты?)

[FanatPHP]

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

Answer 1

[HellWalk]

Проблема с лимитом подключений к базе в тестах решилась добавлением $this->entityManager->getConnection()->close(); в tearDown()

/**
* @throws ConnectionException
*/
public function tearDown(): void
{
    parent::tearDown();
    // ...
    $this->entityManager->getConnection()->close();
}

Забавно, что в официальной документации (с.м. последний пример):
https://symfony.com/doc/current/testing/database.html

Указано:

protected function tearDown(): void
{
    parent::tearDown();

    // doing this is recommended to avoid memory leaks
    $this->entityManager->close();
    $this->entityManager = null;
}

Что, по факту, не помогало решить проблему с лимитом подключений.

Comments

[Максим Федоров]

Что, по факту, не помогало решить проблему с лимитом подключений.

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

честно, сам много с БД тестами работал, не встречал проблем с утечкой подключений... но мы да, часто баловались с одним объектом EM сквозь тесты (надо было, потому подключение формально было одно)

[Максим Федоров]

могу предположить, что это из-за поведения Симфони в части kernel.terminate и finish.request
Ну крч приложение (и подключение) еще живет после овтета

Когда ответ ушел, CGI разорван через fastcgi_finish_request,
а симфа еще дорабатывает разного рода логику (например отправляет письма в режиме Memory Spooling и подобное)

Answer 2

[Максим Федоров]

Ентити-менеджер использует один объект Connection, Connection использует объект PDO, всегда везде одно подключение и работает во всем жизненном цикле приложения, в этом и суть работы (ну в том числе) DI контейнера — отдавать один и тот же объект и не плодить их. То есть на жизненный цикл приложения все и так работает

Тесты функциональные? Может плодится много http запросов в разных процессах? Но если и так — то все равно процессы разные и объекты PDO разные, так что ваша настройка не сработает, тк просто сами приложения будут разные...

Для таких случаев в Codeception есть такая штука как persistService, по идее сервис (в вашем случае EntityManager, если через него работаете, или Connection, если через DBAL работаете) должен один идти через эту штуку единый, даже если разные http запросы
https://codeception.com/docs/modules/Symfony#persi...

Крч, раскройте немного деталей ваших тестов и ситуации, может я все не туда пишу

Comments

[HellWalk]

Сделано все по официальной документации:
https://symfony.com/doc/current/testing/database.html

Последний пример с tearDown

И там видно, что tearDown дергает parent::tearDown(), а там:

static::ensureKernelShutdown();
static::$kernel = null;
static::$booted = false;

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

[HellWalk]

Нашли способ

/**
     * @throws ConnectionException
     */
    public function tearDown(): void
    {
        parent::tearDown();

        //...

        $this->entityManager->getConnection()->close();
    }

[Максим Федоров]

HellWalk,

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

Да, каждый раз новое приложение, именно для таког ов Codeception к примеру и придумали, как сквозь тесты проносить объекты контейнера в случае необходимости (такая необходимость на самом деле редко встречается)

Ваш способ ок, но не совсем ясно, почему он не закрыл соединение, значит php скрипт еще жив был... тк объект подключения удаляется, когда умирает процесс