DDC-625: orm:schema-tool:update --dump-sql showing SQL when DB is up-to-date #773

New Issue

admin · 2026-01-22T12:49:58+01:00

admin commented

2026-01-22 12:49:58 +01:00

Originally created by @doctrinebot on GitHub (Jun 3, 2010).

Originally assigned to: @beberlei on GitHub.

Jira issue originally created by user darkangel:

With the following entities ...
\


/****
 * @Entity
 * @Table(name="users")
 */
class App*Model*User
{
    /****
     * @Id
     * @GeneratedValue(strategy="IDENTITY")
     * @Column(type="integer")
     */
    private $id;

    /****
     * @ManyToOne(targetEntity="App*Model*Role")
     * @JoinColumn(name="role_id", nullable=false)
     */
    private $role;

    /*** @Column(type="string", columnDefinition="CHAR(64) NOT NULL") **/
    private $password;
}

<?php

/****
 * @Entity
 * @Table(name="roles")
 */
class App*Model*Role
{
    /****
     * @Id
     * @GeneratedValue(strategy="IDENTITY")
     * @Column(type="smallint")
     */
    private $id;
}```

I'm getting this output from orm:schema-tool:update --dump-sql, when the database is already up-to-date:

```ALTER TABLE users CHANGE password password CHAR(64) NOT NULL;
ALTER TABLE users DROP FOREIGN KEY users*ibfk*1;
ALTER TABLE users ADD FOREIGN KEY (role_id) REFERENCES roles(id)```

Originally created by @doctrinebot on GitHub (Jun 3, 2010). Originally assigned to: @beberlei on GitHub. Jira issue originally created by user darkangel: With the following entities ...\ \ `````` <?php /**** * @Entity * @Table(name="users") */ class App*Model*User { /**** * @Id * @GeneratedValue(strategy="IDENTITY") * @Column(type="integer") */ private $id; /**** * @ManyToOne(targetEntity="App*Model*Role") * @JoinColumn(name="role_id", nullable=false) */ private $role; /*** @Column(type="string", columnDefinition="CHAR(64) NOT NULL") **/ private $password; } <?php /**** * @Entity * @Table(name="roles") */ class App*Model*Role { /**** * @Id * @GeneratedValue(strategy="IDENTITY") * @Column(type="smallint") */ private $id; }``` I'm getting this output from orm:schema-tool:update --dump-sql, when the database is already up-to-date: ```ALTER TABLE users CHANGE password password CHAR(64) NOT NULL; ALTER TABLE users DROP FOREIGN KEY users*ibfk*1; ALTER TABLE users ADD FOREIGN KEY (role_id) REFERENCES roles(id)``` ``````

admin added the Bug label 2026-01-22 12:49:58 +01:00

admin closed this issue

2026-01-22 12:49:58 +01:00

admin commented

2026-01-22 12:49:59 +01:00

@doctrinebot commented on GitHub (Jun 3, 2010):

is referenced by DBAL-1096: schema-tool:update does not understand columnDefinition correctly

@doctrinebot commented on GitHub (Jun 3, 2010): - is referenced by [DBAL-1096: schema-tool:update does not understand columnDefinition correctly](http://www.doctrine-project.org/jira/browse/DBAL-1096)

admin commented

2026-01-22 12:49:59 +01:00

@doctrinebot commented on GitHub (Jun 22, 2010):

Comment created by shurakai:

This is most probably equivalent with the following problem:

{quote}
It's got to do with cli: when you DB is up to date and you run orm:schema-tool:update --dump-sql, you get something like this:

ALTER TABLE user_users CHANGE avatar avatar LONGTEXT NOT NULL <- but the column avatar is already LONGTEXT

This is caused by the following: Two schema objects are being compared. The first schema is created from the current mapping files (YAML, e.g.) and within these, this column is marked as "object". When the DB is setup, object is transferred into another type, like LONGTEXT. (Platform dependent)

The second schema is created from your current database and is marked as "TextType" because Doctrine cannot decide which other type - there are several who use LONGTEXT - would be correct
{quote}

See /DBAL/Schema/Comparator.php ll. 172ff. & 293

Comparing whether both Types return the same SQL-Statement might do the job but would be really ugly.

@doctrinebot commented on GitHub (Jun 22, 2010): Comment created by shurakai: This is most probably equivalent with the following problem: {quote} It's got to do with cli: when you DB is up to date and you run orm:schema-tool:update --dump-sql, you get something like this: ALTER TABLE user_users CHANGE avatar avatar LONGTEXT NOT NULL <- but the column avatar is already LONGTEXT This is caused by the following: Two schema objects are being compared. The first schema is created from the current mapping files (YAML, e.g.) and within these, this column is marked as "object". When the DB is setup, object is transferred into another type, like LONGTEXT. (Platform dependent) The second schema is created from your current database and is marked as "TextType" because Doctrine cannot decide which other type - there are several who use LONGTEXT - would be correct {quote} See /DBAL/Schema/Comparator.php ll. 172ff. & 293 Comparing whether both Types return the same SQL-Statement might do the job but would be really ugly.

admin commented

2026-01-22 12:49:59 +01:00

@doctrinebot commented on GitHub (Jun 28, 2010):

Comment created by @beberlei:

The columnDefintion affected field can obviously not be solved by any means.

The foreign key thing i see more often in my own projects though, i have to dig deeper there.

@doctrinebot commented on GitHub (Jun 28, 2010): Comment created by @beberlei: The columnDefintion affected field can obviously not be solved by any means. The foreign key thing i see more often in my own projects though, i have to dig deeper there.

admin commented

2026-01-22 12:49:59 +01:00

@doctrinebot commented on GitHub (Jul 9, 2010):

Comment created by @beberlei:

Fixed Foreign Key issue in DBAL master, it was an error in the MySQL query to fetch the foreign keys.

@doctrinebot commented on GitHub (Jul 9, 2010): Comment created by @beberlei: Fixed Foreign Key issue in DBAL master, it was an error in the MySQL query to fetch the foreign keys.

admin commented

2026-01-22 12:50:01 +01:00

@doctrinebot commented on GitHub (Jul 9, 2010):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Jul 9, 2010): Issue was closed with resolution "Fixed"

admin referenced this issue

2026-01-22 16:01:06 +01:00

[PR #773] [CLOSED] Support matching Criteria on PersistentCollection on ManyToMany associat... #8691

Sign in to join this conversation.