orm:schema-tool:update always generates sql with no changes? #6672

Closed
opened 2026-01-22 15:36:47 +01:00 by admin · 3 comments
Owner

Originally created by @FLasH3r on GitHub (Apr 1, 2021).

New to Doctrine.
Using "doctrine/orm": "^2.8" in my composer.json

created a basic "Page" entity

<?php

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="pages")
 */
class Page {

    /**
     * @ORM\Id
     * @ORM\Column(type="bigint",options={"unsigned"=true})
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\Column(type="string")
     */
    protected $title;

    /**
     * @var \DateTime
     * @ORM\Column(type="datetime", columnDefinition="timestamp default current_timestamp")
     */
    protected $createdAt;

    /**
     * @var \DateTime
     * @ORM\Column(type="datetime", nullable=true, columnDefinition="timestamp on update current_timestamp")
     */
    protected $updatedAt;

    // ... more implementation here
}

when running

./vendor/bin/doctrine orm:schema-tool:create --dump-sql

I get:

CREATE TABLE content_pages
  (
     id        BIGINT UNSIGNED auto_increment NOT NULL,
     title     VARCHAR(255) NOT NULL,
     createdat TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
     updatedat TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
     PRIMARY KEY(id)
  )
DEFAULT CHARACTER SET utf8
COLLATE `utf8_unicode_ci`
engine = innodb; 

Which is what I want, so I run it without --dump-sql, the table is created and all is good.

But, if I add any field, to any other entity (or even the same one)

Running this:

./vendor/bin/doctrine orm:schema-tool:update --dump-sql

Always return this:

ALTER TABLE content_pages
  CHANGE createdat createdat TIMESTAMP DEFAULT CURRENT_TIMESTAMP; 

Even if I didn't touched it.

Am I missing something here?

This is how I set things up:

use Doctrine\ORM\Tools\Setup;
use Doctrine\ORM\EntityManager;

$paths = [__APP.'/Entitites'];
$isDevMode = false;
$proxyDir = null;
$cache = null;
$useSimpleAnnotationReader = false;

$dbParams = [
    'driver'   => 'pdo_mysql',
    'host'     => 'mysql',
    'port'     => 3306,
    'user'     => 'root',
    'password' => 'root',
    'dbname'   => 'mydb',
];

$config = Setup::createAnnotationMetadataConfiguration($paths, $isDevMode, $proxyDir, $cache, $useSimpleAnnotationReader);
$entityManager = EntityManager::create($dbParams, $config);
Originally created by @FLasH3r on GitHub (Apr 1, 2021). New to Doctrine. Using `"doctrine/orm": "^2.8"` in my `composer.json` created a basic "Page" entity ``` <?php use Doctrine\ORM\Mapping as ORM; /** * @ORM\Entity * @ORM\Table(name="pages") */ class Page { /** * @ORM\Id * @ORM\Column(type="bigint",options={"unsigned"=true}) * @ORM\GeneratedValue(strategy="AUTO") */ protected $id; /** * @ORM\Column(type="string") */ protected $title; /** * @var \DateTime * @ORM\Column(type="datetime", columnDefinition="timestamp default current_timestamp") */ protected $createdAt; /** * @var \DateTime * @ORM\Column(type="datetime", nullable=true, columnDefinition="timestamp on update current_timestamp") */ protected $updatedAt; // ... more implementation here } ``` when running `./vendor/bin/doctrine orm:schema-tool:create --dump-sql` I get: ``` CREATE TABLE content_pages ( id BIGINT UNSIGNED auto_increment NOT NULL, title VARCHAR(255) NOT NULL, createdat TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updatedat TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY(id) ) DEFAULT CHARACTER SET utf8 COLLATE `utf8_unicode_ci` engine = innodb; ``` Which is what I want, so I run it without `--dump-sql`, the table is created and all is good. But, if I add any field, to any other entity (or even the same one) Running this: `./vendor/bin/doctrine orm:schema-tool:update --dump-sql` Always return this: ``` ALTER TABLE content_pages CHANGE createdat createdat TIMESTAMP DEFAULT CURRENT_TIMESTAMP; ``` Even if I didn't touched it. Am I missing something here? This is how I set things up: ``` use Doctrine\ORM\Tools\Setup; use Doctrine\ORM\EntityManager; $paths = [__APP.'/Entitites']; $isDevMode = false; $proxyDir = null; $cache = null; $useSimpleAnnotationReader = false; $dbParams = [ 'driver' => 'pdo_mysql', 'host' => 'mysql', 'port' => 3306, 'user' => 'root', 'password' => 'root', 'dbname' => 'mydb', ]; $config = Setup::createAnnotationMetadataConfiguration($paths, $isDevMode, $proxyDir, $cache, $useSimpleAnnotationReader); $entityManager = EntityManager::create($dbParams, $config); ```
admin closed this issue 2026-01-22 15:36:48 +01:00
Author
Owner

@beberlei commented on GitHub (Apr 1, 2021):

This is probably caused by the options={unsigned: true}, which is not very well supported in the Schema compare sadly.

@beberlei commented on GitHub (Apr 1, 2021): This is probably caused by the options={unsigned: true}, which is not very well supported in the Schema compare sadly.
Author
Owner

@FLasH3r commented on GitHub (Apr 1, 2021):

This is probably caused by the options={unsigned: true}, which is not very well supported in the Schema compare sadly.

But the update CLI call doesn't refer to it at all...

if I remove it like so:

    /**
     * @ORM\Id
     * @ORM\Column(type="bigint")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

I still get the createdAt alter query when I run:

./vendor/bin/doctrine orm:schema-tool:update --dump-sql

ALTER TABLE content_pages
  CHANGE id id BIGINT auto_increment NOT NULL,
  CHANGE createdat createdat TIMESTAMP DEFAULT CURRENT_TIMESTAMP; 
@FLasH3r commented on GitHub (Apr 1, 2021): > This is probably caused by the options={unsigned: true}, which is not very well supported in the Schema compare sadly. But the update CLI call doesn't refer to it at all... if I remove it like so: ``` /** * @ORM\Id * @ORM\Column(type="bigint") * @ORM\GeneratedValue(strategy="AUTO") */ protected $id; ``` I still get the `createdAt` alter query when I run: `./vendor/bin/doctrine orm:schema-tool:update --dump-sql` ``` ALTER TABLE content_pages CHANGE id id BIGINT auto_increment NOT NULL, CHANGE createdat createdat TIMESTAMP DEFAULT CURRENT_TIMESTAMP; ```
Author
Owner

@beberlei commented on GitHub (Apr 1, 2021):

Oh sorry, i didn't see the columnDefinition's. These will always cause the changes, there is no way around it. We can't compare this against the current state.

That is a downside of diff-based schema changes, because its very hard to make both different sides into a single datastructure.

That is why usually you would use something like Doctrine Migrations, Liquibase or DB Deploy for SQL migrations.

Sorry :-(

@beberlei commented on GitHub (Apr 1, 2021): Oh sorry, i didn't see the columnDefinition's. These will always cause the changes, there is no way around it. We can't compare this against the current state. That is a downside of diff-based schema changes, because its very hard to make both different sides into a single datastructure. That is why usually you would use something like Doctrine Migrations, Liquibase or DB Deploy for SQL migrations. Sorry :-(
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#6672