Data-fixtures: Ошибка усечения таблицы с внешними ключами

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

Хорошо, но проблема с TRUNCATE заключается в том, что команда doctrine: fixtures : load просто НЕ работает.

Если это действительно необходимо, запуск автоматического увеличения с 1 всегда можно выполнить, например, удалив и воссоздав таблицы, верно?

Ага - у меня тоже есть эта проблема. Откат на 91ff6ebbb781441c60782d90a4dd95482eeedf35.

+1 для возврата 91ff6ebbb781441c60782d90a4dd95482eeedf35

Почему бы просто не добавить «КАСКАД» к TRUNCATE? $ platform-> getTruncateTableSQL ($ tbl) имеет второй параметр, который вернет что-то вроде 'TRUNCATE table CASCADE' (по крайней мере, для postgres это так), и с этим он работает.

Как насчет добавления запроса на перенос? Тогда я могу слить это.

@leahaense

Проблема все еще существует при использовании MySQL (даже после 4a8464ef83093de2378cef2770e13da7e4858ffc).

В этом случае ваши внешние ключи двунаправленные или что-то в этом роде?

@beberlei да, я так думаю. Я не уверен на 100%, поскольку SQL генерируется Doctrine из аннотаций один-ко-многим / многие-ко-многим (которые, да, являются двунаправленными).

У кого-нибудь еще есть эта проблема с MySQL? Или это только у меня?

Можете ли вы сделать foreign_key_checks = 0 перед TRUNCATE?

http://bugs.mysql.com/bug.php?id=58788

Я тоже сталкиваюсь с этой проблемой

Я столкнулся с той же проблемой с моим партнером, это действительно происходит в MySQL 5.5, в то время как 5.1 отлично справляется с усечением таблиц с внешними ключами. Возврат к DELETE не был бы элегантным решением, как указывалось ранее, когда ключи auto_increment не сбрасываются.

Было бы неплохо, если бы могло быть исправление, например, foreign_key_checks = 0 для mysql 5.5

http://bugs.mysql.com/bug.php?id=54678

Вот быстрый грязный прием, чтобы заставить его работать с MySQL 5.5.

diff --git a/lib/Doctrine/Common/DataFixtures/Purger/ORMPurger.php b/lib/Doctrine/Common/DataFixtures/Purger/ORMPurger.php
index a580c1f..ff758c1 100644
--- a/lib/Doctrine/Common/DataFixtures/Purger/ORMPurger.php
+++ b/lib/Doctrine/Common/DataFixtures/Purger/ORMPurger.php
@@ -82,10 +82,12 @@ class ORMPurger implements PurgerInterface
             $orderedTables[] = $class->getTableName();
         }

+       $this->em->getConnection()->executeUpdate("SET foreign_key_checks = 0;");
         $platform = $this->em->getConnection()->getDatabasePlatform();
         foreach($orderedTables as $tbl) {
             $this->em->getConnection()->executeUpdate($platform->getTruncateTableSQL($tbl, true));
         }
+       $this->em->getConnection()->executeUpdate("SET foreign_key_checks = 1;");
     }

     private function getCommitOrder(EntityManager $em, array $classes)

Вышеупомянутое исправление отлично подходит для меня. Есть идеи, когда можно было бы внести исправление в репо, чтобы мне не приходилось все время менять его вручную?

Мне также пришлось добавить это исправление, чтобы использовать пакет.

Вышеупомянутое исправило это для меня (насколько я могу судить, все еще изучаю Doctrine / Symfony2)

Я внес изменения foreign_key_checks в MySqlPlatform в самом проекте DBAL всего через несколько минут после того, как @mdarse отправил свой запрос на

https://github.com/doctrine/dbal/pull/42

Та же проблема на моей машине с MySQL 5.5.9, но взлом dogbrain помог.

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

Это не «исправление», это взлом. Я не буду сливать хак.

Хорошо ... достаточно честно. Тем не менее, это хак, который позволяет приборам работать, и было бы неплохо, если бы они работали;)
Если это не может быть объединено, можно ли исправить это? В противном случае есть ошибка, которая делает этот пакет непригодным для многих людей (без постоянного ручного взлома его кода каждый раз, когда делается обновление)

@beberlei?

Можем ли мы отменить изменение 91ff6eb, чтобы решить эту проблему?

Таким образом, это не будет взломом. Это было предложено в первом посте этого номера.

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

"require": {
    "doctrine/doctrine-fixtures-bundle": "dev-master"
},

В любом случае, чтобы получить сброс индекса, мне нужно запустить « doctrine: schema : drop --force», а затем « doctrine: schema : update --force» перед перезагрузкой. В противном случае у меня такая же ошибка. Может ли кто-нибудь сказать мне, что я делаю не так?
Заранее спасибо.

У меня такая же проблема с последней версией доктрин и Mysql 5.5. «Хак» сработал, но это не портативное решение. Мне приходится каждый раз отбрасывать схему и воссоздавать ее.

Сделайте себе одолжение и создайте сценарий внутри папки Symfony, например load_fixtures :

bin/console doc:sc:drop --force
bin/console doc:sc:cr
bin/console doc:fix:lo --no-interaction

Запустите chmod 755 load_fixtures а затем ./load_fixtures.