[DDC-3040] doctrine:schema:update datetimetz field type not null Created: 19/Mar/14  Updated: 07/Apr/14  Resolved: 07/Apr/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: 2.4.2
Security Level: All

Type: Bug Priority: Major
Reporter: Coroliov Oleg Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: console, orm, schematool


 Description   

I have some fields like

    /**
     * Adding date in format ISO-8601 YYYY-MM-DDThh:mm:ss±hhmm
     *
     * @var \DateTime
     *
     * @ORM\Column(name="added_at", type="datetimetz", nullable=false)
     */
    private $addedAt;

    /**
     * Expire date in format ISO-8601 YYYY-MM-DDThh:mm:ss±hhmm
     *
     * @var \DateTime
     *
     * @ORM\Column(name="expired_at", type="datetimetz", nullable=false)
     */
    private $expiredAt;

@ORM\Column -> nullable=false

In database this field already not null
But when i execute in console:

./app/console doctrine:schema:update --dump-sql --env=dev

answer:

ALTER TABLE test CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;

If I change datetimetz to datetime type fot $expiredAt
and execute:

./app/console doctrine:schema:update --dump-sql --env=dev

answer:

ALTER TABLE test CHANGE added_at added_at DATETIME NOT NULL;



 Comments   
Comment by Coroliov Oleg [ 05/Apr/14 ]

have some news about this problem ?

Comment by Marco Pivetta [ 06/Apr/14 ]

Coroliov Oleg does the DDL update statement persist in the diffs even after running it?

Comment by Coroliov Oleg [ 06/Apr/14 ]
$ ./app/console doctrine:schema:update --dump-sql --env=dev
ALTER TABLE device CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE device_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
ALTER TABLE package_activated CHANGE start_at start_at DATETIME NOT NULL, CHANGE expire_at expire_at DATETIME NOT NULL;
ALTER TABLE package_activated_audit CHANGE start_at start_at DATETIME DEFAULT NULL, CHANGE expire_at expire_at DATETIME DEFAULT NULL;
ALTER TABLE package CHANGE created_at created_at DATETIME NOT NULL;
ALTER TABLE package_audit CHANGE created_at created_at DATETIME DEFAULT NULL;
ALTER TABLE coupon CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;
ALTER TABLE coupon_audit CHANGE added_at added_at DATETIME DEFAULT NULL, CHANGE expired_at expired_at DATETIME DEFAULT NULL;
ALTER TABLE company CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE company_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
$ ./app/console doctrine:schema:update --force
Updating database schema...
Database schema updated successfully! "10" queries were executed
$ ./app/console doctrine:schema:update --dump-sql --env=dev
ALTER TABLE device CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE device_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
ALTER TABLE package_activated CHANGE start_at start_at DATETIME NOT NULL, CHANGE expire_at expire_at DATETIME NOT NULL;
ALTER TABLE package_activated_audit CHANGE start_at start_at DATETIME DEFAULT NULL, CHANGE expire_at expire_at DATETIME DEFAULT NULL;
ALTER TABLE package CHANGE created_at created_at DATETIME NOT NULL;
ALTER TABLE package_audit CHANGE created_at created_at DATETIME DEFAULT NULL;
ALTER TABLE coupon CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;
ALTER TABLE coupon_audit CHANGE added_at added_at DATETIME DEFAULT NULL, CHANGE expired_at expired_at DATETIME DEFAULT NULL;
ALTER TABLE company CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE company_audit CHANGE added_at added_at DATETIME DEFAULT NULL;

or if i use additional bundle

$ ./app/console doctrine:schema:update --dump-sql --env=dev
ALTER TABLE device CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE device_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
ALTER TABLE package_activated CHANGE start_at start_at DATETIME NOT NULL, CHANGE expire_at expire_at DATETIME NOT NULL;
ALTER TABLE package_activated_audit CHANGE start_at start_at DATETIME DEFAULT NULL, CHANGE expire_at expire_at DATETIME DEFAULT NULL;
ALTER TABLE package CHANGE created_at created_at DATETIME NOT NULL;
ALTER TABLE package_audit CHANGE created_at created_at DATETIME DEFAULT NULL;
ALTER TABLE coupon CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;
ALTER TABLE coupon_audit CHANGE added_at added_at DATETIME DEFAULT NULL, CHANGE expired_at expired_at DATETIME DEFAULT NULL;
ALTER TABLE company CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE company_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
$ ./app/console doctrine:migrations:diff
Generated new migration class to "/Users/ruscon/projects/xxx/app/DoctrineMigrations/Version20140407004542.php" from schema differences.
$ ./app/console doctrine:migrations:migrate

                    Application Migrations


WARNING! You are about to execute a database migration that could result in schema changes and data lost. Are you sure you wish to continue? (y/n)y
Migrating up to 20140407004542 from 20140405144932

  ++ migrating 20140407004542

     -> ALTER TABLE device CHANGE added_at added_at DATETIME NOT NULL
     -> ALTER TABLE device_audit CHANGE added_at added_at DATETIME DEFAULT NULL
     -> ALTER TABLE package_activated CHANGE start_at start_at DATETIME NOT NULL, CHANGE expire_at expire_at DATETIME NOT NULL
     -> ALTER TABLE package_activated_audit CHANGE start_at start_at DATETIME DEFAULT NULL, CHANGE expire_at expire_at DATETIME DEFAULT NULL
     -> ALTER TABLE package CHANGE created_at created_at DATETIME NOT NULL
     -> ALTER TABLE package_audit CHANGE created_at created_at DATETIME DEFAULT NULL
     -> ALTER TABLE coupon CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL
     -> ALTER TABLE coupon_audit CHANGE added_at added_at DATETIME DEFAULT NULL, CHANGE expired_at expired_at DATETIME DEFAULT NULL
     -> ALTER TABLE company CHANGE added_at added_at DATETIME NOT NULL
     -> ALTER TABLE company_audit CHANGE added_at added_at DATETIME DEFAULT NULL

  ++ migrated (3.46s)

  ------------------------

  ++ finished in 3.46
  ++ 1 migrations executed
  ++ 10 sql queries
