[DDC-3055] table not escaped in orm:schema-tool:update if table already exists and needs to be altered Created: 27/Mar/14  Updated: 27/Mar/14

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

Type: Bug Priority: Major
Reporter: Hilz Simon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

the schema tool had to alter a table which name needs to be escaped (and was properly configured to do so). this didnt work because the table name wasnt escaped. completely deleting the table in the db let the schema tool generate the correct querys with escaped table names.



 Comments   
Comment by Marco Pivetta [ 27/Mar/14 ]

Hilz Simon did you try this with master as well?





[DDC-3025] Schema tool UPDATE or CREATE not generate decimal precision and scale for ID element Created: 12/Mar/14  Updated: 12/Mar/14

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

Type: Bug Priority: Major
Reporter: huda salam Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

FYI. I don't use doctrine but with symfony2, and only use .yml or .xml mapping. Not yet try with annotation.

These commands :

php app\console doctrine:schema:update
php app\console doctrine:schema:create

Will not generate id's precision and scale for this kind of mapping :

<doctrine-mapping .....>
  <entity name="Namespace\MyBundle\Entity\MyData" table="my_data">
    <id name="id" type="decimal" column="id" precision="x" scale="y">
      <generator strategy="IDENTITY"/>
    </id>
    <field ... />
  </entity>
</ ....>

Suggested changes :

  • Doctrine\ORM\Mapping\Driver\YamlDriver.php
  • Doctrine\ORM\Mapping\Driver\XmlDriver.php





[DDC-2794] the Paginator does not support arbitrary join Created: 14/Nov/13  Updated: 23/Dec/13

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: paginator


 Description   

Using the following query with the paginator fails:

SELECT u
FROM User u
JOIN Message m WITH m.author = u
WHERE m.status = 'draft' -- a condition justifying the join

The CountWalker and the CountOutputWalker both throw a exception saying "Cannot count query which selects two FROM components, cannot make distinction"

This message is wrong (I can make distinction here. Only User is selected in the result set) and confusing (I spent some time finding the second FROM before figuring it was related to the use of an arbitrary join instead of an association join).



 Comments   
Comment by Pierre-Antoine Pinel [ 23/Dec/13 ]

Hi,

I have the same issue.
My query is : SELECT entity FROM W\XBundle\Entity\X entity LEFT JOIN Z\YBundle\Entity\Y y WITH y.x = entity LEFT JOIN y.v v WHERE v.name LIKE :like

Is there a way to fix this issue ? I really need this to work with the Paginator.

Best,

Comment by Christophe Coevoet [ 23/Dec/13 ]

Why changing the status to "Awaiting feedback" ? It is not waiting for a feedback of the reporter to check the fix. It is an open ticket which does not have a fix yet





[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)






pager produces wrong results on postgresql (DDC-1958)

[DDC-2729] Same bug affects SQLServer2008Platform Created: 07/Oct/13  Updated: 07/Oct/13

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

Type: Sub-task Priority: Major
Reporter: Rafi Adnan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator
Environment:

SQL Server 10.50.1617
unixODBC 2.2.14
PHP 5.4.19



 Description   

If the class is patched with the following:

if ($this->platform instanceof SQLServer2008Platform)

{ $this->preserveSqlOrdering($AST, $sqlIdentifier, $innerSql, $sql); }

It fixes the issue.






[DDC-2605] Console command generates entity stubs that break type hinting contracts. Created: 09/Aug/13  Updated: 12/Aug/13

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

Type: Bug Priority: Major
Reporter: Alex Parker Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cli, orm, stubs, tools, type-hinting
Environment:

Debian Linux (crunchbang)
PHP 5.4.4-14+deb7u2 (cli)
MySQL Server version: 5.5.31-0+wheezy1 (Debian)


Attachments: PNG File thcontract.png    

 Description   

I've found that the doctrine cli tool seems to break PHP's type hinting contracts in the scenario outlined in the attached diagram, following a process outlined in my stack overflow post here: http://stackoverflow.com/questions/18098552/using-symfony-2-cli-tools-how-can-i-generate-getters-and-setters-with-correct-t

The result is code that throws E_STRICT notices which we are loathe to suppress for CI reasons, e.g: Runtime Notice: Declaration of ... should be compatible with ... in ... line ...

As mentioned I have asked on Stack Overflow to no avail, as well as the FreeNode IRC channels starting with #symfony. The response from #symfony is that this is a doctrine issue, with suggestions being made that my problem is that I am using the CLI tools.

