Даже сущностей нет, просто делаю generate, после migrate и ошибка эта

Код подключения скопировал с другого проекта, тут вообще нечему ломаться по сути, но ошибка странная

Может из-за того что использую последние версии MySQL, doctrine и т.д.?

Может, ответ GPT поможет)))

Ошибка SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 3072 bytes часто возникает при использовании миграций в Symfony (или в любом приложении, которое использует Doctrine для взаимодействия с базой данных) с MySQL, когда создается индекс или первичный ключ, который превышает максимальную допустимую длину. Вот несколько способов решения этой проблемы: ### 1. Измените длину полей Если у вас есть строковые поля, которые участвуют в композитном индексе, попробуйте явно указать их длину. Это может помочь сократить общую длину индекса. // Пример: Аннотируйте поля длиной /** * @ORM\Column(type="string", length=191) */ private $columnName; ### 2. Изменение типа поля Если возможно, попробуйте использовать более короткие типы данных. Например, вместо VARCHAR(255) используйте VARCHAR(191). ### 3. Использование уникальных индексов с ограниченной длиной Если вы определяете уникальный индекс на длинную строку, рассмотрите возможность ограничения длины индекса. Например: $schema->getTable('my_table')->addUniqueIndex(['column_name' => 191]); ### 4. Измените размер страницы в InnoDB Если у вас есть контроль над конфигурацией MySQL, вы можете попробовать увеличить размер страницы InnoDB до 16KB, но это потребует перезапуска сервера MySQL и потенциально изменения конфигурации сервера, что может быть невозможно для некоторых хостинговых сред. SET GLOBAL innodb_page_size=16*1024; ### 5. Обновление версии MySQL В некоторых случаях обновление до более новой версии MySQL может оказаться полезным. Версия 5.7 поддерживает большие размеры индексов, особенно если используется кодировка utf8mb4. ### 6. Использовать utf8 вместо utf8mb4 Если использование полного набора символов utf8mb4 (включая эмодзи) не является необходимым, можно использовать utf8, что уменьшит размер каждого символа. # config/packages/doctrine.yaml doctrine: dbal: charset: utf8 ### 7. Проверьте миграции и запросы Убедитесь, что в миграции SQL команды соответствуют типам данных, поддерживаемым вашей версией MySQL. Общие действия: - Просмотрите все миграции и найдите, где создается большой ключ. - Оптимизируйте схему данных, чтобы ключи были короче. Имейте в виду, что каждый из этих подходов имеет свои плюсы и минусы, и выбор подхода будет зависеть от конкретного контекста вашей задачи и структуры базы данных.

Уже второй день не помогает, первом делом ему пишу

Пробовал этот charset

На другие примеры сущностей нет)

То есть она даже таблицу миграций свою не может создать

Кто нибудь сталкивался с ошибкой при миграции: SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 3072 bytes

Ошибка только на локальной бд?

Только локальную и использую, она внутри контейнера

Только локальную и использую, она внутри контейнера

Попробуй снести нахрен этот контейнер и другой контейнер бд посиавь

Попробуй снести нахрен этот контейнер и другой контейнер бд посиавь

Снести пробовал не раз, могу попробовать версию другую поставить

На 8.0 также

Просто единственное что он пытается создать - таблицу миграций

Да

Там нет длинных полей, больше чем 255 символов

Один файл

А что за драйвер бд в настройках?

pdo_mysql

Версии доктрины все на этапе стабильно

Блин, ну пишут что innodb_large_prefix=true и еще какие-то настройки надо в ini файл прокинуть Но вроде никогда такого не было

Я о том же, сколько использовал не сталкивался с этим

Я о том же, сколько использовал не сталкивался с этим

В официальной доке есть инфа вот такая

Можешь скинуть ссылку

Можешь скинуть ссылку

https://symfony.com/doc/current/doctrine.html

Можешь скинуть ссылку

А слушай

Там есть опция такая - charset

Да есть

Поставь utf8mb4

Указал utf8mb4

Также)

Говно

Согласен

Херня какая-то

А mb3? Оно же поосто utf8

Усеченный вроде, но хз

Без смайликов слышал

Поставил postgres и все работает)

Привет! Подскажите, как юзать symfony/validator за пределами симфони? Создал файл DTO, $userRegisterDto = new UserRegisterDTO(); $validator = Validation::createValidator(); $violations = $validator->validate($userRegisterDto); count($violations); // все время 0

use Symfony\Component\Validator\Constraints as Assert; class UserRegisterDTO { #[Assert\NotBlank] #[Assert\Length(min: 5)] public string $email; }

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

Почитай доку может там написано

use Symfony\Component\Validator\Constraints as Assert; class UserRegisterDTO { #[Assert\NotBlank] #[Assert\Length(min: 5)] public string $email; }

Смотри реализации ValidatorInterface , и в них какие зависимости нужны

Привeт, нyжны 2 чeлoвeкa. Всe c тeлeфoнa или кoмпьютeрa. Oт 220 $ в дeнь. Удaлённaя зaнятocть. Пиши + в ЛC

use Symfony\Component\Validator\Constraints as Assert; class UserRegisterDTO { #[Assert\NotBlank] #[Assert\Length(min: 5)] public string $email; }

Голый валидатор будет работать если ты ему передашь вручную список Constraint

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

Так как в симфе аттрибуты далеко не единственный способ описать валидации и они не могут всунуть все возможные варианты в компонент вадидатора

Если есть проект на симфони проще всего это делать если открыть сгенерированный файл контейнера найти там сервис валидации и посмотреть как он собирается

Если есть проект на симфони проще всего это делать если открыть сгенерированный файл контейнера найти там сервис валидации и посмотреть как он собирается

Спасибо! Покурю тему

Как лучше реализовать i18n на сервере, через файлы с переводами по коду или в бд хранить сам перевод?

Как лучше реализовать i18n на сервере, через файлы с переводами по коду или в бд хранить сам перевод?

Смотря как ты планируешь обновлять перевод

Через админку

Значит через бд

А как еще можно обновлять если есть другой вариант?

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

Но тебе нужен механизм инвалидации кеша

Так же старт приложения обязательно завязывается на запрос в бд

Делать отдельную таблицу «языковые фразы» с полями en ru и т.д., и где нужен текст просто ссылаться на ту таблицу, нормальный вариант?

Или таблицу key | lang | translate

Или таблицу key | lang | translate

О так лучше

Как лучше реализовать i18n на сервере, через файлы с переводами по коду или в бд хранить сам перевод?

Но хранить перевод на клиенте вообще не заинтересован?

Можно, на клиенте стат тексты уже зашиты в json через next-intl по ключу достаю

А тексты статичные или динамические? То есть переводится ui или ещё какие-нибудь статьи?

Типо такого на клиенте

Ну то есть один ui?

Думаешь лучше на клиенте это делать?

Ну то есть один ui?

Да

А зачем тогда в бд хранить?

Хз, раньше такое не делал, поэтому не могу ответить

Т.е. хранить в бд просто ключи а перевод хранить на клиенте?

Позаботься о производительности - храни в файлах проекта. Тебе же новый перевод нужен только тогда, когда ui обновляется/ добавляется Зачем тогда в бд хранить?

Позаботься о производительности - храни в файлах проекта. Тебе же новый перевод нужен только тогда, когда ui обновляется/ добавляется Зачем тогда в бд хранить?

Да перевод нужен когда добавлю или изменяю, но тогда надо пересобираться клиент и править json?

Все таки данные в бд динамичные, а на клиенте переводы статичны, поэтому думал может в бд хранить

Если текст будет формироваться на сервере - то и на клиенте его хранить нет смысла