$ ./app/console doctrine:schema:update --dump-sql --env=dev
ALTER TABLE device CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE device_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
ALTER TABLE package_activated CHANGE start_at start_at DATETIME NOT NULL, CHANGE expire_at expire_at DATETIME NOT NULL;
ALTER TABLE package_activated_audit CHANGE start_at start_at DATETIME DEFAULT NULL, CHANGE expire_at expire_at DATETIME DEFAULT NULL;
ALTER TABLE package CHANGE created_at created_at DATETIME NOT NULL;
ALTER TABLE package_audit CHANGE created_at created_at DATETIME DEFAULT NULL;
ALTER TABLE coupon CHANGE added_at added_at DATETIME NOT NULL, CHANGE expired_at expired_at DATETIME NOT NULL;
ALTER TABLE coupon_audit CHANGE added_at added_at DATETIME DEFAULT NULL, CHANGE expired_at expired_at DATETIME DEFAULT NULL;
ALTER TABLE company CHANGE added_at added_at DATETIME NOT NULL;
ALTER TABLE company_audit CHANGE added_at added_at DATETIME DEFAULT NULL;
Comment by Steve Müller [ 07/Apr/14 ]

I assume from the syntax that you are using MySQL. MySQL does not have a native type for DateTimeTz, therefore the mapping always falls back to the native DATETIME type. See the DBAL documentation (footnote 15): http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#mapping-matrix

The problem here is not the nullable flag but the type you use. Therefore you get the irrgeular update statements from the schema tool. Use Doctrine's "datetime" type instead and you'll be fine. You won't be able to store time zone information for a date time in MySQL anyways as it does not have a type for this.

Comment by Coroliov Oleg [ 07/Apr/14 ]

Steve Müller, you right. Thanks.





[DDC-2989] ORM should allow custom index names for foreign associations. Created: 07/Feb/14  Updated: 23/Feb/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM, Tools
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Jonathon Suggs Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, schematool

Issue Links:
Reference
relates to DBAL-234 Index names are not synchronized by C... Resolved
relates to DBAL-566 Schema Comparator does not identify r... Resolved
is referenced by DDC-2990 [GH-956] Foreign association index names Open

 Description   

Now that the DBAL allows/checks for renamed indexes, the ORM implementation needs to be enhanced to allow custom naming of the indexes for foreign associations.



 Comments   
Comment by Jonathon Suggs [ 07/Feb/14 ]

Here is a full example
https://github.com/jsuggs/schema-issue

I think this mainly has to do with the doctrine auto-generated indexes.

Comment by Marco Pivetta [ 15/Feb/14 ]

IIRC, index names cannot currently be assigned, and are computed automatically - that's why the ORM is behaving like that.

I don't think this needs a fix right now - lowering priority

Comment by Steve Müller [ 15/Feb/14 ]

Jonathon Suggs I also could not reproduce this bug in DBAL. I wonder if that is related to foreign key declarations (ORM relations) only. In fact, you cannot define index names for relations (foreign keys) in ORM at the moment. Therefore ORM always generates index names automatically. If you use custom names for those indexes in your online schema, the comparator will surely output the index renaming statement. I guess defining the index at table level in your mapping manually won't help here either.
Whatsoever I think this is an ORM only issue. If you manually changed your index names "online", you will now get some index rename statements when using the schema tool. Other users explicitly requested this feature. Schemas not in sync have to be upgraded, I guess. So IMO this is rather a "won't fix" in DBAL. However there is a possible improvement to ORM for being able to define index names for foreign keys. The whole topic is rather tricky concerning the comparator. Imagine you have (for whatever reason) multiple indexes with different names that span the exact same columns. How would you expect the comparator to output changes here? Which indexes should be renamed, which shouldn't?

Comment by Jonathon Suggs [ 18/Feb/14 ]

I guess I get it, but its kinda a big deal and I'll have to old off upgrading as a result. I personally find this more of a regression due to the unintended consequences. The schema diff is now 100% useless (to me) as I rename all of my indexes to a more semantic name.

My off the cuff thought on ORM index naming is that you expand the naming strategy to include support for the indexes. Given the full set of criteria you should be able to come up with some sort of semantic naming and only on namespace collision to you "fallback" to a hash of the columns (solves your issues and mine).

Comment by Jonathon Suggs [ 19/Feb/14 ]

To state differently, I (personally) value the schema diff tool much more than custom index (re)naming since the (overall) ability to use custom index names is not complete (due to the ORM issues Steve outlined above).

If the support to (re)name foreign key indexes can't go out in parallel to this, I'd like to offer a middle ground of making the index renaming configurable (ie ability to opt-out of functionality).

Sorry to be negative towards a new feature, but its really an inconvenience for me, and I suspect others since Strate also expressed concerns in the PR.

Let me know how I can be of help in working towards a resolution.

Comment by Benjamin Eberlei [ 19/Feb/14 ]

Jonathon Suggs What do you mean with "just upgraded"? Which to which version? The index renaming and coverage feature is very old already, not sure what is happening. Do you define an index for a relation column?