I don't think it would be too difficult to fix this issue. I had a quick look at the Doctrine\ORM\Tools\EntityGenerator class and Doctrine\ORM\Tools\Console\Command\GenerateEntitiesCommand and it looks like it should be possible to find the eldest ancestor definition of a function and honour its type hints.

I am open to this being an implementation issue on my end, but I do feel this may be either a bug or an opportunity to improve the CLI tools as for most other purposes they have been a huge benefit to automating my workflow.

Thanks for your time and consideration.






[DDC-2213] Paginator does not work with composite primary key entity Created: 25/Dec/12  Updated: 15/Aug/13

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

Type: New Feature Priority: Major
Reporter: Stanislav Anisimov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: composed, key, paginator
Environment:

php 5.4



 Description   

Paginator does not work with composed primary key.

"Single id is not allowed on composite primary key in entity" exception is thrown here
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Tools/Pagination/WhereInWalker.php#L90

Only first column values are fetched while retrieving primary keys here
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Tools/Pagination/Paginator.php#L173



 Comments   
Comment by Marco Pivetta [ 23/Jan/13 ]

Limitation was confused by issue reporter and considered bug

Comment by Austin Morris [ 15/Aug/13 ]

I'd like to add some additional information because the title and description are misleading.

Paginator does work with composite primary key entities. You just cannot use the Paginator when your query does a fetch join with a collection (a one-to-many or many-to-many association). See the documentation for a brief description:
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/tutorials/pagination.html

In order to use Paginator with a composite primary key entity, you need to instantiate the Paginator with the $fetchJoinCollection flag set to false (it defaults to true). Now, pagination will skip the WhereInWalker which throws an exception when using a composite primary key. Fetch joins with entities (one-to-one or many-to-one) will still work. You can even use a regular join with a collection.

The only "problem" is when your Paginator query calls for a fetch join to a collection. The work around for this is to use a regular join as mentioned above. The drawback is that your paginated entities will not be hydrated with the collection. The collection will have to be lazy-loaded when called upon.





[DDC-2184] [GH-530] Singular form of generated methods should end with 'y' when property ends with 'ies' Created: 04/Dec/12  Updated: 05/Mar/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None

Issue Links:
Duplicate
duplicates DDC-2150 EntityGenerator.php - Guessing singul... Resolved
duplicates DDC-2160 [GH-520] Fix for Doctrine\ORM\Tools\E... Resolved

 Description   

In Doctrine 2.3 the 'add' and 'remove' methods in oneToMany associations have another problem (in earlier versions like 2.2 this worked correct). The singular form is not correctly detected if the property ends with 'ies' like 'entries' which should be transformed to 'entry'.
I have this YAML definition:

Archive:
  type: entity
  fields:
    id:
      id: true
      type: integer
      unsigned: false
      nullable: false
      generator:
        strategy: IDENTITY
  oneToMany:
    entries:
      targetEntity: Entry
      mappedBy: archive

This generates these methods:

public function addEntrie(\Entry $entries) { ... }
public function removeEntrie(\Entry $entries) { ... }

Because in the EntityGenerator only the plural 's' is removed. It would be nice if an ending of 'ies' could be replaced by 'y'. So that we get these methods

public function addEntry(\Entry $entries) { ... }
public function removeEntry(\Entry $entries) { ... }

My fork already has the changes https://github.com/naitsirch/doctrine-orm2/commit/a3adfccb4927d61da7debae46ed0fff61e4212f8
I have opened a pull request here https://github.com/doctrine/doctrine2/pull/530



 Comments   
Comment by Christian Stoller [ 04/Dec/12 ]

Sorry, I accidently clicked on the button 'Request Feedback'
Now the status has changed to 'Awaiting Feedback'

Comment by Benjamin Eberlei [ 06/Jan/13 ]

Mark as improvement

Comment by Ed Page Croft [ 04/Jul/13 ]

Is this issue going to be resolved? It's a major problem for our project - a stock market application that uses properties like 'securities' and entities of name 'Security'.

Comment by Doctrine Bot [ 05/Mar/14 ]

A related Github Pull-Request [GH-530] was closed:
https://github.com/doctrine/dbal/pull/530





[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-1817] Allowing to specify MySQL Collation on Field Basis Created: 08/May/12  Updated: 11/Feb/14

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

Type: Improvement Priority: Major
Reporter: Johannes Schmitt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

It would be nice to be able to specify which collation to use on a field basis.

This would for example be useful when you have case-sensitive (utf8_bin), and case-insensitive (utf8_general_ci) values. Right now, this needs to be manually added to migration files (which is ok for projects, but it is not so nice for distributable libraries).



 Comments   
