Грабли: andWhere( id != ?, null)

Простой код

$id=null;

    $q=Doctrine_Query::create()
      ->from('sfGuardUser u')
      ->andWhere('u.id != ?',$id);
      
    print_r($q->fetchArray());

Дает совершенно неожиданные результаты:

1. SQL-запрос составляется правильный (в этом можно убедиться в дебаг-панели и в логах)

2. Результат (массив или коллекция) всегда будут пустыми.

Решение:

->andWhere('u.id != ?',(int)$id);

Вот уж не думал, что надо приводить типы в prepare_sql Доктрины!

Делаем "Направленный список чего-нибудь"

Заказчиком была поставлена следующая задача: сделать возможность создавать направленные списки (списки, в которых порядок следования элементов имеет значение), состоящие из произвольных объектов любых моделей проекта. Практическое применение: вывести в определенной последовательности 5 товаров, потом еще 10 товаров (в другой последовательности), затем 7 категорий товаров, и, наконец, 12 новостей (тоже в заранее заданной последовательности). Назовем этот список "рейтингом". Ниже представлена концепция с основными моментами реализации.

Грабли: таблицу удалили (переименовали), а она все равно создается

Если вы переименовали или удалили какую-то модель (таблицу) в доктрина-схеме, а при следующем doctrine:build эта таблица все равно создается, то надо почистить старые классы моделей (они не удаляются автоматически при изменении схемы):

symfony doctrine:clean-model-files

Обрабатываем большую коллекцию по частям

Не секрет, что гидрация в объекты большого количества записей занимает много ресурсов (времени). Поэтому если вам надо вытащить Доктриной большое количество записей, и обработать их, то первый шаг к оптимизации - вытаскивать коллекцию не всю сразу, а кусочками. Примерно вот так

Грабли: каскадное удаление в refClass'e

Чтобы избежать mysql-ошибок CONSTRAINTS при удалении/обновлении записей, которые связаны с другими связями многие-ко-многим, не забывайте прописывать каскадное удаление в ref-классах:

  relations:
    AAA:
      onDelete: CASCADE
    BBB:
      onDelete: CASCADE

Грабли: очередность загрузки фикстур

Если в папке с фикстурами лежат несколько файлов, то они обрабатываются все сразу, а по очереди. Это надо учитывать, когда создаются связи между записями в разных файлах!
Легко натолкнуться на ситуацию, когда связь не будет создана только потому, что объекта, с которым она связывает, еще нет в БД, и он неизвестен Доктрине: она до него еще просто не дошла.

Стоит отметить, что в пределах одного файла такой проблемы нет.

Symfony: храним i18n-фразы в mysql

Как сделать так, чтобы фразы выводящиеся в шаблонах, можно было редактировать через админку? Для этого нужно сделать несколько простых, но совершенно неочевидных шагов (по большей части решения были найдены методом научного тыка и копания исходников).

Грабля: ругается, что такая запись уже есть в БД

Проблема: при редактировании объекта и отправке формы Доктрина ругается, что

An object with the same "email" already exist

при том, что мы совешенно уверены, что такой email в базе ровно один - у редактируемого объекта. В чем дело? Если случилось так, что форма редактирования объекта содержит embedded-форму, то скорее всего проблема в следующем.

Грабли: SQLSTATE[HY000]: General error: 1005 Can't create table

Mysql server version: 5.1.40-community
если при составлении схемы была допущена ошибка, которая привела к General error: 1005 при установке CONSTRAINTS (например примари ключ и внешний ключ имеют разные типы), то есть вероятность, что даже после исправления схемы она не сможет создаться: та же ошибка. Это связано с тем, что предыдущие, неправильно связанные таблицы, не могут удалиться: мешает кривой CONSTRAINTS. Решение одно: дропнуть БД (ну или бинарные файлы таблиц).

Лично я столкнулся с этой проблемой, когда в симфонии 1.4 случайно использовал sfDoctrineGuardPlugin из ветки 1.2. Выдалась ошибка. Заменил плагин, ошибка осталась. Удалил руками бинарники, пересобрал таблицы - все ок.

General error: 1451 Cannot delete or update a parent row: a foreign key constraint fails

Почему при удалении записи возникает SQL-ошибка?

General error: 1451 Cannot delete or update a parent row: a foreign key constraint fails ... 

Потому что при удалении в БД объекты все еще связаны. И поэтому их надо развязать на уровне приложения перед удалением. В методе delete модели нужно добавить отвязку:

  $this->unlink('Tickets',$this->Tickets->getPrimaryKeys(),true);

Это требуется только при наличии связи many-to-many. При других типах связей вполне справляется onDelete: CASCADE. Обратите внимание на третий аргумент (true). Он указывает на то, что unlink надо сделать немедленно, а не помечать связи как "подлежащие удалению".