Comment by Steve Müller [ 19/Feb/14 ]

Benjamin Eberlei This definitely has to do with the comparator now comparing index names also.
Jonathon Suggs Can you please confirm my assumption that this problem is only related to relations and their foreign key indexes? Also can you confirm that it only affects those foreign key indexes which you gave a custom name? Can you please check that?
I don't see any reasonable solution in DBAL for this. The real solution IMO would be to allow custom names in ORM mappings for foreign key realation indexes.

Comment by Jonathon Suggs [ 19/Feb/14 ]

Sorry for the confusion.

Here is the PR that introduced the functionality in question.
https://github.com/doctrine/dbal/pull/473

Benjamin, I had just upgraded DBAL to the latest 2.5 master. This is only indirectly related to the ORM functionality as the ORM SchemaTool uses the DBAL Comparator to generate is schema diff.
Steve, yes this is only related to relations and foreign key indexes that were given a custom name. I documented the use case/scenario here: https://github.com/jsuggs/schema-issue

Steve, I see three potential solutions (in my personal order of preference).
1) Expand the NamingStrategy to allow it to handle the default names of foreign key relation indexes
2) As you suggested, allow for ORM mappings to specify foreign key relation indexes
3) Add a configuration directive that essentially allows for you to ignore renamed indexes (ie. fallback to the previous behavior, prior to PR 473).

I realize that #1 would be a bit more work, but I think offers enhanced functionality. #2 is a good, but would require additional annotations/mappings. #3 is probably the least dev effort but just doesn't feel right (to me).

Again, I don't want to seem critical of the dev effort, but its an unintended consequence that will keep me from being able to upgrade DBAL to 2.5.

Comment by Steve Müller [ 19/Feb/14 ]

Jonathon Suggs You are right the comparator is somewhat responsible for the "unnecesarry" schema diffs it now creates. However its functionality is completely working IMO. Try creating and comparing your schema example on DBAL level only (without utilizing ORM). You will see that it works. I see and understand that those index name updates are annoying but they are not WRONG. If you have a mapping for a relation with an unnamed index and rename this index in your online schema manually, I would even expect the schema tool to generate this diff. Because this is the whole point of the index rename feature. The problem we have here is that there currently is no way in ORM to define the index name on association mappings. There the following happens in your example when comparing the online and offline schema with the schema tool:

(abbreviated to the important steps, chronological order)

1. Collect mapping information and evaluate offline schema
1.1. Schema tool collects relation SQL for Bar -> Foo association and adds an unnamed index "IDX_76FF8CAA8E48560F" to table "bar"
1.2. Schema tool collects custom indexes defined in the mapping for "bar", detects the custom index "IDX_MANY_TO_ONE", tries to add it to the table "bar, but discards it because there is already another index "IDX_76FF8CAA8E48560F" fulfilling the exact same columns (this is how DBAL works ever since to avoid duplicate indexes)

2. Reverse-engineer online schema from database
2.1 Fetch all defined indexes for table "bar" -> adds "idx_many_to_one" to table "bar"

3. Comapre evaluated online schema to evaluated offline schema
3.1 Compare index "idx_many_to_one" (online schema) to index "IDX_76FF8CAA8E48560F" (offline schema) -> suggest index rename from "idx_many_to_one" to "IDX_76FF8CAA8E48560F" because the mapping is your definition and takes precedence.

Just to clarify what happens under the hood and that it is an ORM issue, not DBAL!

Comment by Jonathon Suggs [ 19/Feb/14 ]

Here is a first shot at basic support for allowing the mapping of the index name.
https://github.com/jsuggs/doctrine2/compare/foreign-association-index-names

Comment by Steve Müller [ 19/Feb/14 ]

Jonathon Suggs I have worked on a PR for this already using the exact same approach you just mentioned. However I am not quite sure about ManyToMany yet (because you would have to be able to define both index names there) and also I talked to Benjamin Eberlei and he does not seem to be happy with this approach. So I stopped work on this for the moment.

Comment by Steve Müller [ 19/Feb/14 ]

Moved this to ORM issues.

Comment by Jonathon Suggs [ 19/Feb/14 ]

Steve I both agree and disagree.

I think my underlying issue is your step 1.1. The ORM creates the index named "IDX_76FF8CAA8E48560F" and there is NO extension point for being able to override that behavior. FWIW, I've never been fond of the way that the ORM uses the AbstractAsset::_generateIdentifierName for generating the index and foreign key.

So I definitely agree that its is an ORM issue not DBAL issue . However, as I stated previously, until the ORM is updated/patched to allow for index naming, this (in my opinion) is a regression despite it working the way it currently does (correct or not).

I can close out this issue and open one for ORM. Do you have a old branch and/or ORM ticket that I can reference?

Thanks for engaging in the dialog! I hope to be of assistance in helping come up with a solution that gets everyone happy.

Comment by Steve Müller [ 19/Feb/14 ]

Jonathon Suggs Thanks for updating the description and thanks for assisting on this issue. We will find a solution for this before the final release of 2.5. If we cannot find a good solution until then we might also consider reverting the index renaming feature on DBAL (but I would like to avoid that). I will discuss this issue with the other core devs again and see what we can come up with.

Comment by Jonathon Suggs [ 19/Feb/14 ]

No problem, here is the start of a PR to maybe address the index names
https://github.com/doctrine/doctrine2/pull/956





[DDC-2894] on-update cascade for one-to-one association Created: 08/Jan/14  Updated: 08/Jan/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.4, 2.4.1
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: I. S. Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, schematool, xml


 Description   