Comment by Steve Müller [ 26/Nov/13 ]

See the following PRs:

https://github.com/doctrine/dbal/pull/274
https://github.com/doctrine/dbal/pull/245
https://github.com/doctrine/dbal/pull/282

This will be available via column's customSchemaOptions.

Comment by Doctrine Bot [ 11/Feb/14 ]

A related Github Pull-Request [GH-245] was closed:
https://github.com/doctrine/dbal/pull/245





[DDC-1229] generate entity interactive dialog: id column Created: 27/Jun/11  Updated: 28/Jun/11

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

Type: Improvement Priority: Major
Reporter: David Buchmann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

according to Stof, this bug https://github.com/sensio/SensioGeneratorBundle/issues/21 comes from the doctrine tools implementation:

in the dialog, i first specified that i want a field id of type integer. the result was

[Doctrine\ORM\Mapping\MappingException]

Duplicate definition of column 'id' on entity 'Liip\DemoBundle\Entity\Event' in a field or discriminator column mapping.

and no file was created.

The dialog should tell me i can not create a field named id. (Or better ask first if i want my id column named id or something else.)

It would be nice if it would write some file even if its not valid, with a warning on top. As it is, i lost all my work of specifying fields. (Luckily was just playing around)



 Comments   
Comment by Benjamin Eberlei [ 28/Jun/11 ]

not a bug, its a feature (though a dumb one). Improvement in a next version.





[DDC-1217] Use the DBAL ReservedKeywordsValidator in orm:validate-schema Created: 20/Jun/11  Updated: 20/Jun/11

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

Type: Improvement Priority: Major
Reporter: Christophe Coevoet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

DBAL provides a ReservedKeywordsValidator to check whether a word is reserved. But this tool is not used by the ORM when validating the schema. It would be useful to use it to avoid WTF from users getting a PDOException when creating their schema because of this.
The other solution if you don't want to add this in orm:validate-schema would be to create a dedicated command.






[DDC-1137] SchemaTool#getUpdateSchemaSql() does not respect database identifier in table names Created: 05/May/11  Updated: 14/May/11

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

Type: Improvement Priority: Major
Reporter: Hugh Lomas Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux 2.6.18-194.32.1.el5.centos.plus x86_64 GNU/Linux



 Description   

Given two databases, 'foo' and 'bar', with entities in /Entities/Foo/ annotated as follows:

/**
 * Test
 *
 * @Table(name="foo.test")
 * @Entity
 */

Create an EntityManager instance with

$connectionOptions = array( 
    'dbname' => 'Foo', 
    'driver' => 'pdo_mysql', 
    <..etc..>
);

Use EntityManager#getClassMetaData( "Entities\\Foo
Test" ) to pass to SchemaTool#createSchema() and Doctrine appropriately creates a database table foo.test

Use EntityManager#getClassMetaData( "Entities\\Foo
Test" ) to pass to SchemaTool#updateSchema() and Doctrine fails with Exception
-> SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'test' already exists

Inserting

die( print_r( $fromSchema, 1 ) . print_r( $toSchema, 1 ) . print_r( $schemaDiff, 1 ) );

into Doctrine/ORM/Tools/SchemaTool.php line 632 shows $fromSchema outputs

