- Is evotodi/seed-bundle compatible with Laravel?
- No. It is a Symfony bundle registered through config/bundles.php and built on Symfony Console commands, the Symfony DI container, and Doctrine ORM, while Laravel ships its own container, Artisan commands, and Eloquent. Installing it in a Laravel app gives you commands that never register and a base Seed class that cannot resolve its injected EntityManager the way it expects. For Laravel you should use native database seeders or a Laravel-specific package instead.
- How do I install and register evotodi/seed-bundle?
- Run composer require evotodi/seed-bundle, then register the bundle in your Symfony config/bundles.php. Optionally map a DataSeeds directory as services in config/services.yaml so your seed classes are auto-wired. After that your seeds appear in bin/console as commands such as seed:user.
- Which Symfony and PHP versions does evotodi/seed-bundle support?
- Version 6.0 requires PHP 8 and Symfony 6 or newer. The README mentions a later update that drops Symfony 6 and adds Symfony 8 support, but that does not clearly match the tagged release history, so verify what is actually installable before depending on it. There is no Laravel version support at all.
- How does seed ordering work and why do tied orders cause problems?
- Seeds are loaded and unloaded in ascending order based on the static getOrder() value, starting at 0. According to the README, multiple seeds sharing the same order load semi-randomly, which is a real correctness hazard, especially when using flags like --from that assume a stable sequence. Assign each seed a unique order value to keep deploys deterministic.
- What is the difference between this bundle and DoctrineFixturesBundle?
- DoctrineFixturesBundle is aimed at development and testing workflows where fixtures are purged and reloaded repeatedly. Evotodi/seed-bundle targets pre-deployment seeding, such as filling reference tables like states and abbreviations or creating initial admin users before the first production push. It adds ordered load and unload semantics and is designed to run once against a real database.
- Is it safe to unload or roll back seed data in production?
- Be careful. The documented unload pattern is a raw DELETE FROM statement that wipes the whole table rather than removing only the rows the seed created, and it is not wrapped in a transaction. A partial failure can leave the table in an inconsistent state. Restrict unload usage to bootstrap scenarios where you can afford a full reset, and take a backup first.
- Why do seeds disable Doctrine logging and how is that done?
- Doctrine's SQL logging keeps every query in memory, which becomes a serious problem when inserting large reference tables. The Seed base class exposes a wrapper method that turns Doctrine logging off for the duration of the seed. Call it at the start of your load method before doing bulk inserts.
- How do I create a custom seed command?
- Create a class extending Evotodi\SeedBundle\Command\Seed. Implement the static seedName() method returning a colon-separated name such as user, which becomes the command seed:user, optionally override the static getOrder() method, and put your insert logic in load(InputInterface $input, OutputInterface $output): int. The seed name must be set or the seed will not load.
- How do I test seed commands?
- The package ships no test helpers, but seeds are ordinary Symfony console commands, so you can drive them with Symfony's CommandTester against a booted kernel pointed at a test database. Assert that the expected rows exist, that running the seed twice does not duplicate data, and that your order values produce the sequence you expect. Avoid running unload tests against anything that resembles production data.
- Is evotodi/seed-bundle actively maintained and what are the alternatives?
- It has a single maintainer, roughly 14 GitHub stars, and no dependents, so there is little ecosystem pressure-testing. Version 6.0 was effectively a rewrite with renamed APIs, a static seedName(), a removed config file, and a PHP 8/Symfony 6 floor, so plan for similar jumps at the next major. The codebase is small, which makes vendoring or forking realistic; alternatives include DoctrineFixturesBundle for dev fixtures, Doctrine migrations, or a handful of custom console commands for one-off production seeding.