Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Doctrine Schema Update Bundle Laravel Package

webtown/doctrine-schema-update-bundle

A Symfony bundle that adds console commands for reviewing and applying Doctrine schema updates, helping you compare mapped entities with the current database and safely generate or execute the SQL needed to bring schemas in sync.

View on GitHub
Deep Wiki
Context7

Getting Started

This bundle does exactly one thing: it removes the doctrine:schema:update console command from the container so nobody on the team can accidentally mutate a database schema outside of a migration. There is no configuration, no services to wire, and no runtime API. Treat it as a guardrail, not a tool.

Minimum steps:

  1. Install via Composer:

    composer require webtown/doctrine-schema-update-bundle
    

    This package predates Symfony Flex (last release March 2016), so expect a Symfony 2.7–3.x era dependency tree. On Symfony 4+ you will need composer require --ignore-platform-reqs tricks at best, and it likely will not boot at all.

  2. Register the bundle manually in app/AppKernel.php:

    public function registerBundles()
    {
        $bundles = [
            new Doctrine\Bundle\DoctrineBundle\DoctrineBundle(),
            new Doctrine\Bundle\MigrationsBundle\DoctrineMigrationsBundle(),
            // ...
            new Webtown\DoctrineSchemaUpdateBundle\WebtownDoctrineSchemaUpdateBundle(),
        ];
    }
    
  3. Confirm the command is gone:

    php app/console list doctrine
    

    You should no longer see doctrine:schema:update. If you still do, the bundle is not registered or a later bundle re-registered the command definition.

First real use case: you have a shared staging database with multiple developers and someone keeps "just syncing" entities with --force. This bundle makes that command disappear. They must now run doctrine:migrations:diff and doctrine:migrations:migrate instead. That's the entire value proposition.

Look first at the bundle's DependencyInjection/Compiler directory — that is where the doctrine.schema_update_command service definition gets removed. Everything else is boilerplate.

Implementation Patterns

Enforce migration-only workflow across environments. The bundle is environment-agnostic — it kills the command everywhere, not just in prod. That's intentional: you want the same command surface in dev, staging, and prod so nobody develops muscle memory for a command that doesn't exist in production.

Pair it with doctrine:migrations:diff in your workflow. Since schema:update is gone, the standard loop becomes:

php app/console doctrine:migrations:diff   # generate version file from entity diff
php app/console doctrine:migrations:migrate

Review the generated migration before committing — the diff tool is not a substitute for thinking about destructive changes.

CI integration. Add a step that asserts the command is actually absent, guarding against a future bundle re-registering it:

php app/console list doctrine | grep -q 'schema:update' && exit 1 || exit 0

This turns the bundle's intent into a testable invariant.

Replacing the command with a friendly message. If you find the bare "command not found" unhelpful, override the definition rather than relying on removal. In a bundle of your own, add a compiler pass that runs after this one:

$container->register('doctrine.schema_update_command', YourFriendlyCommand::class)
    ->addArgument(new Reference('doctrine'))
    ->addTag('console.command');

Now running doctrine:schema:update prints "Use migrations instead" rather than silently missing — much kinder to new hires.

Composer script shortcuts. Wire the migration flow into composer.json scripts so the path of least resistance is the safe one:

"scripts": {
  "db:diff": "php app/console doctrine:migrations:diff",
  "db:migrate": "php app/console doctrine:migrations:migrate --no-interaction"
}

Gotchas and Tips

The project is abandoned. Last release 2016, zero stars, zero dependents. Do not introduce it into a new project expecting maintenance. The entire behavior is ~a dozen lines of a compiler pass — copy the idea into your own AppBundle compiler pass rather than taking the dependency. You get the same guardrail without version-dead code.

Symfony version wall. The 2016-era code targets Symfony 2.x/3.x bundle conventions (AppKernel, Resources/config/services.yml, possibly ContainerAwareCommand). It will not run on Symfony 4+ without porting. If you're on modern Symfony, implement the equivalent as a bundle-less compiler pass registered in Kernel::build():

protected function build(ContainerBuilder $container)
{
    $container->addCompilerPass(new RemoveSchemaUpdateCommandPass());
}

It only removes the command — it does not prevent schema changes. doctrine:schema:create, raw SQL, doctrine:fixtures:load with schema dropping, or an ORM listener can still mutate schema. Treat it as a nudge, not a hard security boundary. Real enforcement belongs in database user permissions.

Service ID brittleness. The compiler pass targets a specific service ID (doctrine.schema_update_command). DoctrineBundle has renamed/moved command services across versions. If you run a newer DoctrineBundle and the command still appears, the ID has drifted — inspect the container (app/console debug:container doctrine | grep schema) and adjust the pass.

Compiler pass ordering. If any bundle registered after this one re-declares the command, removal is undone. Register this bundle last in AppKernel::registerBundles(), or set an explicit priority on your own pass (PassConfig::TYPE_BEFORE_REMOVING).

Migrations bundle is a prerequisite, not a companion. This bundle does not require doctrine/doctrine-migrations-bundle, but disabling schema:update without migrations installed leaves you with no way to sync schema. Install and configure migrations first, verify migrations:status works, then add this bundle.

Debugging a "missing command" surprise. If a CI job or script that used doctrine:schema:update starts failing with "command not defined," that is this bundle working as designed. Grep your scripts, Makefiles, and deploy hooks for schema:update before rollout — the failure mode is silent until somebody runs that path.

Extension point worth knowing. The only customization surface is the compiler pass itself. If you want to block additional commands (e.g. doctrine:schema:drop), fork the pass into your own bundle and add the extra service IDs. There's no config tree to extend.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
uni-method/symfony-lib
tacticmedia/scim-server-bundle
neika-ai/symfony-bundle
mattleads/agent-publishing-bundle
glavweb/framework-bundle
glavweb/extra-bundle
glavweb/api-bundle
glavweb/admin-bundle
adachsoft/api-version-bundle
elsayed85/laravel-api-exceptions
ouhssini/laravel-demo-mode
daworks/ncloud-outbound-mailer-driver
gp247/cms
ignibyte/aic-gates
nexa-merchant/blog
novasa/laravel-language-center
opencage/geocode
adolfoholzer/parameters
livenetworks/ln-starter
shitoudev/permissionmanager