I'm trying to use on-update cascade in a one-to-one association but it ends in on-update restrict when I update the database tables.
I'm using XML Definition an my definition for this specific association looks like this:

<one-to-one field="scope" target-entity="Application\Entity\Scope">
<join-column name="scope_id" referenced-column-name="id" nullable="false" on-delete="CASCADE" on-update="CASCADE" />
<cascade>
<cascade-persist />
<cascade-remove />
</cascade>
</one-to-one>

This works pretty well when I use on-update="CASCADE" in a many-to-one association, but one-to-one just ignores it.
When I change the database manually everything works well, but the next update from command line will override it.






[DDC-2788] Create Table If Not Exists - doctrine:schema:update Created: 11/Nov/13  Updated: 11/Nov/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.2.3
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: jayem Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: command, schematool


 Description   

I am not positive if this issue is in the correct project. Sorry if I placed it in the wrong area.

I was wondering if it would be possible to have the doctrine:schema:update command updated to use CREATE IF NOT EXISTS for tables that already exist.

For example, here is my setup:

Author.php
    /**
     * The relationship between an author and its associated book entities.
     *
     * @ORM\ManyToMany(targetEntity="Book")
     * @ORM\JoinTable(name="authors_books",
     *     joinColumns={@ORM\JoinColumn(name="book_id", referencedColumnName="id")},
     *     inverseJoinColumns={@ORM\JoinColumn(name="author_id", referencedColumnName="id")}
     * )
     */
    protected $books;

The above code is an example, so the exact column names may not be 100% correct. The import aspect is the join table name. If that table already exists in the database, I will get the following error when I run the doctrine:schema:update --dump-sql command:

[Doctrine\DBAL\Schema\SchemaException]
The table with the name 'authors_books' already exists.

This is because it is trying to CREATE TABLE 'authors_books' and that table is already in the database. Could the command instead use CREATE TABLE IF NOT EXISTS 'authors_books' when "IF NOT EXISTS" is available for the configured database type?

Thanks!






[DDC-2742] 2 ManyToMany relations to the same target entity make the schema update fail by default Created: 15/Oct/13  Updated: 15/Oct/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: 2.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, schematool


 Description   

