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

5.4

А почему не хотите User implements UserInterface?

не понял

а что в этом костыльного ?

В сущность юзера добавляются какие то стремные методы

то есть а 100500 ненужных астракция это не стремно ?

Это же не костыль, а базовая функция, ибо все функции symfony по вытаскиванию юзера ожидает что вернутся интрефейс же.... По крайней мере в 6 версии почти везде так

не надо мешать явно доменную сущность и аутентификацию

дак вот мне непонятно почему maker при создании других ентити при связи с User ставит ее в ожидание а не интерфейс, хотя User имплементит интерфейс и мейкер должен это был увидеть

никогда не использовал мейкер и теперь точно не буду

https://symfony.com/doc/current/security.html#loading-the-user-the-user-provider

это настроено

это ж быренько наговнякать, а потом некоторые думают, что это лучшие практики

UserProvider напрямую тянет сущность?

вот так сюрприз сюрприз, maker не бест практис, мой мир никогда не будет прежним ((

Предложу такой вариант. Делаешь UserProvider который возвращает не сущность а отдельный класс юзера для аутентификации

добрый день, симфонисты, столкнулся с такой штукой: есть у меня ентити User, есть ентити Project у которого есть связь #[ORM\ManyToOne(targetEntity: User::class, inversedBy: 'projects')] мейкер всё сам сделал и настроил метод public function setUser(?User $user): self и все бы хорошо но когда я решил сделать ProjectDataPersister (у меня ApiPlatform) притащил через DI Symfony\Component\Security\Core\Security и вызвал его чтобы получить $this->security->getUser() который затем отдать в $data->setUser($this->security->getUser()); и оно даже работает.... но... шторм ругается потому что секурити возвращает UserInterface а setUser ждет ентити class User implements UserInterface как это правильно починить?

$user = $security->getUser() if (!$user instanceof User) { throw new ... // User not instance of User logic } $project->setUser($user);

реализаций UserInterface может быть сколько угодно, но могут быть участки кода в которые умеют работать с определёнными/разными/всеми и т.д

будет работать до тех пор пока в голову не стукнет использовать метод или свойство которого нет в UserInterface

нет, даже в этом случае будет работать

пока один user provider

class User implements UserInterface, PasswordAuthenticatedUserInterface зачем в доке такому учат, непонятно

https://symfony.com/doc/current/security/user_providers.html

Всем привет. Знает кто-нибудь как можно исправить генерацию миграции доктрины, когда используешь mysql? Появляется лишняя строчка запроса в секции down с изменением кодировки таблицы, не до конца понимаю. И при чем с каждой генерацией он предыдущую табличку хочет поменять. Код: https://pastebin.com/TBZwPuUS

почему думаешь что он не нужен? что показывает DDL этой таблицы в БД?

Вот структура таблицы в БД. Не сильно понимаю, что подразумевает "DDL этой таблицы". https://pastebin.com/jZAHRTpT

как будто бы где-то в ранних миграциях были какие-то правки и они отсутствуют в down вот он их и принес, не может же он выдумать команды для down значит после анализа прошлых миграций он нашел что-то такое из-за чего решил написать такой down

Я вообще ничего не менял от миграции к миграции. Я начал новый проект, затем создавал сущности и генерил миграцию. Затем опять новые сущности и миграция. И вот на второй и последующей миграции он хочет в down изменить предыдущие таблицы. Хотя опять же я ничего не изменял в маппингах, а просто добавлял (сущности, колонки, связи). Я вот думаю может есть какой-то пункт в конфиге доктрины, где можно было бы указать про кодировку. Но не могу найти(

если проект прям совсем новый и до прода не дошел, тогда проще грохнуть все миграции и снова сгенерить но уже в виде одного файла, профит

а сами миграции корректировали после накатывания? ещё можно почистить кэш попробовать

Я обычно на постгресе работал просто, там такой херни не было

ну там есть CREATE SCHEMA public, но вопрос решаемый)

rm -rf var/cache && bin/console doctrine:migrations:diff

Я вообще ничего не менял от миграции к миграции. Я начал новый проект, затем создавал сущности и генерил миграцию. Затем опять новые сущности и миграция. И вот на второй и последующей миграции он хочет в down изменить предыдущие таблицы. Хотя опять же я ничего не изменял в маппингах, а просто добавлял (сущности, колонки, связи). Я вот думаю может есть какой-то пункт в конфиге доктрины, где можно было бы указать про кодировку. Но не могу найти(

doctrine: dbal: default_table_options: charset: utf8 collate: utf8mb4_unicode_ci

Стал ловить похожее поведение. У меня symfony 6, php 8.1 Тоже докер. Причем, раньше не было такого, на 5 версии. Решение так и не нашел, смирился. Вычищаю от мусора миграции =(

Я сейчас тоже вычищаю ручками. Но блин такое себе это дело(