[_tables:protected] => Array
        (
            [test]

but $toSchema outputs

[_tables:protected] => Array
        (
            [foo.test]

which causes $schemaDiff to output

[newTables] => Array
        (
            [foo.test]

In summary, Doctrine/DBAL/Schema/Comparator considers foo.test a new table, because Doctrine/DBAL/Schema/AbstractSchemaManager lists its table as "test" rather than "foo.test".



 Comments   
Comment by Hugh Lomas [ 05/May/11 ]

It seems that changing AbstractSchemaManager.php to the following corrected the issue for me, however I am not sure of any repercussions that may arise as a result, being unfamiliar with the codebase.

Doctrine/DBAL/Schema/AbstractSchemaManager.php line 228

return new Table( $tableName, $columns, $indexes, $foreignKeys, false, array());

Doctrine/DBAL/Schema/AbstractSchemaManager.php line 228

return new Table( $this->_conn->getDatabase() . "." . $tableName, $columns, $indexes, $foreignKeys, false, array());

Comment by Benjamin Eberlei [ 14/May/11 ]

Multi databases are not supported by schema manager and schema tool yet.





[DDC-896] Use PDepend for Code-Generation Created: 27/Nov/10  Updated: 27/Nov/10

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Our current code-generation tool has many shortcomings and due to its hard to test nature also many (known and unknown) bugs, as well as high maintenance.

Since people are overusing this tool and I am sort of annoyed by how much time goes into this we should rewrite this in a two-step procedure:

1. Move code into Common so we can share it between ORM, Mongo and CouchDB.
2. Use PDepend to read an entities source file (it generates an AST) and modify the AST with the required changes.

This gives us the advantage of having to maintaining less code for this stuff.






[DDC-813] Validate Schema should complain on bi-directional relationships with mapped superclasses Created: 21/Sep/10  Updated: 29/Oct/12

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

@ManyToOne and @OneToOne on mapped superclasses have to be unidirectional. The Schema Validator should verify this.






[DDC-3036] [doctrine:generate:entities] Created: 17/Mar/14  Updated: 17/Mar/14

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

Type: Improvement Priority: Minor
Reporter: Miguel Simões Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

When using an Entity that is extended by some other class (that may not be a Doctrine Entity), the command doctrine:generate:entities should not create getters/setters that are already defined in the parent class.






[DDC-2980] SchemaTool should report what entities cause a duplicate table Created: 13/Feb/14  Updated: 13/Feb/14

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

Type: Improvement Priority: Minor
Reporter: David Buchmann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

after an afternoon of debugging in all directions, i found out that somebody had copied an entity without changing the table name annotation. i guess next time i see that kind of error, i will look into that possibility sooner, but still, it would be very helpful if the SchemaTool could in addition to "The table with name 'doctrine.fos_user' already exists." also explain which two entities asked for that table to be created.






[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-2897] SchemaTool->update() deletes all tables that not belongs to the schema Created: 09/Jan/14  Updated: 09/Jan/14

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

Type: Bug Priority: Minor
Reporter: do.ev. Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

linux, apache, mysql, php, only tested with the zf2-doctrine modules



 Description   

$tool = new \Doctrine\ORM\Tools\SchemaTool($em);
$tool->updateSchema($em->getMetadataFactory()->getAllMetadata());

=> all Tables that not belong to the schema are gone. If you use the commandline tool for update, tables that not belong to the schema are not touched.






[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-2754] Composer: "cat doctrine >> doctrine.php doctrine.php.bat" Created: 22/Oct/13  Updated: 22/Oct/13

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

Type: Bug Priority: Minor
Reporter: Dominic Guhl Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: composer, packagist
Environment:

Win7 x64, PHP 5.5.3, Composer v2013-10-21 (triggered via NetBeans 7.4)



 Description   

If one is triggering a Composer update, doctrine file content overwrites doctrine.php content and creates doctrine.php.bat with the same content. Before the update, none of these files were existent.

(The summary of this issue suggests what actually happens, not what has been executed by Composer or me, neither it appears in the logs!)

The reason why I reported here first is that these files are only in your repository, from all repositories I have chosen.

Composer Setup was:

    "require": {
        "php": ">=5.3.3",
        "zendframework/zendframework": "2.2.*",
        
        "doctrine/doctrine-module": "0.8.*@dev",
        "doctrine/doctrine-orm-module": "0.8.*@dev"
        
    }, 

...and few requirements were recursively solved on executing update:

    symfony/console (v2.3.6)
    doctrine/orm (v2.4.0)

My first suggest would be that composer can't handle unsuffixed files on Windows. If you can confirm this instead of a bug in Doctrine 2, the Composer project may gets a line dropped?

Possible workaround could be the renaming of doctrine to doctrine.sh.

Thanks!






[DDC-2570] Doctrine CLI Tools - Clear All Cache Created: 24/Jul/13  Updated: 08/Feb/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: ORM, Tools
Affects Version/s: 2.3.4
Fix Version/s: 2.x, 2.5

Type: Improvement Priority: Minor
Reporter: Frederick Marcoux Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli, cache, orm


 Description   

It would be nice to be able to clear all cache one shot instead of clearing them one after one...

Like this:

root$ ./doctrine orm:clear-cache:all

Instead of:

root$ ./doctrine orm:clear-cache:metadata
root$ ./doctrine orm:clear-cache:result
root$ ./doctrine orm:clear-cache:query






[DDC-2569] Unable to reverse engineer non "dbo" schema table Created: 24/Jul/13  Updated: 24/Jul/13

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

Type: Bug Priority: Minor
Reporter: Paul Mansell Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: sqlserver


 Description   

I am unable to reverse engineer a table with a non "dbo" schema from Microsoft SQL Server 2008. The "getListTablesSQL" SQL returns a list of tables without the schema name. An alternative would be to use the SQL :

SELECT '['+SCHEMA_NAME(schema_id)+'].['+name+']' AS name FROM sys.tables

instead - this returns the list of table with the schema name.






[DDC-2522] When changing a manyToMany relationship to a stand alone table with the same table name, doctrine fails to properly update schema. Created: 20/Jun/13  Updated: 05/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: Bug Priority: Minor
Reporter: Jeremy Moore Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: None
Environment:

Discovered while using doctrine orm in Symfony 2.1. MySQL



 Description   

To start with I created a manyToMany relationship in my user entity to my referrers entity. The association was named "referrals" and used a table named "user_referrals" as the manyToMany join table.

I later removed the manyToMany join association in favor of a stand-alone entity. I created an entity named UserReferrals. I kept the table name "user_referrals".

When doctrine attempts to update the mysql database schema, I receive this error...

SQLSTATE[42000]: Syntax error or access violation: 1075 Incorrect table definition; there can be only one auto column and it must be defined as a key

This is the SQL attempting to be executed:
ALTER TABLE user_referrals ADD id INT AUTO_INCREMENT NOT NULL, ADD created DATETIME NOT NULL, ADD updated DATETIME NOT NULL, ADD status VARCHAR(255) NOT NULL, CHANGE referrer_id referrer_id INT DEFAULT NULL, CHANGE user_id user_id INT DEFAULT NULL

Is this a bug? Running the SQL directly in MYSQL also fails with the same error.



 Comments   
Comment by Peter Rehm [ 05/Nov/13 ]

In the SQL Statement there is the primary key definition missing. In your case the adjustment to

ALTER TABLE user_referrals ADD id INT AUTO_INCREMENT NOT NULL, ADD PRIMARY KEY (id), ADD created DATETIME NOT NULL, ADD updated DATETIME NOT NULL, ADD status VARCHAR(255) NOT NULL, CHANGE referrer_id referrer_id INT DEFAULT NULL, CHANGE user_id user_id INT DEFAULT NULL

should make it.

If have the same issue where the schema tool / migrations generated the following statements:

ALTER TABLE ArticleToSet DROP PRIMARY KEY
ALTER TABLE ArticleToSet ADD id INT AUTO_INCREMENT NOT NULL, CHANGE article_id article_id INT DEFAULT NULL, CHANGE articleSet_id articleSet_id INT DEFAULT NULL
ALTER TABLE ArticleToSet ADD PRIMARY KEY (id)

Updating it manually to the following fixes it:

ALTER TABLE ArticleArticleToSet DROP PRIMARY KEY"
ALTER TABLE ArticleArticleToSet ADD id INT AUTO_INCREMENT NOT NULL, ADD PRIMARY KEY (id), CHANGE article_id article_id INT DEFAULT NULL, CHANGE articleSet_id articleSet_id INT DEFAULT NULL

The situation appeared when I have changed from a composite key to a separate key.





[DDC-2515] Schema tool ignores index names in mapping file and uses generated name Created: 18/Jun/13  Updated: 21/Jun/13

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

Type: Bug Priority: Minor
Reporter: Daniel Huss Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File ddc-2515.testcase.patch    

 Description   

I have defined an index on a foreign key colum in my .dcm.xml mapping file:

<indexes>
      <index name="ix_date_created__client_id" columns="date_created,client_id"/>
      <index name="ix_user_id" columns="user_id"/>
</indexes>

However, the resulting CREATE TABLE statement includes:

    INDEX IDX_4848DD9FA76ED395 (user_id), 
    INDEX IDX_4848DD9F4239E22F (accessgroup_id), 
    INDEX IDX_4848DD9FD2112630 (usergroup_id), 
    INDEX ix_date_created__client_id (date_created, client_id), 

So Doctrine seems to be auto-generating indexes for all foreign key columns. I'm assuming this is a feature, even though I'd argue that there are real-life examples where the mere presence of a foreign key constraint does not justify indexing that column.

Anyway, the expected behavior is that Doctrine does not replace existing indexes with generated ones. I will attach a failing test case unless this bug is immediately dismissed as wontfix.



 Comments   
Comment by Daniel Huss [ 21/Jun/13 ]

Test case for SchemaToolTest





[DDC-2509] Add CLI detection for the APC check on Console cache commands Created: 17/Jun/13  Updated: 17/Jun/13

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

Type: Improvement Priority: Minor
Reporter: Jonathan Cardoso Machado Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

There is some instanceof checks on the \Doctrine\ORM\Tools\Console\Command\ClearCache* commands to detect if APC is being used, they were introduced here: https://github.com/doctrine/doctrine2/commit/8efae0b232210b27200f2709e7fcb24c7f02c5de

I would like to know if it's possible to add a CLI check too, something like:

if ($cacheDriver instanceof Cache\ApcCache && PHP_SAPI === 'cli' )

Yeah, I know that those are CLI commands, and so the check looks like unecessary, however, in the particular case that I found it's necessary, I'm running the commands under an WebUI:
Before the modification:

After:



 Comments   
Comment by Marco Pivetta [ 17/Jun/13 ]

CLI commands are not meant to be used in WEB environment (at least not the Symfony CLI ones). You should probably replicate that logic instead.





[DDC-2467] Incorrect work with default values, indexes, autoincrement (patch attached) Created: 23/May/13  Updated: 28/May/13

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

Type: Improvement Priority: Minor
Reporter: And Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File ORM.patch    

 Description   

If you use in your MySQL database default values, indexes or string primary key, you get incorrect mapping by mapping generator. For get it - just use in database one or more from listed abilities, generate mapping for that and then try to dump-sql with schema-tool:update.

Hope you fix it. Tnx!



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

Marked as minor improvement - thank you for the patch!

Comment by And [ 28/May/13 ]

When it will be merged? Maybe, planned version?

Comment by Marco Pivetta [ 28/May/13 ]

And such a patch requires failing tests before being applied - that's up to whoever picks it up.

Comment by And [ 28/May/13 ]

So if I add patch with tests - it will be merged? =)

Comment by Marco Pivetta [ 28/May/13 ]

Most probably - you can open a pull request against the current ORM master for that





[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-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-2236] SUM(..) with Pagination gives incorrect result Created: 11/Jan/13  Updated: 10/Feb/13

Status: In Progress
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.2.3
Fix Version/s: None

Type: Documentation Priority: Minor
Reporter: Oleg Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: paginator
Environment:

Linux



 Description   

https://github.com/whiteoctober/Pagerfanta/issues/69

<?php
$query = $em->getRepository('M\E\Q')
->createQueryBuilder('q')
->select('q', 'SUM(q.price) AS amount')
->where('q.id IN(19, 20, 22)')
->groupBy('q.customer')
;

$pager = new Pagerfanta(new DoctrineORMAdapter($query));
$pager->setMaxPerPage(30);
$pager->setCurrentPage($request->query->get('page', 1));

$result = $pager->getCurrentPageResults();
print_r($result[0]['amount']); // 156.71 - Incorrect

$result = $query->getQuery()->getResult();
print_r($result[0]['amount']); // 553.47
?>

Sql for the above:

SELECT DISTINCT id0 FROM (SELECT q0_.id AS id0, SUM(q0_.price) AS sclr36 FROM Q q0_ WHERE q0_.id IN (19, 20, 22) GROUP BY q0_.customer_id) dctrn_result LIMIT 30 OFFSET 0
SELECT q0_.id AS id0, SUM(q0_.price) AS sclr36 FROM Q q0_ WHERE q0_.id IN (19, 20, 22) AND q0_.id IN ('19') GROUP BY q0_.customer_id
SELECT q0_.id AS id21, SUM(q0_.price) AS sclr36 FROM Q q0_ WHERE q0_.id IN (19, 20, 22) GROUP BY q0_.customer_id

Sql with fetchJoin = false (new DoctrineORMAdapter($query, false))

SELECT q0_.id AS id0, SUM(q0_.price) AS sclr36 FROM Quote q0_ WHERE q0_.id IN (19, 20, 22) GROUP BY q0_.customer_id LIMIT 30 OFFSET 0
SELECT q0_.id AS id0, SUM(q0_.price) AS sclr36 FROM Quote q0_ WHERE q0_.id IN (19, 20, 22) GROUP BY q0_.customer_id



 Comments   
Comment by Alexander [ 09/Feb/13 ]

Can you also test this with doctrine >= 2.3? The pagination code changed quite a lot.

Comment by Oleg [ 10/Feb/13 ]

Looks like no change

composer.json:
"doctrine/orm": "2.3.*",

php composer.phar update
Loading composer repositories with package information
Updating dependencies

  • Installing doctrine/common (2.3.0)
    Loading from cache
  • Installing doctrine/dbal (2.3.2)
    Loading from cache

then cleared cache but result is same
Here's the code

 
$query = $this->getDoctrine()->getEntityManager()->getRepository('MyBundle:Invoice')
  ->createQueryBuilder('q')
  ->select('q', 'SUM(q.amount) AS amount')
  ->groupBy('q.customer')
;
 
95 Connect	root@localhost on **
95 Query	SELECT DISTINCT id0 FROM (SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9 FROM Invoice i0_ GROUP BY i0_.customer_id) dctrn_result LIMIT 30 OFFSET 0
95 Query	SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9, i0_.customer_id AS customer_id10 FROM Invoice i0_ WHERE i0_.id IN ('2') GROUP BY i0_.customer_id
95 Query	SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9, i0_.customer_id AS customer_id10 FROM Invoice i0_ GROUP BY i0_.customer_id
130210 16:08:25	   95 Quit	

But I understand why that happens, it's due to group by and pagination nature.
The first query returns only one row with id "2", second query should be actually "..WHERE i0_.id IN ('2', '3', '4')"

If I do

$pager = new Pagerfanta(new DoctrineORMAdapter($query, false));

I get this sql

SELECT i0_.id AS id0, i0_.invoice_num AS invoice_num1, i0_.date AS date2, i0_.amount AS amount3, i0_.vat_amount AS vat_amount4, i0_.amount_paid AS amount_paid5, i0_.md5 AS md56, i0_.is_exported AS is_exported7, i0_.created AS created8, SUM(i0_.amount) AS sclr9, i0_.customer_id AS customer_id10 FROM Invoice i0_ LIMIT 30 OFFSET 0

I think it should be noted somewhere that if you do groupBy you should set fetchJoin to false?

Comment by Marco Pivetta [ 10/Feb/13 ]

Updating to Documentation issue.





[DDC-1413] Automatically create index for discriminator column Created: 11/Oct/11  Updated: 12/Jun/13

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

Type: Improvement Priority: Minor
Reporter: A.J. Brown Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

It would be nice if the command line orm schema-tool would suggest an index on the discriminator column for single inheritance tables. Since that column would almost always be in the query, I can't think of a case when you wouldn't want it to be in an index



 Comments   
Comment by Menno Holtkamp [ 12/Jun/13 ]

This topic suggests it is a bad practice though:
https://forum.hibernate.org/viewtopic.php?f=9&t=961578

In case of a big STI hierarchy, this might become usefull, additional testing required. However, as soons as a STI hierarchy becomes big, Class Table Inheritance might be more appropriate...





[DDC-1206] Add option to SchemaTool for ignoring unsupported tables Created: 13/Jun/11  Updated: 05/Mar/12

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

Type: New Feature Priority: Minor
Reporter: Jani Hartikainen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

I suggest adding a new feature to SchemaTool, which allows you to ignore tables, which contain unsupported column types.

Use case:

  • You have a legacy database, or a database that is also shared with another application
  • You want to use SchemaTool to speed up development
  • The database contains tables which are not used in the Doctrine 2 application, and contain unsupported column types

I've encountered this already a few times myself - Basically if you try to use orm:schema-tool:update with a database that contains tables with unsupported column types, it'll throw an error and you won't be able to use it at all. Because schema tool is extermely convenient when developing, I think it would be very useful to have support for this feature.

Implementation:

I think this should be doable by just changing SchemaTool/SchemaManager so, that SchemaManager would contain an additional method (or flag) which works like createSchema, but ignores tables that cause an exception, and SchemaTool would include a flag for using this instead of the standard approach.

I'm looking into implementing this myself, and will submit a patch if this seems like a reasonable approach.



 Comments   
Comment by Jani Hartikainen [ 15/Jun/11 ]

Relevant patches (pull request made):

DBAL https://github.com/jhartikainen/dbal/tree/DDC-1206
ORM https://github.com/jhartikainen/doctrine2/tree/DDC-1206

Comment by Michael Graf [ 05/Mar/12 ]

has there been any progres on this feature? I have POINT in my DB and would rather ignore the table than create a custom type.





[DDC-977] Allow for multiple filters to be set from the command line Created: 11/Jan/11  Updated: 11/Jan/11

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: Stephen Lang Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

OSX, PHP 5.3, MySQL 5.1



 Description   

I'm working with an existing database with a large number of tables, I would like to generate metadata mappings for a subset of tables using the command below. The Doctrine code states that the 'filter' option should be an array but there doesn't seem to be any way to pass in an array from the command line? Is the command below the syntax intended for the filter option? If so this may be a Symfony issue?

Command
php doctrine.php orm:convert-mapping --filter="TableOne" --filter="TableTwo" --from-database xml /Path/To/Metadata

Expected result
Processing entity "TableOne"
Processing entity "TableTwo"
Exporting "xml" mapping information to "/Path/To/Metadata"

Actual result
Processing entity "TableTwo"
Exporting "xml" mapping information to "/Path/To/Metadata"

Relevant code
http://j.mp/eJD963 (Doctrine/ORM/Tools/Console/Command/ConvertMappingCommand.php)
http://j.mp/f1ADXm (Symfony/Component/Console/Input/ArgvInput.php)



 Comments   
Comment by Stephen Lang [ 11/Jan/11 ]

Changed priority to minor.





[DDC-900] Insufficient Error Information for orm:validate-schema Created: 29/Nov/10  Updated: 29/Nov/10

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

Type: Improvement Priority: Minor
Reporter: aurorius Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 2
Labels: None
Environment:

linux, php 5.3.3



 Description   

Running "doctrine orm:validate-schema" would return -> [Database] FAIL - The database schema is not in sync with the current mapping file.

It should have at least return the name of the table/field that is not in sync.






[DDC-838] SchemaTool - ignores the attribute uniq in relations Created: 13/Oct/10  Updated: 29/Oct/10

Status: Open
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.0-BETA4
Fix Version/s: 2.x
Security Level: All

Type: Improvement Priority: Minor
Reporter: gektor Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu, PHP 5.3.2, MySQL



 Description   
Mapper
<entity name="Default_Model_Test" table="test">
  <id name="id" type="integer" column="id">
    <generator strategy="AUTO"/>
  </id>
  <field name="blabla" column="blabla" type="boolean"/>
  <one-to-one field="user" target-entity="Users_Model_User">
    <join-column name="users_id" referenced-column-name="id" on-delete="CASCADE" on-update="CASCADE" unique="false" />
  </one-to-one>
</entity>
SQL
CREATE TABLE test (id INT AUTO_INCREMENT NOT NULL, users_id INT DEFAULT NULL, blabla TINYINT(1) NOT NULL, UNIQUE INDEX test_users_id_uniq (users_id), PRIMARY KEY(id)) ENGINE = InnoDB;
ALTER TABLE test ADD FOREIGN KEY (users_id) REFERENCES users(id) ON UPDATE CASCADE ON DELETE CASCADE;

Actual:
UNIQUE INDEX test_users_id_uniq (users_id)

Expected:
INDEX test_users_id (users_id)



 Comments   
Comment by Benjamin Eberlei [ 14/Oct/10 ]

Verified, i just don't understand why you are using a one-to-one relation and then "deactivate" the database constraint for this. You could easily use Many-To-One

Comment by gektor [ 14/Oct/10 ]

You are right. It's not a bug, it's feature.

Comment by Benjamin Eberlei [ 29/Oct/10 ]

This might still be a good improvement to allow the flexibility, but its not a bug. Updating to "Minor Improvmenet for 2.x"





[DDC-1614] On OneToOne mappings with Primary Key same as Foreign Key, using @Id in the foreign association does not carry over when running "generate-entities" with --generate-annotations=1 Created: 22/Jan/12  Updated: 23/Jan/13

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

Type: Improvement Priority: Trivial
Reporter: Ryan Fink Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Fedora 15, php 5.3.8



 Description   

When having a OneToOne mapping that has a primary key that is the same as the foreign key, using the @Id attribute does not carry over when generating entities.

Example code:

class User
{
/**

  • @Id @Column(type="integer", nullable=false, columnDefinition="INT UNSIGNED NOT NULL AUTO_INCREMENT")
  • @GeneratedValue(strategy="AUTO")
    */
    private $id;

/**

  • @OneToOne(targetEntity="User_ExtraAttrs", cascade= {"persist","remove","detach","merge","refresh"}

    , mappedBy="User")

  • @JoinColumn(name="id", referencedColumnName="id")
    */
    private $UserAttrs;
    }

class User_ExtraAttrs
{
/**

  • @OneToOne(targetEntity="User", cascade= {"all"}

    , inversedBy="UserAttrs")

  • @Id
  • @JoinColumn(name="VehicleID", referencedColumnName="VehicleID")
    */
    private $User;
    }

When running "doctrine orm:generate-entities --regenerate-entities=1 --generate-annotations=1", the @Id in User_ExtraAttrs does not carry over. It must be manually inserted.






[DDC-1004] Option for mapping:import to not write Entity Files if they exist Created: 27/Jan/11  Updated: 27/Jan/11

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

Type: Improvement Priority: Trivial
Reporter: s.rohweder Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

There should be an option to omit the creation of allready existing entities:

Use Case:

if you develop your model in the database and create the entities with the cli and then go on with development and create new tables you would build the entities again with the cli. This will kill your allready existing and possible extended entities.

Best would be if you have to set the option when you want the existing entities overwritten. so you cant accidently overwrite them






Generated at Fri Apr 18 21:02:56 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.