At some point in the Doctrine releases (I don't remember which version it was), the default naming of the join table of a ManyToMany relation changed from using the property name to using the name of the target entity.

This makes it impossible to use multiple ManyToMany relations to the same target entity in a class without naming join tables explicitly. A SchemaException is thrown by the SchemaTool when trying to update the schema.

Note that this issue is not caught by the SchemaValidator. It will display us that the mapping files are correct (before throwing the above exception in the second step when trying to compare it to the existing database)






[DDC-2560] Schema tool invalid DDL syntax for default values Created: 19/Jul/13  Updated: 19/Jul/13

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Ben Davies Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: schematool
Environment:

Postgresql



 Description   

Not sure if this is Postgresql specific or not, but here are the reproduction steps:

Have a table with a column setup like so:

ALTER TABLE usr ADD COLUMN contact_count integer;
ALTER TABLE usr ALTER COLUMN contact_count SET NOT NULL;
ALTER TABLE usr ALTER COLUMN contact_count SET DEFAULT 0;

Have a Entity Column Definition like so:

    /**
     * @var integer $contactCount
     *
     * @ORM\Column(name="contact_count", type="integer", nullable=false)
     */
    private $contactCount = 0;

orm:schema-tool:update will generate the following SQL:

ALTER TABLE usr ALTER contact_count SET ;

adding

options={"default":0}

to the column definition results in no sql being generated (correctly I assume)



 Comments   
Comment by Marco Pivetta [ 19/Jul/13 ]

The ORM doesn't support default column values.
That's fine-tuning you can do on the column definitions.

Your "workaround" is actually the correct way of dealing with this kind of DDL change.

Comment by Ben Davies [ 19/Jul/13 ]

I realise the ORM doesn't support default values, but the point is that the schematool picks up a diff in the columns, tries to generate a diff, and generates an invalid sql statement. Surely that is a bug?

Comment by Marco Pivetta [ 19/Jul/13 ]

Ben Davies the DBAL is responsible for generating this wrong DDL... Are you able to reproduce this in DBAL only?

Comment by Ben Davies [ 19/Jul/13 ]

Happy to try.

Comment by Ben Davies [ 19/Jul/13 ]

here you go
https://github.com/bendavies/dbal/blob/DBAL-561/tests/Doctrine/Tests/DBAL/Functional/Ticket/DBAL561Test.php





[DDC-2551] schema-tool does not match join columns with identifier options Created: 13/Jul/13  Updated: 16/Jul/13  Resolved: 15/Jul/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3.4
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Atans Chiu Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: schematool
Environment:

Zend Framework 2
Doctrine ORM 2.3.4



 Description   
/**
 * Role
 *
 * @ORM\Entity
 * @ORM\Table(name="rbac_role", options={"collate"="utf8_general_ci"})
 * @package User\Entity
 */
class Role
{
    /**
     * @ORM\Id
     * @ORm\Column(name="role_id", type="integer", options={"unsigned"=true})
     * @ORM\GeneratedValue(strategy="AUTO")
     * @var int
     */
    protected $id;

    /**
     * @ORM\Column(name="role_name", name="string", length=32, nullable=true)
     * @var string
     */
    protected $name = null;


    /**
     * @ORM\ManyToOne(targetEntity="Role")
     * @ORM\JoinColumn(name="parent_role_id", referencedColumnName="id", nullable=true)
     * @var Role
     */
    protected $parentRole = null;
$ php vendor/doctrine/orm/bin/doctrine.php orm:schema-tool:update --force

Updating database schema...



  [Doctrine\DBAL\DBALException]
  An exception occurred while executing 'ALTER TABLE rbac_role ADD CONSTRAINT
   FK_C55D6FF2A44B56EA FOREIGN KEY (parent_role_id) REFERENCES rbac_role (id)
  ':

  SQLSTATE[HY000]: General error: 1005 Can't create table 'rbac.#sql-98_24b'
  (errno: 150)






  [PDOException]
  SQLSTATE[HY000]: General error: 1005 Can't create table 'rbac.#sql-98_24b'
  (errno: 150)

Problem here: ====================================================

ALTER TABLE rbac_role ADD CONSTRAINT
   FK_C55D6FF2A44B56EA FOREIGN KEY (parent_role_id) REFERENCES rbac_role (id)

 ==> `rbac_role (id)` should be `rbac_role (role_id)


 Comments   
Comment by Marco Pivetta [ 15/Jul/13 ]

You can make your join column unsigned by using the `columnDefinition` property.

Comment by Marco Pivetta [ 15/Jul/13 ]

The schema tool can't use the column options to match join columns with identifier columns.

Column options are one step further and cannot really be applied transitively to join columns, since they may contain vendor specific settings.

Comment by Atans Chiu [ 15/Jul/13 ]

Thanks.


@ORM\JoinColumn(
 name="parent_role_id",
  referencedColumnName="id",
  nullable=true,
  columnDefinition="ALTER TABLE rbac_role ADD CONSTRAINT FK_C55D6FF2A44B56EA FOREIGN KEY (parent_role_id) REFERENCES rbac_role (role_id)"
)

Is this right ?

Comment by Marco Pivetta [ 15/Jul/13 ]

No. Your problem is that the join coulm is signed, whereas the referenced identifier column is unsigned.

Comment by Atans Chiu [ 15/Jul/13 ]

I do not understand, how can I do ?

Comment by Marco Pivetta [ 15/Jul/13 ]

Simple solution: just drop the

options={"unsigned"=true}

from your annotations

Comment by Atans Chiu [ 16/Jul/13 ]

Thanks Marco Pivetta.

Comment by Atans Chiu [ 16/Jul/13 ]

Marco Pivetta, It is the same problem (2.4.0-RC2).

/**
 * Role
 *
 * @ORM\Entity
 * @ORM\Table(name="rbac_role", options={"collate"="utf8_general_ci"})
 * @package User\Entity
 */
class Role
{
    /**
     * @ORM\Id
     * @ORm\Column(name="role_id", type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     * @var int
     */
    protected $id;

    /**
     * @ORM\Column(name="role_name", name="string", length=32, nullable=true)
     * @var string
     */
    protected $name = null;


    /**
     * @ORM\ManyToOne(targetEntity="Role")
     * @ORM\JoinColumn(name="parent_role_id", referencedColumnName="id", nullable=true)
     * @var Role
     */
    protected $parentRole = null;

    /**
     * @ORM\ManyToMany(targetEntity="Permission")
     * @ORM\JoinTable(
     *  name="rbac_role_permission",
     *  joinColumns={@ORM\JoinColumn(name="role_id", referencedColumnName="id")},
     *  inverseJoinColumns={@ORM\JoinColumn(name="perm_id", referencedColumnName="id")}
     * )
     * @var Permission[]
     */
    protected $permissions;
$ php vendor/doctrine/orm/bin/doctrine.php orm:schema-tool:update --dump-sql
ALTER TABLE rbac_role ADD CONSTRAINT FK_C55D6FF2A44B56EA FOREIGN KEY (parent
e_id) REFERENCES rbac_role (id);
ALTER TABLE rbac_role_permission CHANGE role_id role_id INT NOT NULL;
ALTER TABLE rbac_role_permission ADD CONSTRAINT FK_C31A0CF0D60322AC FOREIGN
(role_id) REFERENCES rbac_role (id);
ALTER TABLE rbac_role_permission ADD CONSTRAINT FK_C31A0CF0FA6311EF FOREIGN
(perm_id) REFERENCES rbac_permission (id);

rbac_role (id) does not change to rbac_role (role_id)

Comment by Marco Pivetta [ 16/Jul/13 ]

That's normal. I already marked the issue as "won't fix". Please don't use the issue tracker as a helpdesk.

Comment by Atans Chiu [ 16/Jul/13 ]

Oh, sorry





[DDC-2489] Missing semicolon in schema update tool, using dump-sql argument Created: 05/Jun/13  Updated: 08/Sep/13  Resolved: 08/Sep/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM, Tools
Affects Version/s: None
Fix Version/s: 2.4

Type: Bug Priority: Minor
Reporter: Robert-Jan Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: Cli, schematool


 Description   

When executing the schema-tool update script, using the --dump-sql argument (e.g. "app/console doctrine:schema:update --dump-sql" in a symfony2 project), the semicolon behind the last query is missing.



 Comments   
Comment by Guilherme Blanco [ 12/Jun/13 ]

Fixed in https://github.com/doctrine/doctrine2/commit/0d834d0bd4015de2c103a03592c1543399f1b363





[DDC-2469] SQLite handling for ENUM-Fields Created: 24/May/13  Updated: 24/May/13  Resolved: 24/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Andy Rosslau Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: query, schematool, sqlite


 Description   

SQLite doesn't support ENUMS!

But when I try create the schema of the following Entity Doctrine generates this "CREATE TABLE" - Statement:

CREATE TABLE Entity ([...] NOT NULL, taxation ENUM('incl', 'excl'), maxNumbe[...]
class Entity {
...

    /**
     * @var string
     *
     * @ORM\Column(type="string", columnDefinition="ENUM('incl', 'excl')")
     */
    private $taxation = self::TAXATION_INCL;

...
}

Produces this error:

SQLSTATE[HY000]: General error: 1 near "'incl'": syntax error'



 Comments   
Comment by Marco Pivetta [ 24/May/13 ]

Usage of

columnDefinition

in annotations or generally metadata mappings is all about vendor specific syntax. `columnDefinition` is designed to allow overriding the default ORM column generated DDL to build vendor specific syntax/types, therefore the issue is invalid





[DDC-2464] useless index for the middle table of many-to-many relationship Created: 21/May/13  Updated: 21/May/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Minor
Reporter: scourgen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: ddl, schematool


 Description   

I have entity A and B, the relationship between A and B is many-to-many. which means Doctrine2 will generate a middle table called AB for me.

entity A:

class Station {
    /**
     * @ORM\ManyToMany(targetEntity="Fun", mappedBy="stations")
     */
    protected $funs;
}

entity B:

class Fun {
    /**
     * @ORM\ManyToMany(targetEntity="Station", inversedBy="funs")
     * @ORM\JoinTable(name="stations_have_funs")
     */
    protected $stations;
}

the schema of middle table stations_have_funs:

CREATE TABLE `stations_have_funs` (
  `fun_id` int(11) NOT NULL,
  `station_id` int(11) NOT NULL,
  PRIMARY KEY (`fun_id`,`station_id`),
  KEY `IDX_45C921911CA4BE49` (`fun_id`),
  KEY `IDX_45C9219121BDB235` (`station_id`),
  CONSTRAINT `FK_45C921911CA4BE49` FOREIGN KEY (`fun_id`) REFERENCES `funs` (`id`) ON DELETE CASCADE,
  CONSTRAINT `FK_45C9219121BDB235` FOREIGN KEY (`station_id`) REFERENCES `stations` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

I noticed that there are 2 useless index(fun_id and station_id). Since fun_id and station_id are the primary key of this table. Do we really need 2 extra/duplicated index ?






[DDC-2425] Parent entity sometimes fails to load when validating/updating schema. Created: 03/May/13  Updated: 03/May/13  Resolved: 03/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Trivial
Reporter: Scott Gibson Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: Cli, orm, schematool
Environment:

Debian 6.0.6 x64



 Description   

Should not have reported, was a stupid mistake on my part.






[DDC-2421] Many-To-Many relation creation failed when using non PK entity field Created: 29/Apr/13  Updated: 10/Sep/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: Git Master, 2.3.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Bruno CHALOPIN Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: schematool
Environment:

Ubuntu linux 12.04, php 5.4.9



 Description   

Given these entities :

/**
 * Class Domain
 *
 * @ORM\Entity
 * @ORM\Table(name="profils_domains")
 */
class Domain
{
    /**
     * @var string
     *
     * @ORM\Id
     * @ORM\Column(type="string", length=22, nullable=false)
     */
    protected $name = '';
}
/**
 * Class Web
 *
 * @ORM\Entity
 * @ORM\Table(name="profils_webs",
 *          uniqueConstraints={@ORM\UniqueConstraint(name="web_unique",columns={"name", "domain"})}
 * )
 */
class Web
{
    /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer", nullable=false)
     */
    protected $id;

    /**
     * @var string
     *
     * @ORM\Column(type="string", length=22, nullable=false)
     */
    protected $name = '';

    /**
     * @var Domain
     *
     * @ORM\ManyToOne(targetEntity="Domain", fetch="LAZY")
     * @ORM\JoinColumn(name="domain", referencedColumnName="name", nullable=false, onDelete="CASCADE")
     */
    protected $domain;
}
/**
 * Class WebsGroup
 *
 * @ORM\Entity
 * @ORM\Table(name="profils_websgroups",
 *          uniqueConstraints={@ORM\UniqueConstraint(name="websgroup_unique",columns={"name", "domain"})}
 * )
 */
class WebsGroup
{
    /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\GeneratedValue
     * @ORM\Column(type="integer", nullable=false)
     */
    protected $id;

    /**
     * @var string
     *
     * @ORM\Column(type="string", length=22, nullable=false)
     */
    protected $name = '';

    /**
     * @var Domain
     *
     * @ORM\ManyToOne(targetEntity="Domain", fetch="LAZY")
     * @ORM\JoinColumn(name="domain", referencedColumnName="name", nullable=false, onDelete="CASCADE")
     */
    protected $domain;

    /**
     * @var ArrayCollection
     *
     * @ORM\ManyToMany(targetEntity="Web", indexBy="id", fetch="EXTRA_LAZY")
     * @ORM\JoinTable(name="profils_websgroups_webs",
     *      joinColumns={
     * @ORM\JoinColumn(name="websgroup_id", referencedColumnName="id", onDelete="CASCADE"),
     * @ORM\JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE")
     *          },
     *      inverseJoinColumns={
     * @ORM\JoinColumn(name="web_id", referencedColumnName="id", onDelete="CASCADE"),
     * @ORM\JoinColumn(name="domain", referencedColumnName="domain", onDelete="CASCADE")
     *          }
     *      )
     */
    protected $webs;
}

I've got a domain, some web sites per domain and websgroups which group web sites. I want to be sure in my database that a web group from a domain D can contain only web sites from the very same domain but when calling the console tool for creating my schema it raise :

[Doctrine\ORM\ORMException]                                                                                                                                      
  Column name `domain` referenced for relation from Entity\WebsGroup towards Entity\Web does not exist. 

It's because domain is already an association to an entity which and is not part of the primary key.

I've quick fixed getDefiningClass from Doctrine\ORM\Tools\SchemaTool to make it work but i really don't know if it's the proper way :

    private function getDefiningClass($class, $referencedColumnName)
    {
        $referencedFieldName = $class->getFieldName($referencedColumnName);

        if ($class->hasField($referencedFieldName)) {
            return array($class, $referencedFieldName);
        } else if (in_array($referencedColumnName, $class->getIdentifierColumnNames())) {
            // it seems to be an entity as foreign key
            foreach ($class->getIdentifierFieldNames() as $fieldName) {
                if ($class->hasAssociation($fieldName) && $class->getSingleAssociationJoinColumnName($fieldName) == $referencedColumnName) {
                    return $this->getDefiningClass(
                        $this->em->getClassMetadata($class->associationMappings[$fieldName]['targetEntity']),
                        $class->getSingleAssociationReferencedJoinColumnName($fieldName)
                    );
                }
            }
        } else if (in_array($referencedColumnName, $class->getAssociationNames())) {
            return $this->getDefiningClass(
                $this->em->getClassMetadata($class->associationMappings[$referencedColumnName]['targetEntity']),
                $class->getSingleAssociationReferencedJoinColumnName($referencedColumnName)
            );
        }

        return null;
    }


 Comments   
Comment by Fabio B. Silva [ 29/Apr/13 ]

Bruno CHALOPIN Except for some CS this fix seems good.

If you have time you can send as pull request

Comment by Bruno CHALOPIN [ 30/Apr/13 ]

I've start making a PR and a test case but it is linked to http://www.doctrine-project.org/jira/browse/DDC-2413
I'm looking in making a proper fix to DDC-2413 first.

Comment by Benjamin Eberlei [ 01/May/13 ]

You cannot use a reference column that is not a primary key. Doctrine does not support this.

Comment by Bavo Janss [ 10/Sep/13 ]

I stumbled on this issue when experiencing a similar bug.
There is something seriously wrong with the referencedColumn in a ManyToMany relationship.
When you use a PK as 'id' and set your referenced column to 'id' everything is fine.
But when you use 'productId' as PK and reference it properly creation fails because "column 'id' doens't exists in table", which is very strange. After introducing a bogus column 'id' to the entity, but still referencing 'productId' a linking table is created but it has FK's to 'id' not to productId. When changing the referenced column to 'bogus' the creation also fails because: "column 'bogus' doesn't exists in table".

To me doctrine checks the the referencedColumn for existence but after that just creates everything assuming the default PK 'id'.





[DDC-2288] Schema Tool doesn't update collation on table level Created: 08/Feb/13  Updated: 08/Feb/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, Tools
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: Rickard Andersson Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: collation, schematool


 Description   

In Symfony2, when updating the collation option of a table, the schema tool doesn't recognize the change:

Changing from:

 
* @ORM\Table()

To:

 
* @ORM\Table(options={"collate"="utf8_swedish_ci"})

Results in:

 
$ php app/console doctrine:schema:update --dump-sql
Nothing to update - your database is already in sync with the current entity metadata.





[DDC-2238] doctrine:schema:update partially broken Created: 11/Jan/13  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.3
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Tom Vogt Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: postgresql, schematool
Environment:

OS X 10.7.5
PHP 5.4.4
Postgres SQL 9.1.6

also confirmed on:
Linux (Debian testing, Kernel 2.6.32)
PHP 5.4.4
PostgreSQL 9.1.9
Doctrine 2.3.2


Attachments: Text File schemadiff.txt    
Issue Links:
Duplicate
duplicates DBAL-504 DBAL Enum fields migration issue / Po... Resolved

 Description   

the app/console doctrine:schema:update command generates a seemingly random number of statements like these:

ALTER TABLE geodata ALTER humidity SET ;
ALTER TABLE geodata ALTER lake SET ;
ALTER TABLE message ALTER translate SET ;

which are obvious invalid SQL commands. The mappings are fine, validate and the application works just fine. Here's an example from the mapping files including two of the above statements:

<field name="coast" type="boolean"/>
<field name="lake" type="boolean"/>
<field name="river" type="boolean"/>
<field name="humidity" type="float"/>
<field name="biome" type="string"/>

I am using doctrine2-spatial as an extension for GIS information. This problem shows up both in entities using spatial data and entities not using spatial data.

I'll gladly help debug this, as right now I can't update my dev database with --force, I need to use --dump-sql and filter out the invalid lines.



 Comments   
Comment by Benjamin Eberlei [ 12/Jan/13 ]

Can you dump the SchemaDiff/ColumnDiff instances that are returned from lib/Doctrine/DBAL/Schema/Comparator.php?

Comment by Tom Vogt [ 12/Jan/13 ]

requested dump of SchemaDiff

Comment by Tom Vogt [ 12/Jan/13 ]

added in the file schemadiff.txt - I added this in Schematool.php - getUpdateSchemaSql():

$comparator = new Comparator();
$schemaDiff = $comparator->compare($fromSchema, $toSchema);
\Doctrine\Common\Util\Debug::dump($schemaDiff, 6);

if you need other output, just tell me what entity to dump and where. I'll be happy to help.

The file also contains the buggy update statements it creates towards the end. There's a few non-crucial bugs included, where it alters the geospatial columns to themselves (i.e. river.course already is a geometry/linestring). I don't worry about those because they don't break anything.

Comment by Tom Vogt [ 15/Apr/13 ]

Is there any update on this? I'm still having this issue, with many different entities, always the same problem, for example:

ALTER TABLE event ALTER priority SET ;

Which is an integer field on an entity that doesn't have any GIS elements, so I'm not even sure if it's caused by that anymore.

Comment by Benjamin Eberlei [ 01/May/13 ]

Tom Vogt I added a fix for PostgreSQL today, can you verify again if this works? Its included in the 2.3 branch.

Comment by Benjamin Eberlei [ 01/May/13 ]

Duplicate of http://www.doctrine-project.org/jira/browse/DBAL-504





[DDC-2135] Setting column defaults using options in the annotations causes redundant alter statements Created: 09/Nov/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.2
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Cory Comer Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: Cli, schematool


 Description   

When using the Column annotation on an entity and passing the options parameter to set a default value for a column, the doctrine cli will generate the alter statement every time the schema-tool is run.

This doesn't break the functionality of updating the schema using the cli but when you have multiple entities using default values in this manner it becomes cumbersome to investigate issues during updates that fail and you need to dump the generated sql to examine.

Use case: We have a number of entities that include 'boolean' flags. The data for these entities is inserted into the database through an integration process handled by another application. For all of the flags we want to set a default value of 0 to avoid having to modify the integration scripts when a new flag is added to an entity and the data is not available yet.

Example entity:

/**
 * @ORM\Entity
 * @ORM\Table(name="example")
 */
class Example
{
    
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     */
    protected $id;
    
    /** @ORM\Column(type="integer", options={"default" = 0}) */
    protected $disabled;
    
}
$ php bin/doctrine orm:schema-tool:update --dump-sql
ALTER TABLE example CHANGE disabled disabled TINYINT(1) DEFAULT '0' NOT NULL;

This alter statement is generated on every run of the schema-tool even though the schema has already been altered.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

This is fixed for 2.3.4





[DDC-2119] Problem with inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS Created: 03/Nov/12  Updated: 08/Apr/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL, Tools
Affects Version/s: 2.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: SergSW Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, schematool

Attachments: File dump.sql     File SSWTestBundle.rar    

 Description   

I tried to create inheritance entities with save policy table per class.
Simple fileds was created normally, but a field with ManyToOne type was lost.

I had found a solution.

In Doctrine\ORM\Tools\SchemaTool
...

private function _gatherRelationsSql($class, $table, $schema)
    {
        foreach ($class->associationMappings as $fieldName => $mapping) {

           // if (isset($mapping['inherited'])) { // - old version

	/**
             * SSW
             * It's the solution
             */
	if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass() ) {
                continue;
            }            

            $foreignClass = $this->_em->getClassMetadata($mapping['targetEntity']);
...

But it was enough. In DQL query a simple query was made wrong.

I had found a solution again.
In Doctrine\ORM\Query\SqlWalker
...

public function walkSelectExpression($selectExpression)
...

                // original => if (isset($mapping['inherited'])){
                // It's the solution
                if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass()) {
                    $tableName = $this->_em->getClassMetadata($mapping['inherited'])->table['name'];
                } else {
                    $tableName = $class->table['name'];
                }
...

This problems are topical for inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS.

I don't know, may be my solutions are wrong. But some programmers want to correctly work with INHERITANCE_TYPE_TABLE_PER_CLASS.

Sorry for my english.



 Comments   
Comment by Fabio B. Silva [ 05/Nov/12 ]

Hi SergSW

Could you try to write a failing test case ?

Thanks

Comment by SergSW [ 06/Nov/12 ]

SSW/TestBundle with the problem

Comment by SergSW [ 07/Nov/12 ]

I install the Symfony v2.0.18. and made small TestBundle.
I made schema database, by CLI "console doctrine:schema:update --force"
Result: Database schema updated successfully!
But I saw that I lost a field 'user_id' in a table 'AttachTree' (see Attach)

Comment by SergSW [ 07/Nov/12 ]

MySQL dump

Comment by Benjamin Eberlei [ 12/Nov/12 ]

Adjusted example formatting, don't apologize for your English, thanks for the report!

Comment by Benjamin Eberlei [ 24/Dec/12 ]

What version of 2.1 are you using? We don't actually support 2.1 anymore. Inheritance has always worked as used in hundrets of unit-tests, this changes look quite major a bug to have been missed before. I can't really explain whats happening here.

Comment by Marco Pivetta [ 23/Jan/13 ]

SergSW news?





[DDC-2011] Schema tool fail to handle ManyToMany relation with an existing joinTable Created: 04/Sep/12  Updated: 09/Feb/13  Resolved: 09/Feb/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Erwan Richard Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 2
Labels: schematool


 Description   

The schemaTool fail with a Doctrine\DBAL\Schema\SchemaException when trying to handle ManyToMany relation with an existing joinTable.

My use case :

I'm using the Tree DoctrineExtension with the Closure strategy. It create a mapping between my Category entity and a CategoryClosure entity.

For conveniency, I've setup a ManyToMany relation between Category and Category with the CategoryClosure table as joinTable.

Doctrine ORM handle perfectly this case but the schema tool is failing with :
The table with name 'category_closure' already exists.



 Comments   
Comment by Alexander [ 09/Feb/13 ]

You can't expect the schematool to play nice if you use the table of an entity as m2m table.





Generated at Sat Apr 19 20:34:30 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.