croensch
commented
2 years ago I initially picked up and rebased this PR to revive or end the discussion around this problem. Now that i looked into it, i understand a few things better:
- The ORMPurger touches all tables anyway, so for MySQL where the TRUNCATE is a drop/re-create internally, it should theoretically not be much faster than the current workaround of running the drop & create commands. Still, it would be nice if this feature just works on MySQL too.
- In AliceDataFixtures they implemented a fix referencing the original PR. We should not break that, i don't think it does, but it got me thinking... https://github.com/theofidry/AliceDataFixtures/blob/master/src/Bridge/Doctrine/Purger/Purger.php
- So i like how DBUnit restores the variables state, perfectly fine pattern to be least-invasive. https://github.com/sebastianbergmann/dbunit/blob/master/src/Operation/Truncate.php
- In DBUnit but also this PR i don't like how it's done around every TRUNCATE statement as it may spam the logger. I would rewrite it to call a method (like in DBUnit) before and after the tables loop.
- I still think it's a good idea to sniff the connection instead of the platform since only
AbstractMySQLDriveris the same since 3.0 while theAbstractMySQLPlatformis only available since DBAL 3.3, but3.0is the minimum dependency.
So would you mind if i rewrite it to address all this? In the same PR?
greg0ire
For your consideration, see #272. I don't know if the discussion was a yes/no to this feature.
I can push a little refactor of
getTruncateTableSQL()to make it fit better.