[DDC-3535] Allow binding `Parameter` value object to statements, removing the need for explicit value and type passing Created: 24/Jan/15  Updated: 24/Jan/15

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

Type: Task Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: binding, criteria, parameters, persister, repository, type


 Comments   
Comment by Marco Pivetta [ 24/Jan/15 ]

We currently have a lot of locations in the code where we use list($values, $types) = $this->computeParameters(); (pseudo-code).

This leads to a lot of code duplication and complexity.

Maybe a Parameter VO may be used instead, or a ParameterCollection with a fixed $types and a mutable $values, and with minimal internal validation.





[DDC-3512] Redesign ClassMetadata API as ValueObject based (for type-safety and self-documentation) Created: 17/Jan/15  Updated: 18/Jan/15

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

Type: Improvement Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: classmetadatafactory, cleanup, metadata, performance, type-safety

Issue Links:
Reference
relates to DDC-3503 [GH-1257] Resolve target entity also ... Resolved

 Description   

The current ClassMetadata API is based on a lot of array juggling (for performance reasons).

While that was understandable with PHP 5.3, all the array access operations are currently:

  • slowing things down
  • making the code very hard to read/understand

I suggest re-coding the ClassMetadata internals (public properties and such) so that well-described properties are defined.

Additionally, as a bonus, we'd get a performance boost by just moving all the class-alias and type resolution logic from the runtime into the ClassMetadataFactory (or similar) API, saving tons of performance at every run.

In pseudo-logic, what I'd like to achieve with DDC-3512 is:

  • base metadata is loaded from the mapping driver
  • onLoadMetadata event is fired for each loaded metadata instance
  • metadata is completed by the ClassMetadataFactory logic
  • onCompleteMetadata event is fired for each loaded metadata instance

This would make metadata manipulation from events a bit messier (user needs to know which value to change during which event), but would allow using better constrained metadata structures in future, and that would disallow mistakes during event listeners execution as well (internal validation).






[DDC-3441] Unidirectional ManyToOne Not Lazy Loading Created: 09/Dec/14  Updated: 24/Jan/15

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

Type: Bug Priority: Critical
Reporter: Marcus Fulbright Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: lazy-loading, proxy, public-properties, reflection

Issue Links:
Dependency
depends on DDC-3442 [GH-1217] @DDC3441 failing test cases... Open

 Description   

The Unidirectional ManyToOne association described in the docs does not lazy load correctly. The appropriate SQL will get executed, and the returned Proxy does pass type hinting for the correct class. However, the lazy loaded object always has the following properties:

  • _initializer_
  • _cloner_
  • _isInitialized_
  • lazyPropertiesDefaults

Any properties from the class definition do not show up. This is problematic when trying to get reflected properties and their values. Methods are correctly reflected.

Pull request for failing test case



 Comments   
Comment by Marcus Fulbright [ 09/Dec/14 ]

Let me know if anything else is needed.

Comment by Doctrine Bot [ 11/Dec/14 ]

A related Github Pull-Request [GH-1217] was assigned:
https://github.com/doctrine/doctrine2/pull/1217

Comment by Marco Pivetta [ 11/Dec/14 ]

Looks like a current ORM limitation (private properties lazy loading).

Related:

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1217] was labeled:
https://github.com/doctrine/doctrine2/pull/1217

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1217] was labeled:
https://github.com/doctrine/doctrine2/pull/1217





[DDC-3360] Problem custom name sequeceGenerator YAML for annotatition entities Created: 22/Oct/14  Updated: 29/Oct/14

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

Type: Bug Priority: Critical
Reporter: Sandro Cândido de Oliveira Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi Benjamin

Problem custom name sequeceGenerator YAML why not create the custom name you want. Being created the default postgres, where is the problem?

Note: https://groups.google.com/forum/#!topic/doctrine-user/7ctTFGWu4mo

Message:

  type: entity
  id:
    id:
      type: integer
      generator:
        strategy: SEQUENCE
      sequenceGenerator:
        sequenceName: message_sq
        allocationSize: 100
        initialValue: 1

The entity is created like this:

namespace message\models\entities;

use Doctrine\ORM\Mapping as ORM;

/**
 * Message
 *
 * @ORM\Table(name="message")
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class Message
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="SEQUENCE")
     * @ORM\SequenceGenerator(sequenceName="message_id_seq", allocationSize=1, initialValue=1)
     */

Should be created as specify:

/**
 * Message
 *
 * @ORM\Table(name="message")
 * @ORM\Entity
 * @ORM\HasLifecycleCallbacks
 */
class Message
{
    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="SEQUENCE")
     * @ORM\SequenceGenerator(sequenceName="message_sq", allocationSize=1, initialValue=1)
     */


 Comments   
Comment by Marco Pivetta [ 22/Oct/14 ]

Is the bug reproducible also in 2.4.6?

Comment by Steve Müller [ 22/Oct/14 ]

Moved to ORM issue tracker. This is not DBAL related.

Comment by Sandro Cândido de Oliveira [ 29/Oct/14 ]

Hi

Is the bug reproducible also in 2.4.6 and 2.5.0-DEV





[DDC-3212] Remove ArrayHydrator logic Created: 14/Jul/14  Updated: 13/Oct/14

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

Type: Improvement Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: hydration, hydrator


 Description   

The Doctrine\ORM\Internal\Hydration\ArrayHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php ) is currently very messy and complicated due to the lack of actual Doctrine\ORM\UnitOfWork references when working with it, since we are not dealing with objects.

In order to reduce the amount of bugs and code duplication when working with array hydration, I would simply suggest making use of the Doctrine\ORM\Internal\Hydration\ObjectHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php ) and its siblings, and then extracting data coming from the results in it as an array.

This could be a simple reflection-based extraction (pseudo):

class ArrayHydrator
{
    public function hydrateAllData()
    {
        foreach ($this->objectHydrator->hydrateAllData() as $object) {
            yield $this->extractData($object);
        }
    }
}

The point here is that array-based hydration is not the primary focus of the ORM, and users should probably rely on SQL only when they want array hydration.



 Comments   
Comment by Marco Pivetta [ 14/Jul/14 ]

Note: performance is one of our biggest requirements, and array hydration is meant to achieve that. As I stated above, plain SQL is probably better for this sort of operation, so the issue is more about deprecating the ArrayHydrator completely, providing utilities to manipulate SQL resultsets instead.





[DDC-2953] ArrayHydrator: Not all items hydrated while orderBy Created: 05/Feb/14  Updated: 18/Aug/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: Critical
Reporter: Mariusz Jaskółka Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: array, hydration
Environment:

Linux and Windows, PHP5


Attachments: File ArrayHydrator.php     File Array_Hydrator_4.2.php     File Array_hydrator_4.2_bugfix.php    
Issue Links:
Dependency
depends on DDC-2955 [GH-933] [WIP] DDC-2953 Resolved

 Description   

I will explain the problem using example and pseudo-code:

I have query like that:
SELECT (...) FROM order LEFT JOIN person LEFT JOIN identifier (...) order by (...)

The rows returned by query are following (the order is very important):
order_id|person_id|identifier_id|
12 |21 |33 |
12 |21 |34 |
11 |21 |35 |
11 |21 |33 |
11 |21 |34 |
12 |21 |35 |

After hydration the result is like:
result[0][person][identifier][0][id]=33
result[0][person][identifier][0][id]=34
result[1][person][identifier][0][id]=35
result[1][person][identifier][0][id]=34

But it should be:
result[0][person][identifier][0][id]=33
result[0][person][identifier][0][id]=34
result[0][person][identifier][0][id]=35
result[1][person][identifier][0][id]=35
result[1][person][identifier][0][id]=34
result[1][person][identifier][0][id]=33

The reason is that ArrayHydrator::_identifierMap contains only object id and parents object id. In may example there is difference in parents parent (grandparent) id.



 Comments   
Comment by Marco Pivetta [ 05/Feb/14 ]

I've started work on this at https://github.com/doctrine/doctrine2/pull/933

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

This is how I temporary solved the issue, maybe it can help (attachment).

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka can you provide a diff with current master? This seems to be based off 2.3 or previous versions...

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

Version 2.4.2 oryginal file and bugfix

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

Oh sorry it is version 2.4.1 (composer downloaded that version for me).
I hope it will be ok.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka thanks! I'm trying it right now

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

I added one dimention to $this->_identifierMap to be sure that all object's children's keys will be mapped separately.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka, I've applied your hotfix at https://github.com/doctrine/doctrine2/commit/c05921032ff6947daca2d7275031e5cde4700634 and the tests seem to pass on my system and on travis. You may want to check it out and see if it works for your use case.

Comment by Mariusz Jaskółka [ 06/Feb/14 ]

It works for my use case correctly. You apparently forgot to remove/comment line 82 which is not necessary now.

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka fixed, thanks!

Comment by Marco Pivetta [ 14/Jul/14 ]

I don't think we'll have a fix for this issue for 2.5, as it will probably require a complete rewrite of the array hydrator

Comment by Guilherme Blanco [ 14/Jul/14 ]

... and introducing BC breaks.

Comment by Doctrine Bot [ 18/Aug/14 ]

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





[DDC-3644] One To Many Relationships do not properly support Orphan Removal Created: 27/Mar/15  Updated: 27/Mar/15

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

Type: New Feature Priority: Major
Reporter: Jarrett Croll Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

After speaking to @guilhermeblanco you assume the following method is unreachable when in fact it is not:

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/Collection/OneToManyPersister.php#L39

If an entity currently has a persistent collection in a 1-m relationship and that persistent collection is replaced with a new collection the entities not contained in that new collection should be scheduled for deletion but they are not.






[DDC-3639] [GH-1349] Fix #1347 Created: 26/Mar/15  Updated: 27/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

Url: https://github.com/doctrine/doctrine2/pull/1349

Message:

This PR fixes #1347.



 Comments   
Comment by Doctrine Bot [ 27/Mar/15 ]

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





[DDC-3635] QueryBuilder - INSTANCE OF with parameter not working Created: 24/Mar/15  Updated: 25/Mar/15

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

Type: Bug Priority: Major
Reporter: Wouter Wiltenburg Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: binding, dql, parameter
Environment:

Zend Framework 2



 Description   

I use single table class inheritance.
When I write my INSTANCE OF clause in my QueryBuilder like this:

    $result = $this->createQueryBuilder('o')
        ->leftJoin('o.child', 'c')
        ->where('c INSTANCE OF :entity_class')
        ->setParameter('entity_class', 'My\Entity\Class')
        ->getQuery()
        ->getResult();

It does not work correctly. The problem seems to lie in the fact that the parameter is bound to the SQL query. So if I change the entity_class to the discriminator column name it works correctly.

So if the discriminator value for My\Entity\Class would be discriminator then this does work:

    $result = $this->createQueryBuilder('o')
        ->leftJoin('o.child', 'c')
        ->where('c INSTANCE OF :entity_class')
        ->setParameter('entity_class', 'discriminator')
        ->getQuery()
        ->getResult();

So the step for getting the discriminator column from the class name is missing and instead the class name is bound to the MySql query directly.






[DDC-3633] Schema creation problem on PostgreSQL Created: 22/Mar/15  Updated: 22/Mar/15

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

Type: Bug Priority: Major
Reporter: Dmitry Korotovsky Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: schematool


 Description   

Schema tool can't create correct schema on empty database in PostgreSQL:

$ php app/console doctrine:schema:create --env=test
ATTENTION: This operation should not be executed in a production environment.

Creating database schema...

[Doctrine\ORM\Tools\ToolsException]
Schema-Tool failed with Error 'An exception occurred while executing 'CREATE SCHEMA public':
SQLSTATE[42P06]: Duplicate schema: 7 ERROR: schema "public" already exists' while executing DDL: CREATE SCHEMA public






[DDC-3618] Refactor PersistentCollection Created: 16/Mar/15  Updated: 16/Mar/15

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

Type: Improvement Priority: Major
Reporter: Varga Bence Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: collection, orm


 Description   

PersistentCollection - a final class - contains all the metadata, used to speed up updates (through $snapshot). This information should be removed from the collection object and stored elsewhere, loosely coupled.

Doctrine2 uses the data mapper pattern (instead of Doctrine1's active record approach). This tells me that the designers see the importance of freedom which comes with loose coupling. Entities don't have to extend fixed base classes, why do collections?

Use case: I would like to use a wrapper around Collection (my current environment requires collections to have a certain functionality). This is possible in theory, but as I do the first step I'm losing all the advantages coming with PersistentColelction. Since it is a final class and logically an interface by itself (see the sniffing in ObjectHydrator#initRelatedCollection) it is impossible to create a wrapper which exposes the same functionality.

A short-term solution would be to extract an interface from PersistentColelction. A long-term one would be to manage the persisted state (currently PersistentCollection#snapshot) elsewhere (accessed through the EntityManager maybe).






[DDC-3610] [GH-1328] [DDC-3609] Syntax error in class table inheritance join when WITH is used in DQL query Created: 10/Mar/15  Updated: 16/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of adeanzan:

Url: https://github.com/doctrine/doctrine2/pull/1328

Message:

I've added a test case to reproduce this issue. It's a bit contrived, but hopefully gives you enough to go on.



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1328] was labeled:
https://github.com/doctrine/doctrine2/pull/1328





[DDC-3609] Syntax error in class table inheritance join when WITH is used in DQL query Created: 10/Mar/15  Updated: 16/Mar/15

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

Type: Bug Priority: Major
Reporter: Alex Dean Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using WITH on entities that use class table inheritance I'm seeing a syntax error in the generated SQL. Two "ON" statements show up:

INNER JOIN DDCNEWOrder d4_ ON d3_.id = d4_.id ON (d4_.id = d0_.id)

PR: https://github.com/doctrine/doctrine2/pull/1328



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1328] was labeled:
https://github.com/doctrine/doctrine2/pull/1328





[DDC-3605] [GH-1324] load all many to many join columns Created: 08/Mar/15  Updated: 10/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of fabiocarneiro:

Url: https://github.com/doctrine/doctrine2/pull/1324

Message:

the ```$joinColumnElement``` variable is created inside the foreach loop, and used only after it finishes, causing only the last join column to be loaded.



 Comments   
Comment by Doctrine Bot [ 10/Mar/15 ]

A related Github Pull-Request [GH-1324] was labeled:
https://github.com/doctrine/doctrine2/pull/1324

Comment by Doctrine Bot [ 10/Mar/15 ]

A related Github Pull-Request [GH-1324] was assigned:
https://github.com/doctrine/doctrine2/pull/1324





[DDC-3604] [GH-1323] - added isset validation for "inversedBy" Created: 08/Mar/15  Updated: 16/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of kokspflanze:

Url: https://github.com/doctrine/doctrine2/pull/1323

Message:



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1323] was labeled:
https://github.com/doctrine/doctrine2/pull/1323

Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1323] was labeled:
https://github.com/doctrine/doctrine2/pull/1323





[DDC-3603] Readonly columns Created: 06/Mar/15  Updated: 06/Mar/15

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

Type: New Feature Priority: Major
Reporter: Przemyslaw Wrobel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Sometimes I have a column that is calculated (or have a default value) at the database side. When inserting a new record doctrine issues NULL into such a column that causes problems on some DBMS. I would like to annotate such columns as readonly so that doctrine would skip them in INSERT and UPDATE clauses but still fetch them in SELECT clauses.






[DDC-3602] allow regex in filter option for convert-mapping cli Created: 05/Mar/15  Updated: 05/Mar/15

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

Type: New Feature Priority: Major
Reporter: Jochem Blok Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: cli, convert-mapping, filter


 Description   

It is possible to use the filter option to filter which table is converted. It uses as strpos function of php. Please enable the power of regular expressions.






[DDC-3601] @index where annotation not filled with convert-mapping cli Created: 05/Mar/15  Updated: 05/Mar/15

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

Type: Bug Priority: Major
Reporter: Jochem Blok Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: annotation, cli, convert-mapping, index, mssql, sqlserver
Environment:

Sql Server



 Description   

When you use the CLI tool "orm:convert-mapping --from-database xml" the generated XML file does not contain the optional WHERE for the indexes. It look like this is not implemented in de Doctrine\ORM\Tools\Export\Driver\XmlExporter






[DDC-3600] Implement include columns annotation for indexes Created: 05/Mar/15  Updated: 05/Mar/15

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

Type: Bug Priority: Major
Reporter: Jochem Blok Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: annotation, index, mssql, sqlserver
Environment:

Sql Server



 Description   

Sql server has an option to include columns in an index. There is no (optional) annotation for this functionality. http://doctrine-orm.readthedocs.org/en/latest/reference/annotations-reference.html#annref-index



 Comments   
Comment by Marco Pivetta [ 05/Mar/15 ]

Why would you need this sort of feature, when an index already defines the included columns?

Comment by Jochem Blok [ 05/Mar/15 ]

the advantages are described on the MSDN website:

By including nonkey columns, you can create nonclustered indexes that cover more queries. This is because the nonkey columns have the following benefits:
They can be data types not allowed as index key columns.
They are not considered by the Database Engine when calculating the number of index key columns or index key size.





[DDC-3598] Paginator incorrect ordering Created: 03/Mar/15  Updated: 03/Mar/15

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

Type: Bug Priority: Major
Reporter: Kris Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: paginator


 Description   

When ordering by multiple fields, with the order by fields not contained in the original select statement the paginator outputs in an incorrect order.
I found the issue is in the LimitSubqueryOutputWalker in the preserveSqlOrdering function. This is the query it generates

SELECT DISTINCT id1, date_added3 FROM (SELECT t0_.description AS description0, t0_.id AS id1, t0_.date AS date2, t0_.date_added AS date_added3 FROM Ticket t0_ INNER JOIN user u1_ ON t0_.assigned_user_id = u1_.id INNER JOIN user u2_ ON t0_.created_user_id = u2_.id WHERE t0_.project_id = ? ORDER BY u2_.first_name DESC, t0_.date_added DESC) dctrn_result ORDER BY date_added3 DESC

So it appears that it ignores any order by field that is not included in the inner select statement.






[DDC-3596] Do not allow entity column name "decimal" or escape somehow Created: 02/Mar/15  Updated: 02/Mar/15

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

Type: Bug Priority: Major
Reporter: Aurimas Niekis Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Problem is that after creation and schema update of entity with property "decimal" it makes problem to insert and alter that column.

On schema update it uses this SQL to create table:

CREATE TABLE Unit (id INT AUTO_INCREMENT NOT NULL, name VARCHAR(255) NOT NULL, unit VARCHAR(255) NOT NULL, `decimal` SMALLINT NOT NULL, decimal_point VARCHAR(1) NOT NULL, thousands_separator VARCHAR(1) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

When trying to persist entity I get exception

  [Doctrine\DBAL\DBALException]
  An exception occurred while executing 'INSERT INTO Unit (name, unit, decimal, decimal_point, thousands_separator) VALUES (?, ?, ?, ?, ?)' with params ["Cubic meters", "m\u00b3", "2", ".", ","]:
  SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'deci
  mal, decimal_point, thousands_separator) VALUES ('Cubic meters', 'm³', '2',' at line 1

Or alter table to rename column

  [Doctrine\DBAL\DBALException]
  An exception occurred while executing 'ALTER TABLE Unit CHANGE decimal decimal_numbers SMALLINT NOT NULL':
  SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'deci
  mal decimal_numbers SMALLINT NOT NULL' at line 1





[DDC-3593] INDEX BY doesnt't work for NEW ArticleDTO Created: 01/Mar/15  Updated: 01/Mar/15

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

Type: Bug Priority: Major
Reporter: Ondřej Vodáček Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

With this query the resulting array is not indexed by id, but from zero

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
$query = $em->createQuery('SELECT NEW ArticleDTO(a.id, a.title) FROM Article a INDEX BY a.id');
$articles = $query->getResult();





[DDC-3592] [GH-1318] Respect the "unique" property of the join column on the owning side of a... Created: 27/Feb/15  Updated: 16/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-1666 orphanRemoval does not work with oneT... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of ed-at-work:

Url: https://github.com/doctrine/doctrine2/pull/1318

Message:

... One to One association. Coupled with Orphan Removal on the mapped side, this should provide better compatibility for replacing the row without getting duplicate key errors.



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1318] was labeled:
https://github.com/doctrine/doctrine2/pull/1318

Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1318] was labeled:
https://github.com/doctrine/doctrine2/pull/1318





[DDC-3584] [GH-1310] Allow symfony 3.0 components Created: 22/Feb/15  Updated: 16/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of nicolas-grekas:

Url: https://github.com/doctrine/doctrine2/pull/1310

Message:

Tests should tell if any deprecated interfaces of Symfony are used. If not, then the bundle is defacto compatible with 3.0



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1310] was labeled:
https://github.com/doctrine/doctrine2/pull/1310





[DDC-3583] [GH-1309] [DDC-3582] Fix hydration of nested embeddables Created: 22/Feb/15  Updated: 27/Feb/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jankramer:

Url: https://github.com/doctrine/doctrine2/pull/1309

Message:

The wrong class is chosen when hydrating embeddables that are part of a nested structure. See `DDC3582Test` for a demonstration. The fix is to use `class` instead of `embeddedClass` to instantiate the embeddable in ReflectionEmbeddedProperty.

The test I removed from ReflectionEmbeddedPropertyTest was failing because you cannot instantiate an abstract class (and rightfully so). However, as this would not be possible in practice anyway (you always end up extending the abstract class), I think this test can be removed safely.



 Comments   
Comment by Doctrine Bot [ 22/Feb/15 ]

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

Comment by Doctrine Bot [ 27/Feb/15 ]

A related Github Pull-Request [GH-1311] was assigned:
https://github.com/doctrine/doctrine2/pull/1311

Comment by Doctrine Bot [ 27/Feb/15 ]

A related Github Pull-Request [GH-1311] was merged:
https://github.com/doctrine/doctrine2/pull/1311





[DDC-3582] Nested embeddables are instantiated with the wrong class Created: 22/Feb/15  Updated: 27/Feb/15

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

Type: Bug Priority: Major
Reporter: Jan Kramer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Consider the example where an entity contains an embeddable, that itself contains 2 different embeddables. So Entity -> Embeddable 1 -> (Embeddable 2, Embeddable 3). In this case, Embeddable1 will be instantiated as an Embeddable2 for some reason.

Please see https://github.com/jankramer/doctrine2/commit/5e6b02a0fa9a1216b4e4d075061619288af74e7a for a test that demonstrates this and currently fails.

I looked at the code in the ReflectionEmbeddedProperty, and noticed that 'embeddedClass' was recently changed from 'class'. If I change it back, this test passes, but then the ReflectionEmbeddedPropertyTest fails on the scenario for abstract classes. @ocramius, I saw you were the author on that change, could you please take a look? Thanks!



 Comments   
Comment by Jan Kramer [ 22/Feb/15 ]

Closing this as I can't seem to reproduce this issue anymore.

Comment by Jan Kramer [ 24/Feb/15 ]

Now able to reproduce this issue, updated the description.

Comment by Marco Pivetta [ 24/Feb/15 ]

Jan Kramer please send a PR with that diff

Comment by Jan Kramer [ 24/Feb/15 ]

@ocramius See https://github.com/doctrine/doctrine2/pull/1311

Comment by Doctrine Bot [ 27/Feb/15 ]

A related Github Pull-Request [GH-1311] was assigned:
https://github.com/doctrine/doctrine2/pull/1311

Comment by Doctrine Bot [ 27/Feb/15 ]

A related Github Pull-Request [GH-1311] was merged:
https://github.com/doctrine/doctrine2/pull/1311





[DDC-3580] [GH-1308] [DDC-3579] Allow override of inversedBy Created: 20/Feb/15  Updated: 16/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of z38:

Url: https://github.com/doctrine/doctrine2/pull/1308

Message:



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1308] was labeled:
https://github.com/doctrine/doctrine2/pull/1308

Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1308] was labeled:
https://github.com/doctrine/doctrine2/pull/1308





[DDC-3578] [GH-1307] Test for DDC-2988 Created: 20/Feb/15  Updated: 16/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-2988 Notice: Undefined index: joinColumns ... Awaiting Feedback

 Description   

This issue is created automatically through a Github pull request on behalf of aivus:

Url: https://github.com/doctrine/doctrine2/pull/1307

Message:

This test can be merged only after fix issue DDC-2988

http://www.doctrine-project.org/jira/browse/DDC-2988



 Comments   
Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1307] was labeled:
https://github.com/doctrine/doctrine2/pull/1307





[DDC-3577] Inherited associations are ignored Created: 20/Feb/15  Updated: 20/Feb/15

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

Type: Bug Priority: Major
Reporter: Denis Vasilev Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: schematool


 Description   

Could not create schema via SchemaTool for entity, which has inherited accosiation mapping (this mapping is ignored).

ShemaTool.php
private function gatherRelationsSql($class, $table, $schema, &$addedFks, &$blacklistedFks)
{
    foreach ($class->associationMappings as $mapping) {
        if (isset($mapping['inherited'])) {
            continue;
        }
...

I have three entity types:

  • BaseType — mapping mapped-superclass, has association many-to-one, join-column pid
  • SecondType extends BaseType — mapping entity
  • ThirdType extends SecondType — mapping entity

Table for ThirdType not has pid column after created scheme via SchemeTool. Inheritance mapping not using.



 Comments   
Comment by Marco Pivetta [ 20/Feb/15 ]

This should actually be working: you probably need to provide a test case otherwise

Comment by Denis Vasilev [ 20/Feb/15 ]

https://github.com/yethee/doctrine2/commit/d55a8bc71381db1c599da682c4baca0ce39d0d62
Test case for this issue.

$ phpunit --group=DDC-3577
PHPUnit 4.7-g7c1de6a by Sebastian Bergmann and contributors.

Configuration read from D:\Projects\doctrine2\phpunit.xml.dist

F

Time: 1.97 seconds, Memory: 81.75Mb

There was 1 failure:

1) Doctrine\Tests\ORM\Tools\SchemaToolTest::testInheritedAssociationShouldBeSupported
Table "ddc3577_interviews" should has column "user_id".
Failed asserting that false is true.




[DDC-3575] Paginator's CountOutputWalker keeps the ORDER BY in the subquery for all non-MSSQL platforms Created: 20/Feb/15  Updated: 20/Feb/15

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

Type: Bug Priority: Major
Reporter: John Flatness Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: paginator

Issue Links:
Reference
relates to DDC-3519 [GH-1267] Failing test for an ORDER B... Resolved
relates to DDC-3538 [GH-1283] #1267 - order by broken in ... Resolved

 Description   

The Paginator's CountOutputWalker leaves the ORDER BY clause in the subquery that's executed to get the total count.

The original (and current) version of that code included the following comment:

Note that the ORDER BY clause is not removed. Many SQL implementations (e.g. MySQL) are able to cache subqueries. By keeping the ORDER BY clause intact, the limitSubQuery that will most likely be executed next can be read from the native SQL cache.

My understanding is that MySQL does not, in fact, cache subqueries in the query cache, so cached results are not available between executions of different queries. The current MySQL manual still states that "Queries that are a subquery of an outer query" are not cached.

This pull request was merged in 2013 to address errors with mssql and paginating ordered queries. Midway through the discussion on that issue, it was determined that it would be better to just remove the ORDER BY clause for all platforms, not just MS SQL. However, that decision was reversed when it came time to merge the PR.

Does the comment on that method accurately describe the rationale for retaining the ORDER BY clause for the count query? If so, am I simply wrong about how MySQL operates, or does the comment refer to some other platform that benefits from this pattern?



 Comments   
Comment by Marco Pivetta [ 20/Feb/15 ]

See https://github.com/doctrine/doctrine2/pull/1283

This change was reverted because MSSQL is pretty much a niche, and fixing bugs for it is really making things complicated for all the other storages.

Comment by John Flatness [ 20/Feb/15 ]

Thanks for the reply, Marco.

I think this is getting conflated with the other Paginator-related ORDER BY changes and reversions that have happened breaking and fixing the actual sorting behavior. The pull you linked looks like its relating to the LimitSubqueryOutputWalker, not the CountOutputWalker.

The thing I'm talking about is still there, and does specifically address only a MSSQL bug: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Tools/Pagination/CountOutputWalker.php#L82

The particular part of the discussion on PR #572 I was referring to above is here: https://github.com/doctrine/doctrine2/pull/572#discussion_r3154962

My concern is that the rationale for keeping the ORDER BY intact for all the other platforms (only when running the count query, not the "real" one) is a performance-related one, and that it's a flawed rationale. (Or, at least, that the comment about it is.)





[DDC-3573] DateTime objects casted to string when used in aggregate functions in query results Created: 18/Feb/15  Updated: 18/Feb/15

Status: Open
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: Ameer Antar Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, mysql, orm, querybuilder
Environment:

MySQL, possibly others



 Description   

Similar to DDC-657: http://www.doctrine-project.org/jira/browse/DDC-657

DateTime objects are converted to strings when selecting them through an aggregate function.

Example:

Update.php Column definition
    /**
     * @var \DateTime
     * @ORM\Column(name="entryDate", type="datetime")
     */
    private $entryDate;
Query Builder
		$qb = $this->getEntityManager()->createQueryBuilder();
		$qb->select('u.code, max(u.entryDate) as updateDate');
		$qb->from('Update', 'u');
		$qb->addGroupBy('u.code');

		var_dump( $qb->getQuery()->getResult() );

The result contains the date/times as strings not DateTime objects as expected. This affects the query builder. I assume it also affects DQL queries.






[DDC-3563] Wrong metadata output. One-To-Many, Bidirectional Created: 08/Feb/15  Updated: 08/Feb/15

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

Type: Bug Priority: Major
Reporter: Jason Schilling Assignee: Steve Müller
Resolution: Unresolved Votes: 1
Labels: None

Attachments: Zip Archive Data.zip    

 Description   

During observe the metadata in a One-To-Many association I've noticed that, the inversedBy value is NULL but in the annotation its assigned to something like $images (look example). I think its wrong because the EntityGenerator dont get it and dont generate the add..., remove... and get...s Method stubs or the __constructor assignment to ArrayCollections.






[DDC-3562]  Make two different join request with different join condition with Doctrine ORM Created: 06/Feb/15  Updated: 06/Feb/15

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

Type: Bug Priority: Major
Reporter: Colin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Doctrine2 symfony integration
PHP 5.5.2
MySQL 5.5.41
Linux
doctrine/annotations v1.2.3
doctrine/cache v1.4.0
doctrine/collections v1.2
doctrine/common v2.4.2
doctrine/dbal v2.5.1
doctrine/doctrine-bundle v1.3.0
doctrine/doctrine-cache-bundle v1.0.1
doctrine/inflector v1.0.1
doctrine/lexer v1.0.1
doctrine/orm v2.4.7



 Description   

I want to make two requests on an object and join a one to many relation using doctrine ORM. The first request has different condition on the joined object.
The first request should join one object, and the second one two, but both return one object when run with the same EntityManager context.

The test entity

    /**
     * TreeNode
     *
     * @ORM\Table(name="treeNode")
     */
    class TreeNode {
    	/**
    	* @var integer
    	*
    	* @ORM\Id
    	* @ORM\Column(name="id", type="integer")
    	* @ORM\GeneratedValue(strategy="AUTO")
    	*/
    	private $id;
    
    	/**
    	* @var string
    	*
    	* @ORM\Column(name="name", type="string", length=50)
    	*/
    	private $name;
    
    	/**
    	* @var \Doctrine\Common\Collections\Collection
    	*
    	* @ORM\JoinColumn(name="subdirs", nullable=true)
    	* @ORM\OneToMany(targetEntity="TestBundle\Entity\TreeNode", mappedBy="parent", cascade={"persist"})
    	*/
    	private $subdirs;
    
    	/**
    	* @var TestBundle\Entity\TreeNode
    	*
    	* @ORM\JoinColumn(name="parent", nullable=true)
    	* @ORM\ManyToOne(targetEntity="TestBundle\Entity\TreeNode", inversedBy="subdirs")
    	*/
    	private $parent;
    }

Adding some test data

    $parent = new TreeNode();
    $parent->setName('Parent');
    $parent->setParent(null);
    
    $child1 = new TreeNode();
    $child1->setName('Child1');
    $child1->setParent($parent);
    
    $child2 = new TreeNode();
    $child2->setName('Child2');
    $child2->setParent($parent);

Run the queries

    $repo = $em->getRepository('TestBundle:TreeNode');

    $qb = $repo->createQueryBuilder('t');
    $qb->innerJoin('t.subdirs', 'subnode')
    		->addSelect('subnode')
    		->where('t.name = :parentName')
    		->setParameter('childName', 'Child1')
    		->andWhere('subnode.name = :childName')
    		->setParameter('parentName', 'Parent');
    
    $result = $qb->getQuery()->getOneOrNullResult();
    var_dump($result->getSubdirs()->count()); // Gives 1, ok 
    
    
    // Get parent parent + all childs
    $qb = $repo->createQueryBuilder('t');
    $qb->innerJoin('t.subdirs', 'subnode')
    		->addSelect('subnode')
    		->where('t.name = :parentName')
    		->setParameter('parentName', 'Parent');
    $result = $qb->getQuery()->getOneOrNullResult();
    var_dump($result->getSubdirs()->count()); // Gives 1, should have been 2 !
  • The second request only returns one "subdir" object, while it should have been two.
  • If I run the second request without the first one, I get the two results, as expected. Inverting the request makes the second one return two results instead of one.
  • The correct SQL requests are run by this code, only the returned result is wrong.
  • Running `$em->clear()` between the two statements works, but I don't want to untrack my other entities.





[DDC-3561] Wrong SQL generated for Drop Foreign Key on MySQL Created: 06/Feb/15  Updated: 20/Mar/15

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

Type: Bug Priority: Major
Reporter: Stefan Gnann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

operating system: osx yosemite
database driver: pdo_mysql
installed bundles:
doctrine/annotations v1.2.3
doctrine/cache v1.4.0
doctrine/collections v1.2
doctrine/common v2.4.2
doctrine/data-fixtures dev-master ac36ccc
doctrine/dbal v2.5.1
doctrine/doctrine-bundle v1.3.0
doctrine/doctrine-cache-bundle v1.0.1
doctrine/doctrine-fixtures-bundle v2.2.0
doctrine/doctrine-migrations-bundle dev-master 81575a4
doctrine/inflector v1.0.1
doctrine/instantiator 1.0.4
doctrine/lexer v1.0.1
doctrine/migrations dev-master 96f838b
doctrine/mongodb 1.1.6
doctrine/mongodb-odm dev-master 23152aa
doctrine/mongodb-odm-bundle dev-master 9748d11
doctrine/orm v2.4.7
gedmo/doctrine-extensions v2.3.9
stof/doctrine-extensions-bundle v1.1.0


Attachments: File migrate-example.php    

 Description   

i´m new to doctrine, but it seems to me that there is a problem creating statements in migrations.
Please see the //comments in the attached file!



 Comments   
Comment by Marco Pivetta [ 06/Feb/15 ]

Steve Müller I think I saw this issue already in the DBAL tracker somewhere, but I can't find it. Do you remember the issue ID?

Comment by Stefan Gnann [ 06/Feb/15 ]

The attached file was automatically generated after upgrading doctrine/dbal onto version 2.5.1 .

Now i have DOWNgraded doctrine/dbal to version 2.4.4 .
Suddenly the doctrine:migrations:diff says "No changes detected in your mapping information.".

Before downgrading i had two identical databases. One locally installed and one in a vagrant box with debian as os.
On every database i did a "doctrine:migrations:diff" to generate an actual schema update file. What i was wondering ist, that i got two different files with different ALTER xxxxx statements regarding to FOREIGN KEY and INDEXES.

Maybe this is a bug in doctrine/dbal 2.5.1?

Comment by Stefan Gnann [ 06/Feb/15 ]

actual installed bundles after downgrading:

doctrine/annotations v1.2.3
doctrine/cache v1.4.0
doctrine/collections v1.2
doctrine/common v2.4.2
doctrine/data-fixtures dev-master 80401e8
doctrine/dbal v2.4.4
doctrine/doctrine-bundle v1.3.0
doctrine/doctrine-cache-bundle v1.0.1
doctrine/doctrine-fixtures-bundle v2.2.0
doctrine/doctrine-migrations-bundle dev-master 81575a4
doctrine/inflector v1.0.1
doctrine/instantiator 1.0.4
doctrine/lexer v1.0.1
doctrine/migrations dev-master 1ac14fa
doctrine/mongodb 1.1.7
doctrine/mongodb-odm dev-master 1343375
doctrine/mongodb-odm-bundle dev-master 27e7690
doctrine/orm v2.4.7
gedmo/doctrine-extensions v2.3.11
stof/doctrine-extensions-bundle v1.1.0

Comment by Peter Rehm [ 18/Feb/15 ]

Steve Müller I did some research on that the last days and I am sure, there is still a major issue with the implementation.

The schema update creates the following sql commands:

$this->addSql('ALTER TABLE Article DROP FOREIGN KEY FK_12743CF7924C3225');
$this->addSql('ALTER TABLE Article DROP FOREIGN KEY FK_12743CF79395C3F3');
$this->addSql('ALTER TABLE Article DROP FOREIGN KEY FK_12743CF7F7C5BCDB');
$this->addSql('ALTER TABLE Article DROP FOREIGN KEY FK_93173F21A23B42D');
$this->addSql('ALTER TABLE Article DROP FOREIGN KEY FK_93173F21A5790FE9');
$this->addSql('ALTER TABLE Article ADD CONSTRAINT FK_12743CF7924C3225 FOREIGN KEY (createdUser_id) REFERENCES CoreUser (id)');

Looking at the previous SQL schema I found out that there is already e.g. the FK_12743CF7924C3225. This FK
will be dropped and newly added at the same time. It is actually not using the new FK name which doctrine would
like to see. However in the down sql it tried to drop the key which should be there.

In addition to that there is an issue with upper/lowercase Index names. This I got fixed by

return 'DROP INDEX ' . strtoupper($indexName) . ' ON ' . $table;

in MysqlPlatform:860 which is most likely not the right way. I am more concerned about the FK
issue, which I am unable to track down so far. Do you have any idea?

Comment by Peter Rehm [ 20/Mar/15 ]

@deeky666 Have you had a chance to look at this?





[DDC-3558] Sequence name generation for identity strategy Created: 04/Feb/15  Updated: 05/Feb/15

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

Type: Bug Priority: Major
Reporter: Gemorroj Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: generator-strategy, identity, metadata, sequence

Attachments: PNG File Захват-1.png    

 Description   

In version 2.5 added support sequence with the strategy of identity.
But I cannot get the correct name of the sequence with the strategy of identity. With the strategy sequence produces the correct name. It is taken from the configuration sequenceName. Strategy identity name sequence will not be taken from the configuration, and is always generated is automatically (which is not working properly in my case).

see: https://github.com/doctrine/doctrine2/blob/4c68a38bd6b7d590dbfa90b2bb116129381935ce/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L632
the title sequence is generated automatically.

https://github.com/doctrine/doctrine2/blob/4c68a38bd6b7d590dbfa90b2bb116129381935ce/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L662
and in this case, it first checks its own configuration.



 Comments   
Comment by Gemorroj [ 05/Feb/15 ]

Any comments plz..?

Comment by Marco Pivetta [ 05/Feb/15 ]

Gemorroj consider writing a test case with your problem/example: I can't understand the issue as it is currently written down.

A code example is also fine.

Comment by Gemorroj [ 05/Feb/15 ]

If you use the strategy SEQUENCE, the doctrine calls the sequence specified in the configuration. And inserts a record in the database with the specified ID.
If you are using the IDENTITY strategy, doctrine inserts a record without an ID. And after a record is inserted, causes sequence (https://github.com/doctrine/dbal/blob/8cbfefe03ff2d1a2246dfb6e98b84e4b36622e6f/lib/Doctrine/DBAL/Driver/OCI8/OCI8Connection.php#L148) to learn the value of id.
But, with the IDENTITY strategy, doctrine does not know how actually called a sequence.

Comment by Marco Pivetta [ 05/Feb/15 ]

Yes, when using the IDENTITY strategy, the sequence name is not used: https://github.com/doctrine/doctrine2/blob/4c68a38bd6b7d590dbfa90b2bb116129381935ce/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L626-L657

That's expected behavior: what are you expecting?

Comment by Gemorroj [ 05/Feb/15 ]

If doctrine determines that the database uses the sequence, then I expect the setup sequence doctrine is taken from the configuration.
https://github.com/doctrine/doctrine2/blob/4c68a38bd6b7d590dbfa90b2bb116129381935ce/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L636-L638
The generated name sequence wrong for me.

Comment by Marco Pivetta [ 05/Feb/15 ]

You should rather just use the SEQUENCE strategy.

Otherwise, provide a functional test case and eventually propose a fix.





[DDC-3552] Code generation throws exceptions when embeddables are used Created: 30/Jan/15  Updated: 30/Jan/15

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

Type: Bug Priority: Major
Reporter: Vladislav Veselinov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I've created a gist showing the code you can use to reproduce the issue
https://gist.github.com/v3labs/d02244c99a87444be709

I've also included the composer.json file.

When I run php app/console doctrine:generate:entities AppBundle -v, I get the following exception:

[Symfony\Component\Debug\Exception\ContextErrorException]
Notice: Trying to get property of non-object

Exception trace:
() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:3251
Symfony\Component\Debug\ErrorHandler->handleError() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:3251
Doctrine\ORM\Mapping\ClassMetadataInfo->inlineEmbeddable() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:201
Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:332
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:78
Doctrine\ORM\Mapping\ClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:225
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:115
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:201
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:164
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getMetadataForNamespace() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:54
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getBundleMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Command/GenerateEntitiesDoctrineCommand.php:96
Doctrine\Bundle\DoctrineBundle\Command\GenerateEntitiesDoctrineCommand->execute() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:253
Symfony\Component\Console\Command\Command->run() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:882
Symfony\Component\Console\Application->doRunCommand() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:195
Symfony\Component\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:96
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:126
Symfony\Component\Console\Application->run() at /Users/vladislav/Sites/doctrine2.5_tests/app/console:27

If I add columnPreffix to the @Embed annotation the exception is different:

[Symfony\Component\Debug\Exception\ContextErrorException]
Catchable Fatal Error: Argument 1 passed to Doctrine\ORM\Mapping\ReflectionEmbeddedProperty::__construct() must be an instance of ReflectionP
roperty, null given, called in /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php on
line 952 and defined

Exception trace:
() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ReflectionEmbeddedProperty.php:61
Symfony\Component\Debug\ErrorHandler->handleError() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ReflectionEmbeddedProperty.php:61
Doctrine\ORM\Mapping\ReflectionEmbeddedProperty->__construct() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:952
Doctrine\ORM\Mapping\ClassMetadataInfo->wakeupReflection() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:721
Doctrine\ORM\Mapping\ClassMetadataFactory->wakeupReflection() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:343
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:78
Doctrine\ORM\Mapping\ClassMetadataFactory->loadMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:225
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:115
Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:201
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getAllMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:164
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getMetadataForNamespace() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Mapping/DisconnectedMetadataFactory.php:54
Doctrine\Bundle\DoctrineBundle\Mapping\DisconnectedMetadataFactory->getBundleMetadata() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/doctrine/doctrine-bundle/Command/GenerateEntitiesDoctrineCommand.php:96
Doctrine\Bundle\DoctrineBundle\Command\GenerateEntitiesDoctrineCommand->execute() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:253
Symfony\Component\Console\Command\Command->run() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:882
Symfony\Component\Console\Application->doRunCommand() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:195
Symfony\Component\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:96
Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /Users/vladislav/Sites/doctrine2.5_tests/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:126
Symfony\Component\Console\Application->run() at /Users/vladislav/Sites/doctrine2.5_tests/app/console:27

doctrine:generate:entities [--path="..."] [--no-backup] name

I don't think it's a Symfony specific issue. I tried using the built-in CLI tool and got the same results.



 Comments   
Comment by Marco Pivetta [ 30/Jan/15 ]

Yeah, this can't really work with code-gen, because embeddables require reflection to be initialized in order to operate, whereas the codegen cli-tools operate with a DisconnectedMetadataFactory, which skips reflection on purpose (it assumes that the class does not exist, therefore it does not start up reflection).

I think it's a can't fix for now.

Comment by Vladislav Veselinov [ 30/Jan/15 ]

Sorry for the formatting. I had never used jira before.

Comment by Marco Pivetta [ 30/Jan/15 ]

Vladislav Veselinov fixed the formatting, no big deal

Comment by Vladislav Veselinov [ 30/Jan/15 ]

Btw:

Changing line 947 in ClassMetadataInfo to:

if (isset($mapping['declaredField']) && $parentReflFields[$mapping['declaredField']]) {

seems to bypass the problem and the generation runs fine, but I don't know if it breaks something else. Doesn't seem like it but ... I'm not sure

Comment by Vladislav Veselinov [ 30/Jan/15 ]

Just figured out with it won't work in all cases. I'll keep digging. Thanks for the feedback!





[DDC-3550] [GH-1293] EntityManager::__cosntruct() as public method Created: 28/Jan/15  Updated: 16/Feb/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of mcspronko:

Url: https://github.com/doctrine/doctrine2/pull/1293

Message:



 Comments   
Comment by Doctrine Bot [ 16/Feb/15 ]

A related Github Pull-Request [GH-1293] was labeled:
https://github.com/doctrine/doctrine2/pull/1293





[DDC-3548] [GH-1291] Conversion to PHP 5.4's short array syntax Created: 28/Jan/15  Updated: 28/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of BenMorel:

Url: https://github.com/doctrine/doctrine2/pull/1291

Message:

Now that the minimum PHP version is 5.4, it would be good to encourage the use of the short array syntax `[]`.
Converting the existing codebase to this syntax will promote this good practice and encourage everyone to follow it.

I have converted the codebase with [a tool](https://gist.github.com/BenMorel/6994483) I wrote for personal projects:

find doctrine2 -type f -name '*.php' -exec php short-array-syntax-converter.php {} \;

The number of changes is quite large, but I'm confident that nothing is broken, and the passing tests confirm this.



 Comments   
Comment by Doctrine Bot [ 28/Jan/15 ]

A related Github Pull-Request [GH-1291] was assigned:
https://github.com/doctrine/doctrine2/pull/1291

Comment by Doctrine Bot [ 28/Jan/15 ]

A related Github Pull-Request [GH-1291] was labeled:
https://github.com/doctrine/doctrine2/pull/1291





[DDC-3545] Persist new object failed when it works with optimistic lock Created: 27/Jan/15  Updated: 27/Jan/15

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

Type: Bug Priority: Major
Reporter: Max Liu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, orm
Environment:

PHP 5.5



 Description   

When I was trying to persist a new object, Doctrine reported a exception:

An exception occurred while executing 'SELECT version FROM wallet WHERE user_id = ?' with params [{}]:

Catchable Fatal Error: Object of class XXXBundle\Entity\User could not be converted to string in /Users/XXX/WebSite/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php line 91

From the stack trace information, I found the original exception is:

Catchable Fatal Error: Object of class XXXBundle\Entity\User could not be converted to string

The reason is that the entity Wallet has a OneToOne mapping to entity User, and user property is also marked as primary key. When the wallet object persists, Doctrine try to fetch the new version id and use user property to find object. But Doctrine doesn't handle the primary key is an object, not a basic type. So PDO can't use a object as a query parameter.

My Entity:

class Wallet
{
    /**
     * ID
     * @var User
     *
     * @ORM\Id
     * @ORM\OneToOne(targetEntity="XXXBundle\Entity\User")
     * @ORM\JoinColumn(name="user_id", referencedColumnName="id")
     */
    private $user;

    /**
     * @var int
     *
     * @ORM\Version()
     * @ORM\Column(name="version", type="integer")
     */
    private $version;
}

I hope Doctrine team can solve this problem. My temporary solution is to override __toString method in User object. It is not elegant, doesn't it?



 Comments   
Comment by Marco Pivetta [ 27/Jan/15 ]

What exact version of the ORM is affected? Is master also behaving like this?

Comment by Max Liu [ 27/Jan/15 ]

It works well before I add version field. I didn't try with master version.





[DDC-3539] [GH-1284] #1189 DDC-3406 derived identity in proxy must be a proxy Created: 24/Jan/15  Updated: 16/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Dependency
is required for DDC-3406 Proxy returns string instead of object Open

 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/doctrine2/pull/1284

Message:

This is a horrible hack for #1189.

Not happy with it, this seems like it fixes just the symptom.



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1284] was assigned:
https://github.com/doctrine/doctrine2/pull/1284

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1284] was labeled:
https://github.com/doctrine/doctrine2/pull/1284

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1189] was labeled:
https://github.com/doctrine/doctrine2/pull/1189

Comment by Doctrine Bot [ 25/Jan/15 ]

A related Github Pull-Request [GH-1284] was unlabeled:
https://github.com/doctrine/doctrine2/pull/1284

Comment by Doctrine Bot [ 25/Jan/15 ]

A related Github Pull-Request [GH-1284] was labeled:
https://github.com/doctrine/doctrine2/pull/1284

Comment by Doctrine Bot [ 16/Mar/15 ]

A related Github Pull-Request [GH-1284] was unlabeled:
https://github.com/doctrine/doctrine2/pull/1284





[DDC-3525] Exception "The column id must be mapped to a field in class" when associationKey used Created: 20/Jan/15  Updated: 21/Jan/15

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

Type: Bug Priority: Major
Reporter: Ilya Antipenko Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: associationKey, foreign-key

Attachments: Text File foreign-key.log    

 Description   

I have issue when I use "associationKey"

I create test repo for reproduce this issue:
https://github.com/aivus/symfony2-foreign-bug

1. composer install
2. Set DB parameters in app/config/parameters.yml and create DB
3. php app/console doctrine:schema:create --force
4. php app/console server:run
5. Load fixtures: http://127.0.0.1:8000/app/loadFixture
6. Try to get list: http://127.0.0.1:8000/app_dev.php/admin/app/app/order/list

I make workaround, which works for me (https://github.com/aivus/doctrine2/commit/8461111e8aea98d02175f3642870a689d446beef), but I'm not sure about it



 Comments   
Comment by Ilya Antipenko [ 21/Jan/15 ]

Add stacktrace





[DDC-3515] [GH-1263] #1223 DDC-3453 - make `EntityManager` constructor `public` Created: 18/Jan/15  Updated: 25/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: constructor, entitymanager, setup

Issue Links:
Reference
is referenced by DDC-3453 [GH-1223] Refactored construction of ... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/doctrine2/pull/1263

Message:



 Comments   
Comment by Doctrine Bot [ 18/Jan/15 ]

A related Github Pull-Request [GH-1263] was assigned:
https://github.com/doctrine/doctrine2/pull/1263

Comment by Doctrine Bot [ 18/Jan/15 ]

A related Github Pull-Request [GH-1263] was assigned:
https://github.com/doctrine/doctrine2/pull/1263

Comment by Doctrine Bot [ 18/Jan/15 ]

A related Github Pull-Request [GH-1263] was unassigned:
https://github.com/doctrine/doctrine2/pull/1263

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1263] was labeled:
https://github.com/doctrine/doctrine2/pull/1263





[DDC-3511] Temporarily change fetch mode in DQL for toMany relations Created: 16/Jan/15  Updated: 16/Jan/15

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

Type: New Feature Priority: Major
Reporter: Filip Procházka Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: dql, eager, fetch-mode, query


 Description   

This would be a major improvement. I can't seem to find the issue for this. Is this even planned?

http://docs.doctrine-project.org/en/latest/reference/dql-doctrine-query-language.html#temporarily-change-fetch-mode-in-dql

I might be able to find some time to work on this in February, if nobody else is going to.



 Comments   
Comment by Marco Pivetta [ 16/Jan/15 ]

You might want to wait for the persisters to stabilize with 2.5





[DDC-3510] [GH-1261] Add a new QuoteStrategy that automatically escape database reserved keyword Created: 16/Jan/15  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of xhuberty:

Url: https://github.com/doctrine/doctrine2/pull/1261

Message:

All the upload screenshots which are used to explain what we are doing are taken from a real project developed with Mouf dependency injection framework (http://mouf-php.com/) that we use to configure the entity manager.

We wanted to create a FAQ where admin can add question/answer and use drag and drop to set the position of the question in the FAQ.

For this, at some point, in an entity, we used a protected keyword "order" in a class FAQ:

```
/**

  • @ORM\Column(type="integer", nullable=false)
  • @var int
    */
    private $order;
    ```

This fails with Doctrine. The documentation clearly explains why: http://doctrine-orm.readthedocs.org/en/latest/reference/basic-mapping.html#quoting-reserved-words

Below are a list of screenshot explaining we use the `DefaultQuoteStrategy` and the failure message we get.

![doctrineconfiguration](https://cloud.githubusercontent.com/assets/8350192/5779969/4ab5c15e-9da7-11e4-8df8-f2c718c8d66a.PNG)

In the configuration,the "quoteStrategy" setter is not set. Therefore, we use `DefaultQuoteStrategy`.

![defaultquotestrategy](https://cloud.githubusercontent.com/assets/8350192/5779977/51fe0a70-9da7-11e4-9cfa-3a86e6f8aab8.PNG)

We get this error:

![error](https://cloud.githubusercontent.com/assets/8350192/5779963/422e0bc2-9da7-11e4-902c-602a2eac7f96.PNG)
We get an error while using doctrine ORM because it doesn't auto escape protected keyword. (We can protect it manually by using ` .)

We created a new QuoteStratigy that automaticcaly escape protected keyword *only*. We just bind it via the Mouf interface:

![escapingquotestrategy](https://cloud.githubusercontent.com/assets/8350192/5780067/d9997bae-9da7-11e4-8a23-c5fa2ebaffcc.PNG)

and then the magic begins: a screenshot of the page with no error.

![succes](https://cloud.githubusercontent.com/assets/8350192/5780085/f9b597f6-9da7-11e4-85b0-cd09fb572cd9.PNG)

We would like to submit this new `EscapingQuoteStrategy` as we think it will be easier for developers to work with it, and it should not have a big performance impact (only an additional lookup in a table)



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1261] was labeled:
https://github.com/doctrine/doctrine2/pull/1261

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1261] was labeled:
https://github.com/doctrine/doctrine2/pull/1261





[DDC-3507] [GH-1260] Added PersisterFactory to ORM. Created: 16/Jan/15  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of guilhermeblanco:

Url: https://github.com/doctrine/doctrine2/pull/1260

Message:



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1260] was labeled:
https://github.com/doctrine/doctrine2/pull/1260

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1260] was labeled:
https://github.com/doctrine/doctrine2/pull/1260





[DDC-3489] Sequence generators should be stateless Created: 13/Jan/15  Updated: 13/Jan/15

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

Type: Bug Priority: Major
Reporter: Marco Pivetta Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: metadata, sequence, sequence-generator, stateless

Issue Links:
Dependency
is required for DDC-2477 [GH-681] Sequence generator fix Resolved

 Description   

Current sequence generators keep internal state such as the metadata of the entity that uses the sequence.

The sequence generators should instead be stateless.






[DDC-3485] Using Embeddable in MappedSuperclass fails Created: 11/Jan/15  Updated: 11/Jan/15

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

Type: Bug Priority: Major
Reporter: Marco Pfeiffer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File EmbedInMappedSuperclass.php    

 Description   

While Trying to Embed an object into a mapped superclass an exception is thrown:

PHP Fatal error:  Uncaught exception 'Doctrine\ORM\Mapping\MappingException' with message 'Duplicate definition of column 'embed_someField' on entity 'Entity' in a field or discriminator column mapping.' in /home/dev/Workspace/symfony/perto/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php:555





[DDC-3481] [GH-1241] [3.0] [POC] lazy-load on a per-property base Created: 09/Jan/15  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Ocramius:

Url: https://github.com/doctrine/doctrine2/pull/1241

Message:

This is just a proof of concept that I hacked together real quick.

This changes how proxies are generated and lazy-loaded in a very radical way:

  • method calls do not cause lazy-loading
  • lazy-loading is triggered by access to non-transient properties (things that need to be lazy-loaded)
  • access to identifiers or non-mapped properties won't cause lazy-loading

Following BC breaks need to be fixed or discussed before going forward on this idea:

  • [ ] proxies don't implement `Doctrine\Common\Proxy\Proxy` anymore, but `ProxyManager\Proxy\GhostObjectInterface` (BC break, needs fixing, can be easily done with some effort)
  • [ ] `serialize($proxy)` now causes proxy initialization (probably needs fixing, as this is a major BC break)

Pending TODOs:

  • [ ] cloning a proxy is still not fully supported (requires dedicated logic in `__clone`)
  • [ ] this is just a PoC, so the code that writes proxies to disk is not yet in place


 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1241] was labeled:
https://github.com/doctrine/doctrine2/pull/1241

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1241] was labeled:
https://github.com/doctrine/doctrine2/pull/1241





[DDC-3480] ORM\Embeddable does not create ManyToOne column in the database Created: 09/Jan/15  Updated: 09/Feb/15

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

Type: Bug Priority: Major
Reporter: Tomas Voslar Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None

Issue Links:
Reference
relates to DDC-3556 [GH-1297] [DDC-3480] Docs: Embeddable... Resolved

 Description   

Following Embeddable

/**
 * @ORM\Embeddable
 */
class Address
{
    /**
     * @ORM\ManyToOne(targetEntity="Country")
     */
    protected $country;

won't save country attribute into the database table, other simple attributes (like type="text") saved normally.

    /**
     * @ORM\Embedded(class="LuciniLucini\Adsender\CommonBundle\Entity\Address")
     */
    private $address;


 Comments   
Comment by Marco Pivetta [ 09/Jan/15 ]

The issue seems incomplete to me: what exactly is the failure? Can you make an example?

Comment by Tomas Voslar [ 09/Jan/15 ]

Okay, I am sorry. I have main entity which includes Embeddable entity (Address), this address entity contains country attribute with ManyToOne relation, but this country is not being saved into the database table, other attributes like street (string) are being saved normally.

Comment by Tomas Voslar [ 09/Jan/15 ]

Basically it creates main entity with all fields from embeddable except country which is ManyToOne.

Comment by Marco Pivetta [ 09/Jan/15 ]

Ah, now I get it (I was probably misreading it). We don't support associations from embeddables right now: please check the test suite, but they really don't provide this functionality right now.

Comment by Tomas Voslar [ 09/Jan/15 ]

And is there any chance it will be supported in the near future? Or it's not possible?

Comment by Marco Pivetta [ 09/Jan/15 ]

It will probably not implemented for now, as embeddables (in our vision) are fitting the use-case of ValueObjects. ValueObjects are (usually) supposed to be containing serializable data, and an entity reference is not serializable data.

Comment by Tomas Voslar [ 09/Jan/15 ]

Okay, understood. So it's not good idea to use embeddables for Address entity for example, with this country as relation to another table, right? It seemed to me like best case. Thank you for the support anyway.

Comment by Marco Pivetta [ 09/Jan/15 ]

So it's not good idea to use embeddables for Address entity for example, with this country as relation to another table, right?

I'd rather just save the country identifier in the embeddable instead.

Comment by Tomas Voslar [ 09/Jan/15 ]

So you mean, instead of ManyToOne, save just id=integer (so no relation with entity)?

Comment by Marco Pivetta [ 09/Jan/15 ]

Correct: simple scalar or serializable types

Comment by Tomas Voslar [ 09/Jan/15 ]

https://github.com/doctrine/doctrine2/blob/400acad53355f24137e18d5cd55ccf6ff828cfbe/tests/Doctrine/Tests/ORM/Functional/ValueObjectsTest.php

Line 121 method testDqlOnEmbeddedObjectsField, guess I am wrong, but it seems there should be support for embeddable with relations though.

Comment by Yavin [ 11/Jan/15 ]

Hi,
if is is not supported i think an exception should be thrown when someone use association in embedded class. Now it is just silently ommited.

I found code where embedded metadata is added:
https://github.com/doctrine/doctrine2/blob/573153669c11a6f69201513831d3b8ce5e111d25/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php#L3200

Comment by Eugene Dounar [ 02/Feb/15 ]

It will probably not implemented for now, as embeddables (in our vision) are fitting the use-case of ValueObjects. ValueObjects are (usually) supposed to be containing serializable data, and an entity reference is not serializable data.

This should be explicitly stated in the documentation.

Comment by Marco Pivetta [ 02/Feb/15 ]

Eugene Dounar please send a PR to the documentation with the wording you prefer.

Comment by Eugene Dounar [ 09/Feb/15 ]

Marco Pivetta http://www.doctrine-project.org/jira/browse/DDC-3556





[DDC-3476] JoinTable options are not inherited Created: 06/Jan/15  Updated: 06/Jan/15

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

Type: Bug Priority: Major
Reporter: Enrico Schultz Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: join, joins, orm, table-options


 Description   

I'm working with Symfony 2.6 and Doctrine (MySQL), but the error is in the Doctrine 2 ORM.

I have specified a ManyToMany relation like so:

/**
 *@ORM\Table(name="users", options={"engine"="MyISAM", "collate"="utf8_general_ci"})
 * @ORM\Entity
 */
class User
{
  /**
    * @ORM\ManyToMany(targetEntity="Group", inversedBy="users")
    * @ORM\JoinTable(name="user_groups", joinColumns={@ORM\JoinColumn(name="user_id", referencedColumnName="id")}, inverseJoinColumns={@ORM\JoinColumn(name="group_id", referencedColumnName="id")})
  */
  private $groups;

...
}

All tables should be created as MyISAM and "utf8_general_ci" collation instead of InnoDB and "utf8_unicode_ci". This works fine for all tables except for "user_groups" table because the options are not inherited. As a result the schema is not valid, because foreign keys cannot be created over 2 different collations.

To fix this, I modified class "\Doctrine\ORM\Tools\SchemaTool", function "gatherRelationsSql($class, $table, $schema, &$addedFks, &$blacklistedFks)" and added the following lines in the MANY_TO_MANY block:

if (isset($foreignClass->table['options'])) {
  foreach ($foreignClass->table['options'] as $key => $val) {
    $theJoinTable->addOption($key, $val);
  }
}

Now, it works as I want. The new table is created with the right collation and engine and the foreign keys are created correct. Could you please implement this fix?



 Comments   
Comment by Enrico Schultz [ 06/Jan/15 ]

Please also have a look at DDC-972 where MyISAM support was added. The problem was already mentioned there in the last 4 comments, so it exists at least since 2012.





[DDC-3469] [GH-1234] added basic test for private embedded field in inheritence Created: 30/Dec/14  Updated: 30/Dec/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Nemo64:

Url: https://github.com/doctrine/doctrine2/pull/1234

Message:

The tried creating a test case for DDC-3467(http://www.doctrine-project.org/jira/browse/DDC-3467). I hope I put everything in the right place as my knowledge of this project is currently limited.






[DDC-3463] Generated enitities have singular variable names for many to many relationships Created: 25/Dec/14  Updated: 25/Dec/14

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

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


 Description   

Running doctrine:generate:entities from the command line gives entities that have instance variables arrays, but their names are singular. For example if there are many "tools" associated with a "toolbox" via a many to one or many to many realationship, the toolbox class should have an array variable named "tools". It has an array but the name of it is "tool" instead of "tools". The name of the variable should be singular for one to one relationships and plural for whenever its an array






[DDC-3460] SchemaTool create unnecessry work by trying to set foreign keys on MyISAM tables Created: 20/Dec/14  Updated: 16/Feb/15

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

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


 Description   

When I run SchemaTool::getSchemaFromMetadata, it always adds foreign keys constraints for all association fields (in SchemaTool::gatherRelationJoinColumns). Since I've set the table's engine option to 'MyISAM', this is quite pointless, since they won't get created anyways.

When I run SchemaManager::createSchema, it does not detect any foreign keys, so the SchemaDiff from Comparator will contain a large number of (pointless) ADD CONSTRAINT FK_xxx FOREIGN KEY commands.

For the moment, I work around this by removing them in a ToolEvents::postGenerateSchemaTable listener, but shouldn't SchemaTool be able to detect this situation itself?



 Comments   
Comment by flack [ 16/Feb/15 ]

This says "awaiting feedback" now. Is there any question that I can answer?

Comment by Marco Pivetta [ 16/Feb/15 ]

I think this is a "won't fix", as we don't consider MyISAM as supported.

The "awaiting feedback" flag was mainly because tests are missing.

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

I think we fixed that already in DBAL 2.5: https://github.com/doctrine/dbal/commit/e95afefab614ecb352791cf09fd5f831d7e5b3be





[DDC-3458] [GH-1228] Fixed many small phpcs issues Created: 19/Dec/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of acrobat:

Url: https://github.com/doctrine/doctrine2/pull/1228

Message:

This pr fixes many small phpcs issues



 Comments   
Comment by Doctrine Bot [ 19/Dec/14 ]

A related Github Pull-Request [GH-1228] was assigned:
https://github.com/doctrine/doctrine2/pull/1228

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1228] was labeled:
https://github.com/doctrine/doctrine2/pull/1228





[DDC-3455] [GH-1225] Test for RuntimeException in AnnotationExporter::exportClassMetadata() Created: 19/Dec/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of TorbenBr:

Url: https://github.com/doctrine/doctrine2/pull/1225

Message:



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1225] was labeled:
https://github.com/doctrine/doctrine2/pull/1225

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1225] was labeled:
https://github.com/doctrine/doctrine2/pull/1225





[DDC-3450] Embeddables containing only nested embeddables are not hydrated properly Created: 16/Dec/14  Updated: 16/Dec/14

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

Type: Bug Priority: Major
Reporter: James Moss Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have the following object mapping:

Location (entity)

  • name <string>
  • bounds <Bounds>

Bounds (embeddable)

  • northeast <Coords>
  • southwest <Coords>

Coords (embeddable)

  • latitude <float>
  • longitude <float>

This setup works fine when persisting entities, the database schema is correct, etc. but when I fetch my `Location` entity afterwards the `bounds` property is wrong. It looks something like this. Calling `getBounds()` on `Location` returns something like:

Coords

  • latitude <float>
  • longitude <float>
  • northeast <Coords>
  • southwest <Coords>

As if the `Coords` embeddable has been transposed with the `Bounds` embeddable.

If I add another property to `Bounds` that isn't an embeddable (say a string) then it's hydrated correctly.



 Comments   
Comment by Marco Pivetta [ 16/Dec/14 ]

James Moss could you come up with a small test case in https://github.com/doctrine/doctrine2/tree/v2.4.7/tests/Doctrine/Tests/ORM/Functional/Ticket ?





[DDC-3448] @OrderBy on eager @OneToMany does not work Created: 13/Dec/14  Updated: 13/Dec/14

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

Type: Bug Priority: Major
Reporter: Oliver Hoff Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

generated code when eagerly fetching:

SELECT 
  t0.id AS id_8,
  t19.category_id AS category_id_23 
FROM 
  category t0 
  LEFT JOIN attribute_category t19 ON t19.category_id = t0.id 
WHERE 
  t0.id = ?

when fetching lazy the collection query has the ORDER BY clause






[DDC-3446] [GH-1219] Comparison like/notlike support Created: 10/Dec/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Fedik:

Url: https://github.com/doctrine/doctrine2/pull/1219

Message:

Support `Comparison::LIKE` and `Comparison::NOTLIKE` additionally to doctrine/collections#50

as alternative for #1150



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1219] was labeled:
https://github.com/doctrine/doctrine2/pull/1219

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1219] was labeled:
https://github.com/doctrine/doctrine2/pull/1219





[DDC-3445] ERROR GENERATED VALUE (UUID) Created: 10/Dec/14  Updated: 11/Dec/14

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

Type: Bug Priority: Major
Reporter: MUHAMAD SURYA IKSANUDIN Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, postgresql


 Description   

UUID is not working (missing ID and need to set manually)

/**
 * @ORM\Entity
 * @ORM\Table(name = "utl_role")
 */
class Role implements EntityInterface
{
    /**
     * @ORM\Id
     * @ORM\Column(name = "id", type = "guid")
     * @ORM\GeneratedValue(strategy = "UUID")
     **/
    protected $id;

===============================

i need to pass the id manually

$role->setId((new UuidGenerator())->generate($this->em, $role)); 

because the id is not set and error when i try to persist.

This error is arrive when i try to persist an entity i loop

================================

I use postgresql 9.3



 Comments   
Comment by Marco Pivetta [ 11/Dec/14 ]

Can you check this also against master (2.5-dev)?

Comment by MUHAMAD SURYA IKSANUDIN [ 11/Dec/14 ]

i think it same because the uuid generator is same

https://github.com/doctrine/doctrine2/blob/master/lib%2FDoctrine%2FORM%2FId%2FUuidGenerator.php#L42

in that code, i see the uuid is generated from database provider/platform, i suggest to use code base generator like

https://github.com/ramsey/uuid/blob/master/src%2FUuid.php

it just my suggestion

thanks





[DDC-3444] [GH-1218] Failing test case for cascading refresh Created: 09/Dec/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of MartijnDwars:

Url: https://github.com/doctrine/doctrine2/pull/1218

Message:



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1218] was labeled:
https://github.com/doctrine/doctrine2/pull/1218





[DDC-3442] [GH-1217] @DDC3441 failing test cases for the ticket Created: 09/Dec/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Dependency
is required for DDC-3441 Unidirectional ManyToOne Not Lazy Loa... Open

 Description   

This issue is created automatically through a Github pull request on behalf of MarcusFulbright:

Url: https://github.com/doctrine/doctrine2/pull/1217

Message:

Failing test cases for the ticket DDC-3441(http://www.doctrine-project.org/jira/browse/DDC-3441)



 Comments   
Comment by Marcus Fulbright [ 09/Dec/14 ]

I didn't realize a ticket would get automatically opened when I submitted a pull request. I already put relevant details for this in DDC-3441. This is a duplicate.

Comment by Doctrine Bot [ 11/Dec/14 ]

A related Github Pull-Request [GH-1217] was assigned:
https://github.com/doctrine/doctrine2/pull/1217

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1217] was labeled:
https://github.com/doctrine/doctrine2/pull/1217

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1217] was labeled:
https://github.com/doctrine/doctrine2/pull/1217





[DDC-3424] Class Table Inheritance - wrong table order on insert with more than one level of inheritance Created: 02/Dec/14  Updated: 04/Dec/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.3
Fix Version/s: 2.2.3
Security Level: All

Type: Bug Priority: Major
Reporter: mohammed Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: ORM
Environment:

Mysql



 Description   

when i use class table inheritance with multiple levels in doctrine :
Account<=User<=Dealer
(Dealer inherits from User, User from Account)
Account has the discriminator column and mapping.
when i persist a new Dealer entity I get a foreign key error because there is no row in the User table.
So the order in which the insert statements are executed:
1) Insert into Account
2) Insert into Dealer (which causes the error)
3) insert into User
Can someone help me thanks in advance.



 Comments   
Comment by Marco Pivetta [ 02/Dec/14 ]

Is this also valid for 2.4.x and master? 2.3.3 is a very old version.

Additionally, could you come up with a small reproduction test case? You can check the ones at https://github.com/doctrine/doctrine2/tree/v2.4.6/tests/Doctrine/Tests/ORM/Functional/Ticket for reference

Comment by mohammed [ 03/Dec/14 ]

This is also valid for 2.4.x and master
this is the test case https://github.com/rogerghost/doctrine2/blob/patch-1/tests/Doctrine/Tests/ORM/Persisters/DDC3424Test.php





[DDC-3415] [GH-1194] [DDC-3414] Add test for "Joining on a table with inheritance produces badly formed ON clause" Created: 26/Nov/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of LewisW:

Url: https://github.com/doctrine/doctrine2/pull/1194

Message:

Add a test for a bug report. The test is only simple with no assertions, since the SQL generated by Doctrine is invalid and generates an exception in SQLite.



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1194] was labeled:
https://github.com/doctrine/doctrine2/pull/1194





[DDC-3414] Joining on a table with inheritance produces badly formed ON clause Created: 26/Nov/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Lewis Wright Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: inheritance, joins, orm, querybuilder


 Description   

When I join on a table that uses class table inheritance, Doctrine automatically joins on the parent table, but it does it before the ON clause.

So for example, writing this DQL:

SELECT uc, c FROM MyModel\Customer c LEFT JOIN MyModel\Customer uc WITH uc.customer = c

produces:

SELECT 
 # Snipped
FROM 
  customer c0_ 
  LEFT JOIN user_customer u2_ 
  INNER JOIN base_user b1_ ON u2_.id = b1_.id ON (u2_.customer_id = c0_.id)

This syntax for the ON clause looks wrong, and fails in SQLite, so I can only assume it's the result of a bug?



 Comments   
Comment by Marco Pivetta [ 26/Nov/14 ]

Please compare the DQL you wrote by hand with the one generated by the QueryBuilder

Comment by Lewis Wright [ 26/Nov/14 ]

The issue appears not to be with just the query builder, but with the DQL version too (see the updated bug report). Would it help if I made a bare-bones doctrine application demoing the problem?

Actually, what would probably be more helpful is if I added a test to the test suite for this bug. I'll see what I can do.

Comment by Marco Pivetta [ 26/Nov/14 ]

We'd need a functional test to add to the test suite, not a demo app. Sending a pull-request with a failing test case will expose the problem immediately.

Comment by Lewis Wright [ 26/Nov/14 ]

Apologies, I should have read the contribute readme first before submitting the ticket. I've created a pull request here with the failing SQLite tests:

https://github.com/doctrine/doctrine2/pull/1194

I did put this ticket number as the PR subject, but the bot seems to have created another issue here:
http://www.doctrine-project.org/jira/browse/DDC-3415

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1194] was labeled:
https://github.com/doctrine/doctrine2/pull/1194





[DDC-3413] Types are always ignored when performing a one to many statement Created: 26/Nov/14  Updated: 12/Mar/15

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

Type: Bug Priority: Major
Reporter: Edouard COLE Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: persister


 Description   

BasicEntityPersister#getOneToManyStatement() is building an array named $criteria. This array is built this way:

$criteria[$tableAlias . "." . $targetKeyColumn] = ...;

This means this array is indexed by keys looking like that:

t0.fieldName

But the function BasicEntityPersister#expandParameters() is used in this function, and this function is NOT able to handle SQL field name as keys, but PHP attributes, because it uses BasicEntityPersister#getType() which is doing this:

case (isset($this->class->fieldMappings[$field])):
case (isset($this->class->associationMappings[$field])):

I think the $criteria array should be used to call BasicEntityPersister#getSelectSQL(), but another array should be passed to expandParameters. Here is a potential fix:

$cleanCriteria[$owningAssoc['fieldName']] = $criteria[$tableAlias . "." . $targetKeyColumn] = ...;

And $cleanCriteria should be passed to expandParameters.



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

Edouard COLE I suggest you to open a pull request with a failing test case, otherwise this issue is hard to follow/understand.

Comment by Edouard COLE [ 12/Mar/15 ]

I think this issue is fixed since https://github.com/doctrine/doctrine2/commit/ce446a6f033ca46fc65911e6f40299336ddace74





[DDC-3406] Proxy returns string instead of object Created: 21/Nov/14  Updated: 25/Jan/15

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

Type: Bug Priority: Major
Reporter: Martin Keckeis Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm, proxy

Issue Links:
Dependency
depends on DDC-3539 [GH-1284] #1189 DDC-3406 derived iden... Open

 Description   

I get an string in one case instead of an entity or proxy.

User -> Address -> Plant -> Hierarchy

User OneToOne Address
Address ManyToOne Plant
Plant OneToOne Hierarchy

(all are fetched as eager loading)

See PR with a test case here
https://github.com/doctrine/doctrine2/pull/1189

Reference
https://github.com/doctrine/DoctrineORMModule/issues/355



 Comments   
Comment by Doctrine Bot [ 21/Nov/14 ]

A related Github Pull-Request [GH-1189] was assigned:
https://github.com/doctrine/doctrine2/pull/1189

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1189] was labeled:
https://github.com/doctrine/doctrine2/pull/1189

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1189] was labeled:
https://github.com/doctrine/doctrine2/pull/1189

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1189] was labeled:
https://github.com/doctrine/doctrine2/pull/1189





[DDC-3400] Wrong result using php-cli Created: 19/Nov/14  Updated: 20/Nov/14

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

Type: Bug Priority: Major
Reporter: Damir Abdijevic Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: cache, cli, dql, environment, orm
Environment:

Windows 7, Debian GNU/Linux 7 PHP 5.5.15



 Description   

Same query produces different results. With apache module everything works like expected. With php-cli the join condition to i18n table is ignored and calling getCountries() returns all and not only that entity that is matched by join condition.

        $qb = $this->_em->createQueryBuilder()
                        ->select('t', 'i18n')
                        ->from($this->_entityName, 't')
                        ->innerJoin('t.countries', 'i18n')
                        ->where('i18n.locale = :localeId')
                        ->setParameter('localeId', $localeId);

Country Entity:

namespace MyApp\Model\Entity;

use Doctrine\ORM\Mapping as ORM;
use Doctrine\Common\Collections\ArrayCollection;

/**
 * Country entity
 *
 * @ORM\Entity(repositoryClass="MyApp\Model\Repository\Country")
 * @ORM\Table(name="country")
 *
 */
class Country
{
    /**
     * @var int
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

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

    /**
     * @var int
     * @ORM\Column(type="integer", name="sort", unique=true)
     */
    protected $sort;

    /**
     * @var ArrayCollection
     * @ORM\OneToMany(targetEntity="ProductDescription\Model\Entity\CountryI18n", mappedBy="country", cascade={"all"})
     */
    protected $countries;


    /**
     * Constructor
     *
     * @return Country
     */
    public function __construct()
    {
        $this->countries = new ArrayCollection();
    }

    /**
     * Getter for $this->id
     *
     * @return int
     */
    public function getId()
    {
        return $this->id;
    }

    /**
     * Setter for $this->id
     *
     * @param int $id entity id
     *
     * @return void
     */
    public function setId($id)
    {
        $this->id = (int) $id;
    }

    /**
     * Getter for $this->sort
     *
     * @return int
     */
    public function getSort()
    {
        return $this->sort;
    }

    /**
     * Setter for $this->sort
     *
     * @param int $sort sort order
     *
     * @return void
     */
    public function setSort($sort)
    {
        $this->sort = (int) $sort;
    }

    /**
     * Getter for $this->name
     *
     * @return string
     */
    public function getName()
    {
        return $this->name;
    }

    /**
     * Setter for $this->name
     *
     * @param string $name language name in german
     *
     * @return void
     */
    public function setName($name)
    {
        $this->name = (string) $name;
    }

   /**
    * Get collection from i18n table
    *
    * @return ArrayCollection
    */
    public function getCountries()
    {
        return $this->countries;
    }

    /**
     * Proxy method. So we have working with all entities same method
     * to getting i18n data.
     *
     * @return ArrayCollection
     */
    public function getI18n()
    {
        return $this->getCountries();
    }

CountryI18nEntity:

namespace MyApp\Model\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * CountryI18n entity
 *
 * @ORM\Entity
 * @ORM\Table(name="country_i18n", uniqueConstraints={@ORM\UniqueConstraint(name="idx_UNIQUE_country_id_locale_id", columns={"country_id", "locale_id"})})
 */
class CountryI18n
{
    /**
     * @var int
     * @ORM\Id
     * @ORM\Column(type="integer", name="id")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\ManyToOne(targetEntity="ProductDescription\Model\Entity\Country", inversedBy="countries")
     * @ORM\JoinColumn(name="country_id", referencedColumnName="id")
     */
    protected $country;

    /**
     * @ORM\ManyToOne(targetEntity="ProductDescription\Model\Entity\Language", inversedBy="countries")
     * @ORM\JoinColumn(name="locale_id", referencedColumnName="id")
     */
    protected $locale;

    /**
     * @var string
     * @ORM\Column(type="string", name="name", length=255)
     */
    protected $name;


    /**
     * Getter for $this->id
     *
     * @return int
     */
    public function getId()
    {
        return $this->id;
    }

    /**
     * Setter for $this->id
     *
     * @param int $id id of row primary key
     *
     * @return void
     */
    public function setId($id)
    {
        $this->id = (int) $id;
    }

    /**
     * Getter for $this->country
     *
     * @return Country
     */
    public function getCountry()
    {
        return $this->country;
    }

    /**
     * Setter for $this->country
     *
     * @param Country $country country entity to set
     *
     * @return void
     */
    public function setCountry(Country $country)
    {
        $this->country = $country;
    }

    /**
     * Getter for $this->locale
     *
     * @return Language
     */
    public function getLocale()
    {
        return $this->locale;
    }

    /**
     * Setter for $this->locale
     *
     * @param Language $locale language entity to set as locale
     *
     * @return void
     */
    public function setLocale(Language $locale)
    {
        $this->locale = $locale;
    }

    /**
     * Getter for $this->name
     *
     * @return string
     */
    public function getName()
    {
        return $this->name;
    }

    /**
     * Setter for $this->name
     *
     * @param string $name translation name
     *
     * @return void
     */
    public function setName($name)
    {
        $this->name = (string) $name;
    }

}


 Comments   
Comment by Marco Pivetta [ 19/Nov/14 ]

Looks like a caching issue. The amount of information provided is insufficient as it is. I'd suggest verifying if the generated SQL is the same, and checking that all caches were cleared both in CLI and in WEB sapis.

Comment by Damir Abdijevic [ 20/Nov/14 ]

O.k. here some further information.

No caching like Xcache or APC is enabled. PHP 5.5 integrated opcache ist not enabled. All Doctrine caches are set to Array. The sql queries are in both cases exactly the same:

sql
SELECT c0_.id AS id0, c0_.name AS name1, c0_.sort AS sort2, c1_.id AS id3, c1_.name AS name4, c1_.country_id AS country_id5, c1_.locale_id AS locale_id6 FROM country c0_ INNER JOIN country_i18n c1_ ON c0_.id = c1_.country_id WHERE c1_.locale_id = ?

/* locale_id = 2 */

The sql result is correct

Running the console script a ZF2 Initializer runs before that performs this query builder query:

QueryBuilder

$qb = $this->_em->createQueryBuilder()
                            ->select('t', 'i18n', 'l')
                            ->from($this->_entityName, 't')
                            ->innerJoin('t.countries', 'i18n')
                            ->innerJoin('i18n.locale', 'l');

That results in following SQL:

sql
SELECT c0_.id AS id0, c0_.name AS name1, c0_.sort AS sort2, c1_.id AS id3, c1_.name AS name4, l2_.id AS id5, l2_.name AS name6, l2_.full_name AS full_name7, l2_.locale AS locale8, c1_.country_id AS country_id9, c1_.locale_id AS locale_id10, l2_.country_id AS country_id11 FROM country c0_ INNER JOIN country_i18n c1_ ON c0_.id = c1_.country_id INNER JOIN language l2_ ON c1_.locale_id = l2_.id
Comment by Marco Pivetta [ 20/Nov/14 ]

What happens if you run those SQL statements via CLI (dbal:run-sql) or WEB? Same results?

Comment by Damir Abdijevic [ 20/Nov/14 ]

The sql result is correct. Can I attach it to the ticket? I have exported it to csv.

Comment by Marco Pivetta [ 20/Nov/14 ]

If the same results are produced on CLI and WEB APIs then I suggest trying to insulate the issue in a functional test to be run in both context. You probably have a different ORM bootstrap for CLI and WEB.

Attaching a CSV for same results makes no real difference here.

Comment by Damir Abdijevic [ 20/Nov/14 ]

No, I didn't want to attach two times the same result. Wanted to attach it one time to show that those entitites that are wrong in the result doesn't appear in the sql result at all. I don't have different bootstraps. After a few short tests I think it is an error in th ArrayCache mechanism. The difference was that using Apache one initializer was not called. Calling this initializer in both cases leads now to wrong results in CLI and WEB API.

When the second query is not executed everything is fine. But when the second longer query runs and selects all i18n entities and after it the first query runs then the issue appears.





[DDC-3399] indexBy expects db field names insteadof model property names Created: 19/Nov/14  Updated: 19/Nov/14

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

Type: Documentation Priority: Major
Reporter: Oliver Hoff Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The following example does work:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
/**
 * @ORM\Entity
 */
class Order {

	use IDTrait;

	/**
	 * @ORM\OneToMany(
	 * 		targetEntity="OrderCategory",
	 * 		mappedBy="order",
	 * 		indexBy="my_category_id",
	 * 		fetch="EAGER",
	 * 		cascade={"all"},
	 * 		orphanRemoval=true
	 * )
	 * @var Collection
	 */
	private $categories;

}

/**
 * @ORM\Entity
 */
class OrderCategory {

	/**
	 * @ORM\ManyToOne(targetEntity="Order", inversedBy="categories")
	 * @ORM\JoinColumn(name="order_id", referencedColumnName="id", onDelete="CASCADE")
	 * @ORM\Id
	 * @var Order
	 */
	private $order;

	/**
	 * @ORM\ManyToOne(targetEntity="Category")
	 * @ORM\JoinColumn(name="my_category_id", referencedColumnName="id", onDelete="RESTRICT")
	 * @ORM\Id
	 * @var Category
	 */
	private $category;

}

If you use indexBy="category", it does not work. Why are the object property names used for referencing in most of the mapping, but for indexBy you have to use the db field name? It is nowhere mentioned in the docs.
I didnt test this with non-association properties as indexBy.






[DDC-3398] PersistentCollection doesn't check that Entity is managed before scheduling orphan removal Created: 18/Nov/14  Updated: 18/Nov/14

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

Type: Bug Priority: Major
Reporter: Nicholas Dobie Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orphanRemoval


 Description   

I am adding and removing a non-persisted entity to a PersistentCollection before flushing. The collections field is an OneToMany relation with orphanRemoval. When the entity is removed it is automatically scheduled for orphanRemoval but is never checked if it is actually a managed entity before being scheduled which causes an exception. After it has been scheduled there is no way to unschedule it other than completely clearing the UnitOfWork.



 Comments   
Comment by Marco Pivetta [ 18/Nov/14 ]

Does this affect also later versions?





[DDC-3390] [GH-1185] add a new method that return the mapped properties Created: 12/Nov/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of fabiocarneiro:

Url: https://github.com/doctrine/doctrine2/pull/1185

Message:

There are some implementations that use the doctrine metadata to get the properties of a entity (DoctrineObject), and it currently uses the getFieldNames and getAssociationNames methods to retrieve and merge it.

Since the embeddables feature was added, that method will return more than one metadata for each embeddable property, and then the hydrator can never find the appropriate setter for that property.

This method allows some implementation to retrieve all mapped fields from an entity, something that can't be done using get_class_vars for example.

Of course this implementation could be done in the hydrator, but i don't think it is its responsibility to filter and merge data received from the ClassMetadata. Since you have methods to retrieve the metadata formatted as the database structure, you should also have methods to retrieve the information to the other side, in object structure.



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1185] was labeled:
https://github.com/doctrine/doctrine2/pull/1185





[DDC-3383] [GH-1179] Fix embeddables class metadata (work-in-progress) Created: 10/Nov/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of fabiocarneiro:

Url: https://github.com/doctrine/doctrine2/pull/1179

Message:

ClassMetadataInfo is returning more than one result in getFieldNames() for the embeddables properties. This method is used by DoctrineModule\Stdlib\Hydrator\DoctrineObject in the extraction process.

Since its returning a number of results equal the number of properties of the embedded object, it will never find the correct setter for the extraction and that causes that property to be removed from the extracted array.

I was able to solve the issue by hacking into the getFieldNames() for testing and merging the duplicated entries, and then the object was successfully extracted.

By digging into the code, i found out that there is a mapEmbedded(), but instead of using that for embeddeds, its using the default mapField, which may be the root cause of the problem.

  • [x] Hack into the getFieldNames() method to see if the expected solution would work
  • [x] Remove multiple class declaration in the same file from the files i'll work with
  • [x] Create a failing testcase
  • [ ] Create a solution


 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1179] was labeled:
https://github.com/doctrine/doctrine2/pull/1179

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1179] was labeled:
https://github.com/doctrine/doctrine2/pull/1179





[DDC-3381] orm:schema-tool:update shows incorrect changes with MasterSlaveConnection wrapper class Created: 09/Nov/14  Updated: 10/Nov/14

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

Type: Bug Priority: Major
Reporter: Pieter Vogelaar Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: connection, ddl, master-slave, schematool


 Description   

My entities and database are in sync. If I use the default Doctrine connection configuration it shows "Nothing to update - your database is already in sync with the current entity metadata.". This is what I would expect and is correct.

'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'driverClass' => 'Doctrine\DBAL\Driver\PDOMySql\Driver',
                'params' => array(
                    'host'     => 'localhost',
                    'port'     => '3306',
                    'user'     => 'myuser',
                    'password' => 'mypassword',
                    'dbname'   => 'example',
                    'charset'  => 'utf8',
                ),
        ),
),

But with the MasterSlaveConnection configuration, I always get the same changes which are a lot, you would think the database is empty at the moment.

'doctrine' => array(
        'connection' => array(
            'orm_default' => array(
                'wrapperClass' => 'Doctrine\DBAL\Connections\MasterSlaveConnection',
                'params' => array(
                    'driver' => 'pdo_mysql',
                    'master' => array(
                        'host' => 'localhost',
                        'port' => '3306',
                        'user' => 'myuser',
                        'password' => 'mypassword',
                        'dbname' => 'example',
                        'charset' => 'utf8',
                    ),
                    'slaves' => array(
                        array(
                            'host' => 'localhost',
                            'port' => '3306',
                            'user' => 'myuser',
                            'password' => 'mypassword',
                            'dbname' => 'example',
                            'charset' => 'utf8',
                        ),
                    ),
                ),
            ),
        ),
    ),
),


 Comments   
Comment by Marco Pivetta [ 10/Nov/14 ]

Can you come up with a functional test case for this? Couldn't reproduce from here.





[DDC-3376] Only one row is returned Created: 06/Nov/14  Updated: 07/Nov/14

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

Type: Bug Priority: Major
Reporter: Patryyyck Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: inheritance, lazy-loading, n+1-queries, sti
Environment:

Linux Mint 17
PHP 5.5.9
Apache 2.4.7
Symfony 2.4.10
Doctrine ORM 2.4.6
Doctrine DBAL 2.4.3
Sql Server database



 Description   

Hi,

I don't know if you are the appropriate person.
I have an issue with Doctrine ORM or DBAL.
By the way, i'm not sure the issue is in one of these bundles.

I'm trying to get all the rows of on an entity A which is a SINGLE_TABLE with 3 discriminators.
This entity has a property "parent" which is a self referencing property (ManyToOne on entity A).

The getResult of my query only return the first row of my table.
When i replace getResult by getArrayResult, i have all my table.
But i want the objects

After hours of debugging, i saw that the Doctrine ORM ObjectHydrator.php loops on the result of my query (which have the good number of results):

while ($row = $this->_stmt->fetch(PDO::FETCH_ASSOC)) {
    $this->hydrateRowData($row, $cache, $result);
}

But, the hydrateRowData executes another query to get the parent of each row (Doctrine DBAL Connection.php function executeQuery).
This function prepares a query to get the parent with a param (parent id) and i think the prepare function return the same statement (stmt) as the first query (the list of all the entity A).
So, the prepared query is executed but when the Doctrine ORM ObjectHydrator.php want to fetch the second row, he considers that there's no more rows to fetch and return the first rows.

I don't know if i am clear enough. Tell me if you want more details.

Oh. I forgot. If i try the same request with the same datas but in a mySQL database (pdo_mysql), i have a good result. I don't know if that helps.

Thanks

Regards



 Comments   
Comment by Marco Pivetta [ 07/Nov/14 ]

The issue you described is very well known and it is a limitation of the ORM. What happens is following:

1. you have an inheritance A -> B | C | D (A being the root of the inheritance)
2. A has a self-referencing association to A (typically like a hierarchy of parent-child)
3. the ORM tries to load an A instance that has a reference to a parent of type A. In order to do so, the ORM has to resolve the actual type of the referenced parent, and therefore cannot lazily load it via a proxy (a query has to be executed in order to find out the value of the discriminator column)

This means that for performance reasons you should NEVER reference the root of an inheritance, but only leafs (where the ORM does not need to do this sort of resolution).

See also http://doctrine-orm.readthedocs.org/en/latest/reference/inheritance-mapping.html#id4 (Performance impact of inheritance mapping) for more details.

Comment by Patryyyck [ 07/Nov/14 ]

Thanks Marco for your quick answer.

I understand the ORM limitation.
But i still don't understand why this limitation doesn't exist when i use a MySQL database.





[DDC-3371] MultiTableUpdateExecutor does not handle input parameters correctly within arithmetic expression assignments to updated fields Created: 05/Nov/14  Updated: 05/Nov/14

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

Type: Bug Priority: Major
Reporter: Michael Plomer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

An update statement like

UPDATE MyEntity e SET e.value1 = e.value1 + :inParam1 WHERE e.value2 = :inParam2

will fail if MyEntity is part of a join table inheritance hierarchy and hence the update is handled by the MultiTableUpdateExecutor. The insert statement for the temporary ID table causes the following PDOException:

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens

The problem is in counting the number of input parameters in the update part of the statement. Lines 127-131 of the MultiTableUpdateExecutor:

if ($newValue instanceof AST\InputParameter) {
    $this->_sqlParameters[$i][] = $newValue->name;
    ++$this->_numParametersInUpdateClause;
}

fall short in detecting input parameters unless they are directly assigned as new values.






[DDC-3367] [GH-1171] Improvements for complex select statements when using new object expression Created: 28/Oct/14  Updated: 13/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jaimz22:

Url: https://github.com/doctrine/doctrine2/pull/1171

Message:

My update allows you to alias objects created with the ["new" object expression](http://doctrine-orm.readthedocs.org/en/latest/reference/dql-doctrine-query-language.html#new-operator-syntax), as well as the ability to create queries that allow you to have multiple "new" object expressions and mixed scalar results.

Suppose you create a query as such:

```dql
SELECT new UserDTO(u.id,u.name) as user,new AddressDTO(a.street,a.postalCode) as address, a.id as addressId FROM User u INNER JOIN u.addresses a WITH a.isPrimary = true
```

upon executing this query, you'll end up with a result set that looks like the following:

```php
array(
0=>array(
0=>

{UserDTO object},
1=>{AddressDTO object},
2=>{u.id scalar},
3=>{u.name scalar},
4=>{a.street scalar},
5=>{a.postalCode scalar},
'addressId'=>{a.id scalar},
),
...
)
```

My changes fix that so you'd end up with a more usable result set:

```php
array(
0=>array(
'user'=>{UserDTO object}

,
'address'=>

{AddressDTO object}

,
'addressId'=>

{a.id scalar}

)
...
)
```



 Comments   
Comment by Doctrine Bot [ 13/Jan/15 ]

A related Github Pull-Request [GH-1171] was merged:
https://github.com/doctrine/doctrine2/pull/1171





[DDC-3364] QueryBuilder fails when using alias in having with like expr Created: 21/May/14  Updated: 26/Oct/14

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

Type: Bug Priority: Major
Reporter: webDEVILopers Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: GROUP_CONCAT, dql, expression, having, like, mysql
Environment:

Debian, MySQL, PHP, Zend Framework 2, Doctrine Module, Doctrine Extensions



 Description   

In my select I create an alias. I use a like expr on this alias in the having clause.

Trying several variations I still get the following error:
Expected '.' or '(', got 'long_name'

My example including variations inside comments:

$having = $qb->expr()->like('long_name', $qb->expr()->literal('%' . $term . '%'));

$qb->select(array(
    'b.id', 'b.name AS branch_name',
    'c.name AS company_name',
    'GroupConcat(b.name, \', \', c.name) AS long_name' // same for 'c.name AS long_name'
))
->from('Application\Entity\Branch', 'b')
->join('b.company', 'c')
->where('b.compartment = 1')
->having('(' . $having . ')') // same for having($having)
->groupBy('c.id')
->orderBy('c.name')
->addOrderBy('b.name');

I use a Doctrine Extension for the MySQL GROUP_CONCAT functionality:
https://github.com/beberlei/DoctrineExtensions/blob/master/lib/DoctrineExtensions/Query/Mysql/GroupConcat.php

This should have no effect on the result since I tried a simple alias - see comment - instead of it.

The problem seems to be using an alias inside the having clause when adding the like expr.
The following clause would work:

$having = $qb->expr()->like('c.name', $qb->expr()->literal('%' . $term . '%'));

I also tried this workaround using the GROUP_CONCAT method inside the where part:

->andWhere($qb->expr()->like('GroupConcat(b.name, \', \', c.name)', $qb->expr()->literal('%' . $term . '%')))

Allthough I used the groupBy part I got this error:
General error: 1111 Invalid use of group function



 Comments   
Comment by Marco Pivetta [ 26/Jun/14 ]

What is the actual failure/exception type? What about the generated SQL?

Comment by Steve Müller [ 26/Oct/14 ]

Moved to ORM, the error and use case is ORM related.





[DDC-3362] [GH-1168] [DDC-1952] Support for array parameters on the SQLFilter Created: 24/Oct/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of xpavp03:

Url: https://github.com/doctrine/doctrine2/pull/1168

Message:

Allows passing an array to SQLFilter parameter and have each item pass through quote() before turning the whole array into a comma-separated list.

For purpose see here:
http://www.doctrine-project.org/jira/browse/DDC-1952

Exception is made for types that Doctrine already recognizes as an array and stores as their derivate (array, simple_array, json_array).



 Comments   
Comment by Doctrine Bot [ 24/Oct/14 ]

A related Github Pull-Request [GH-1168] was assigned:
https://github.com/doctrine/doctrine2/pull/1168

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1168] was labeled:
https://github.com/doctrine/doctrine2/pull/1168





[DDC-3361] Doctrine error while trying to execute a DQL query on PostgreSQL 9.2.x Created: 23/Oct/14  Updated: 31/Mar/15

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

Type: Bug Priority: Major
Reporter: Reynier Perez Mira Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: postgresql, typecast
Environment:

CentOS 6.5, PostgreSQL 9.2, Symfony 2.5.5, Doctrine 2.4.6



 Description   

I have this DQL on a repository class:

    public function filterNorm($codigo = null, $anno = null, $term = null, $comite_tecnico = null)
    {
        $qb = $this->getEntityManager()->createQueryBuilder();
        $qb
                ->select('n')
                ->from("AppBundle:Norma", "n");

        if ($codigo != NULL) {
            $qb->where(
                    $qb->expr()->like('n.numero', $qb->expr()->literal('%'.$codigo.'%'))
            );
        }

        if ($anno != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.anno', $qb->expr()->literal('%'.(int) $anno.'%'))
            );
        }

        if ($term != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.nombre', $qb->expr()->literal('%'.$term.'%'))
            );
        }

        if ($comite_tecnico != NULL) {
            $qb->orWhere(
                    $qb->expr()->like('n.comite_tecnico', $qb->expr()->literal('%'.(int) $comite_tecnico.'%'))
            );
        }

        return $qb->getQuery()->getResult();
    }

And when I try to execute it, leaving the first paramter null, I got this error:

An exception occurred while executing 'SELECT n0_.numero AS numero0, n0_.anno AS anno1, n0_.id AS id2, n0_.nombre AS nombre3, n0_.activo AS activo4, n0_.comite_tecnico_id AS comite_tecnico_id5 FROM nomencladores.norma n0_ WHERE n0_.anno LIKE '%34%' OR n0_.nombre LIKE '%sad%'':

SQLSTATE[42883]: Undefined function: 7 ERROR: operator does not exist: integer ~~ unknown
LINE 1: ...o_id5 FROM nomencladores.norma n0_ WHERE n0_.anno LIKE '%34%...
^
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts. 

I think in somewhere Doctrine is failing or not, not so sure, if not what will be the solution around this issue I'm having?



 Comments   
Comment by Marco Pivetta [ 23/Oct/14 ]

First of all: do not hardcode parameters in your DQL, as that represents a possible DQL injection vector.

Is your schema in sync with the ORM mappings? Postresql seems to complain about a missing operator between incompatible types.

Comment by Reynier Perez Mira [ 23/Oct/14 ]

What you mean with "do not hardcode parameters in your DQL"? How should I do this? And yes schema and ORM mappings are good:

Symfony > doctrine:schema:validate
[Mapping] OK - The mapping files are correct.
[Database] OK - The database schema is in sync with the mapping files.

Comment by Marco Pivetta [ 23/Oct/14 ]

What you mean with "do not hardcode parameters in your DQL"? How should I do this?

You wrote:

$qb->where($qb->expr()->like('n.numero', $qb->expr()->literal('%'.$codigo.'%')));

Should be:

$qb->where($qb->expr()->like('n.numero', ':codigo'));
$qb->setParameter('codigo', '%' . $codigo . '%');
Comment by Reynier Perez Mira [ 08/Nov/14 ]

Hi there @ocramius any advice around this issue? Any tip to get ride of this? I have similar queries all over the application I'm working on and still don't know how to deal with this, thanks

Comment by Marco Pivetta [ 08/Nov/14 ]

Seems to be a db-side type mismatch in a comparison, not a D2 bug.

Comment by Reynier Perez Mira [ 08/Nov/14 ]

@ocramius and how I should deal with this? Any idea?

Comment by Felipe Araújo Nunes de Lima [ 31/Mar/15 ]

I think the field 'numero' is an integer and because it cannot be used in a LIKE function.
I'm looking for a function that search for parts of numbers in doctrine, and i have a little idea to do it.





[DDC-3354] Replacing indexed item on association with indexBy cannot comply with unicity constraint Created: 17/Oct/14  Updated: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Charles Bouchard-Légaré Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, mapping, orm


 Description   

Using a bidirectional one-to-many relation having an 'indexBy' clause on the owning side and a unique constraint over the indexed field and the 'mappedBy' field of the inverse side, replaced indexed fields being inserted before removed violated the unique constraint.

As stated in the code examples below, if done without the unique constraint, when replacing an indexed field, the row is replaced in the database (new one created, old one deleted).

Here is an example:

Yaml Mapping for Person and Email
Person:
    type: entity
    id:
        id:
            type: integer
            generator:
                strategy: AUTO
    oneToMany:
        emailAddresses:
            targetEntity: Email
            indexBy: name
            mappedBy: owner
            cascade: [ all ]
            orphanRemoval: true

Email:
    type: entity
    id:
        id:
            type: integer
            generator:
                strategy: AUTO
    fields:
        name:
            type: string
            nullable: false
        address:
            type: string
            nullable: false
    uniqueConstraints:
        unique_named_person_email:
            columns: [ owner_id, name ]
    manyToOne:
        owner:
            targetEntity: Person
            inversedBy:   emailAddresses
            joinColumn:
                name: owner_id
                referencedColumnName: id
PHP definitions for Person and Email
class Person {
    protected $id;
    /**
     * @var Collection|Email[] $emailAddresses
     */
    protected $emailAddresses;

    /**
     * I would expect this to work.
     */
    public function setEmailAddress_expected($name, $emailAddress)
    {
        /**
         * Expected to work but throws UniqueConstraintViolationException
         * If done without the 'unique_named_person_email' constraint', it 
         * works properly creating a new Email and deleting the old one.
         */
        $this->emailAddresses->set(
            (string) $name,
            new Email($this, (string) $name, (string) $emailAddress)
        );
    }
    
    /**
     * I would expect this to work.
     */
    public function setEmailAddress_expected_too($name, $emailAddress)
    {
        /**
         * Expected to work but throws UniqueConstraintViolationException
         * If done without the 'unique_named_person_email' constraint, it 
         * works properly creating a new Email and deleting the old one.
         */
        $this->emailAddresses->remove((string) $name);
        $this->emailAddresses->set(
            (string) $name,
            new Email($this, (string) $name, (string) $emailAddress)
        );
    }

    /**
     * Works
     */
    public function setEmailAddress_works($name, $emailAddress)
    {
        $existing = $this->emailAddresses->get((string) $name);
        if ($existing) {
            $existing->setAddress((string) $emailAddress);
        } else {
            $this->emailAddresses->set(
                (string) $name,
                new Email($this, (string) $name, (string) $emailAddress)
            );
        }
    }
}

class Email {
    protected $id;
    protected $owner;
    protected $name;
    protected $address;
    public function __construct($owner, $name, $address)
    {
        $this->owner = $owner;
        $this->name = $name;
        $this->address = $address;
    }

    /**
     * I am forced to create this method.
     */
    public function setAddress($address)
    {
        $this->address = $address;
    }
}

IMO, Using 'indexBy' on a one-to-many relation should automatically generate a unique constraint for the combination of the indexed field and the 'mappedBy' field.

Documentation states that

Fields that are used for the index by feature HAVE to be unique in the database. The behavior for multiple entities with the same index-by field value is undefined.

which is unclear (especially the use of the word 'database'). I wonder why indexes used for association should be unique for a whole table.



 Comments   
Comment by Marco Pivetta [ 19/Oct/14 ]

I wonder why indexes used for association should be unique for a whole table.

That's because we can't ensure that indexes aren't overwritten when hydrating a collection: that is what the behavior "undefined" stands for.

As for replacing values in the collection, that's how the ORM works in any case, as it inserts data before removing any data to avoid removes from causing FK constraint failures (see https://github.com/doctrine/doctrine2/blob/d361ed904e5d56711304b755b5b2a8484d9a35b6/lib/Doctrine/ORM/UnitOfWork.php#L347-L379)





[DDC-3349] Possibility to override order of fields of composite ID produced by Mapping Created: 13/Oct/14  Updated: 16/Jan/15

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

Type: New Feature Priority: Major
Reporter: tiger-seo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping

Issue Links:
Reference
relates to DDC-3352 [GH-1162] DDC-3349: Possibility to ov... Resolved

 Description   

So, the problem is when the one needs to use association key in composite identifier; they are added in the end of the identifier array, which is clearly not always suitable in regards to performance.
For example, following mapping:

Acme\DemoBundle\Entity\PageLocalFans:
    type: entity
    id:
        date:
            type: date
        page:
            associationKey: true
        countryCode:
            type: string
            length: 2
    fields:
        fans:
            type: integer
    manyToOne:
        page:
            targetEntity: Page
            joinColumn:
                name: page_id
                referencedColumnName: id
                onDelete: CASCADE

will turn into sql as:

CREATE TABLE page_local_fans (
  date         DATE       NOT NULL,
  country_code VARCHAR(2) NOT NULL,
  page_id      INT        NOT NULL,
  fans         INT        NOT NULL,
  INDEX IDX_7391EB36C4663E4 (page_id),
  PRIMARY KEY (date, country_code, page_id)
) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

and there is no way to change the order of the primary from

PRIMARY KEY (date, country_code, page_id)

to

PRIMARY KEY (date, page_id, country_code)


 Comments   
Comment by tiger-seo [ 14/Oct/14 ]

i've done the PR for this, pls see https://github.com/doctrine/doctrine2/pull/1162

Comment by Doctrine Bot [ 17/Oct/14 ]

A related Github Pull-Request [GH-1162] was assigned:
https://github.com/doctrine/doctrine2/pull/1162

Comment by Doctrine Bot [ 16/Jan/15 ]

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





[DDC-3344] Flush on a specific entity is not correctly cascaded to associated entities Created: 10/Oct/14  Updated: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Pavel Horal Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

In a setup with a simple entity associated entity, the cascade is not performed when flushing the parent entity. This violates contract specified by EntityManager#flush($entity) PHPDoc:

If an entity is explicitly passed to this method only this entity and the cascade-persist semantics + scheduled inserts/removals are synchronized.

It seems that the reason behind this is UnitOfWork#computeAssociationChanges, which expects that a #computeChangeSets is called elswehere (which it is not when flushing a specific entity):

MANAGED associated entities are already taken into account during changeset calculation anyway, since they are in the identity map.

This makes flushing and cascading very confusing. Also I believe this might be a cause of other issues, like DDC-3113.



 Comments   
Comment by Marco Pivetta [ 10/Oct/14 ]

Doctrine\ORM\EntityManager#flush() is not supposed to be called with a specific entity when there are cascade operations involved.

The optional argument has to be only used for performance reasons, but can indeed break things.

Comment by Pavel Horal [ 10/Oct/14 ]

Thank you for the reply. I am probably (and possibly other people) misinterpretting the PHPDoc. Can you explain what is meant by "and the cascade-persist semantics"?

Comment by Marco Pivetta [ 19/Oct/14 ]

Pavel Horal I don't really understand that bit myself, but git blame states that the comment was introduced in https://github.com/doctrine/doctrine2/commit/5d3298e706b1457ca8be02469b00ef219afe84e6 by Benjamin Eberlei.

Maybe it just needs a docblock rewrite

Comment by Pavel Horal [ 19/Oct/14 ]

Commit is linked with DDC-720 . Again, that gives me an impression that events should be cascaded:

In a nutshell, this change would mean that flush() can optionally accept an entity as an argument. When that happens, the resulting changeset will be limited to that entity and any entity reachable from it.

Comment by Marco Pivetta [ 19/Oct/14 ]

Again, that gives me an impression that events should be cascaded

No, the entire flush($entity) functionality is just to limit the entire Doctrine\ORM\UnitOfWork operations over the single object: it's expected behavior.

In general, you should use flush($entity) only if you have very high priority performance optimizations, as it was never meant to be reliable API when using listeners.

I'd even suggest deprecating it for removal in the next major release, as it has only caused issues so far.





[DDC-3340] __wakeup not called in UoW::createEntity when loading uninitialized proxy Created: 07/Oct/14  Updated: 13/Oct/14

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

Type: Bug Priority: Major
Reporter: Uwe Jäger Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I'm using __wakeup to initialize a property with an empty ArrayCollection for a transient property. But when I try to "find" the entity and the uninitialized Proxy is already in the entity map, the proxy is simply set to "initialized" but my code to init the collection is never call (see https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L2552). So neither the constructor of my entity nor the proxies' _load method are called.
Where should I initialize that collection?



 Comments   
Comment by Uwe Jäger [ 07/Oct/14 ]

I just added a postLoad event listener that seems to do the trick in this case, so I have three things to do
1. implement __wakeup to make proxies' load work
2. implement a constructor
and
3. add a postLoad Listener.

Lot's of code for a simple $this->collection = new ArrayCollection();

Comment by Marco Pivetta [ 07/Oct/14 ]

Can you code this as a failing test case? Fixing it should be trivial afterwards.

Also, which version is affected?

Comment by Christophe Coevoet [ 13/Oct/14 ]

__wakeup is not a way to hook in the loading of the entity for Doctrine. The way to hook into the loading of the entity is to use the postLoad lifecycle callback.

Calling __wakeUp when initializing the proxy would be abusing this method, as it has a different purpose in PHP.

Comment by Marco Pivetta [ 13/Oct/14 ]

Christophe Coevoet we currently use __wakeup for transient properties wakeup on proxy initialization...

Comment by Marco Pivetta [ 13/Oct/14 ]

As an example:

class Foo
{
    /** @Id @Column */
    private $bar;
    private $transientField;

    public function __construct()
    {
        $this->transientField = new SomeUtil();
    }

    public function __wakeup()
    {
        $this->transientField = new SomeUtil();
    }
}

This is expected __wakeup usage. Is this broken for you, Uwe Jäger?

Comment by Uwe Jäger [ 13/Oct/14 ]

This is broken when the entity was loaded before via a relation and the proxy is not initialized. Doing a find in the same request finds the proxy in UoWs identityMap but __wakeup is not called then, so the property is not initialized.

Comment by Marco Pivetta [ 13/Oct/14 ]

Uwe Jäger is it actually a proxy? Or just an entity? Proxy initialization happens if __wakeup is defined as of https://github.com/doctrine/doctrine2/blob/3ca0dae6062f13b448f9b5f154cf9690d24a1913/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L138

Comment by Uwe Jäger [ 13/Oct/14 ]

It is a proxy, please check https://github.com/doctrine/doctrine2/blob/3ca0dae6062f13b448f9b5f154cf9690d24a1913/lib/Doctrine/ORM/UnitOfWork.php#L2552, there __wakeup is not called.

Comment by Marco Pivetta [ 13/Oct/14 ]

Uwe Jäger that is indeed a bug. Checking reflection there seems to be a bit too performance-heavy.

A test for that would be (pseudo):

class Foo
{
    /** @Id @Column */
    public $id;
    public $transientField;

    public function __construct()
    {
        $this->transientField = 123;
    }

    public function __wakeup()
    {
        $this->transientField = 123;
    }
}
$foo = new Foo();

$em->persist($entity);
$em->flush();
$em->clear();

$entity = $em->getReference('Foo', $foo->id);
$em->createQuery('SELECT f FROM Foo f')->setHint(AbstractQuery::HINT_REFRESH, true)->getResult();

$this->assertInstanceOf('...Proxy', $entity);
$this->assertTrue($entity->__isInitialized());
$this->assertSame(123, $entity->transientField);




[DDC-3335] Merge with value object causes notice Created: 03/Oct/14  Updated: 03/Oct/14

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

Type: Bug Priority: Major
Reporter: David de Boer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This:

// Assume Location is some value object
$valueObject = new Location(); // or e.g. new \stdClass()
$em->merge($valueObject);

causes this:

Notice: Undefined offset: 0 in /vagrant/api/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 729

While I agree merge shouldn't work for value objects, wouldn't it be better to throw an exception when ClassMetadataInfo tries to find an identifier that isn't there?






[DDC-3332] [GH-1152] Adds error message when the key is composite Created: 02/Oct/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of fran6co:

Url: https://github.com/doctrine/doctrine2/pull/1152

Message:

An example is:

```
SELECT u FROM User u INNER JOIN Address a ON a.user = u
```

When User has a composite key.



 Comments   
Comment by Doctrine Bot [ 02/Oct/14 ]

A related Github Pull-Request [GH-1152] was assigned:
https://github.com/doctrine/doctrine2/pull/1152

Comment by Doctrine Bot [ 17/Jan/15 ]

A related Github Pull-Request [GH-1152] was assigned:
https://github.com/doctrine/doctrine2/pull/1152

Comment by Doctrine Bot [ 17/Jan/15 ]

A related Github Pull-Request [GH-1152] was unassigned:
https://github.com/doctrine/doctrine2/pull/1152

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1152] was labeled:
https://github.com/doctrine/doctrine2/pull/1152

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1152] was labeled:
https://github.com/doctrine/doctrine2/pull/1152





[DDC-3328] [GH-1150] Improve Comparison::CONTAINS: allow to use custom position for % and _ wildcard characters Created: 28/Sep/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Fedik:

Url: https://github.com/doctrine/doctrine2/pull/1150

Message:

This pull prevent forced wrapping of the value in to `%`
and allow to use the custom position for `%` and `_` wildcard characters in case `Comparison::CONTAINS`

Allow to build the `contains` expressions like:
```php
Criteria::expr()->contains('myField', 'some string%');
Criteria::expr()->contains('myField', '%some string');
Criteria::expr()->contains('myField', '10%');
Criteria::expr()->contains('myField', 's_m_ string');
```



 Comments   
Comment by Doctrine Bot [ 19/Oct/14 ]

A related Github Pull-Request [GH-1150] was assigned:
https://github.com/doctrine/doctrine2/pull/1150

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1150] was labeled:
https://github.com/doctrine/doctrine2/pull/1150





[DDC-3314] Error with AttributeOverride when upgrading schema Created: 19/Sep/14  Updated: 23/Sep/14

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

Type: Bug Priority: Major
Reporter: JB Blanchon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm


 Description   

I want to override an attribute from FOSuserBundle:User class with annotations.

My class extends BaseUser

SiteCustomer.php
class SiteCustomer extends BaseUser

My use statement is like this

SiteCustomer.php
use FOS\UserBundle\Model\User as BaseUser;

When I put the annotations on my entity

SiteCustomer.php
 /*
 * @ORM\AttributeOverrides({
 *     @ORM\AttributeOverride(name="emailCanonical",
 *         column=@ORM\Column(
 *             name="email_canonical",
 *             type="string",
 *             length=255,
 *             unique=false
 *         )
 *     )
 * })
 */

I get this error message :


MappingException: Invalid field override named 'emailCanonical' for class SiteCustomer.

I got the same error message, for usernameCanonical.
I need to override this field in order to remove the uniqness of the field
I use Doctrine v2.4.4 what is wrong with my annotation ? Why do I get this error when trying to upgrade my schema

Thank you



 Comments   
Comment by Marco Pivetta [ 22/Sep/14 ]

Did you try reaching where the exception is thrown? It typically says more about the specific failure.

Comment by JB Blanchon [ 23/Sep/14 ]
Stack Trace 1
  */
    public static function invalidOverrideFieldName($className, $fieldName)
    {
        return new self("Invalid field override named '$fieldName' for class '$className'.");
    }
    /**
[1] Doctrine\ORM\Mapping\MappingException: Invalid field override named 'emailCanonical' for class 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer'.
    at n/a
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php line 129

    at Doctrine\ORM\Mapping\MappingException::invalidOverrideFieldName('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', 'emailCanonical')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 2032

    at Doctrine\ORM\Mapping\ClassMetadataInfo->setAttributeOverride('emailCanonical', array('fieldName' => 'emailCanonical', 'type' => 'string', 'scale' => '0', 'length' => '255', 'unique' => false, 'nullable' => false, 'precision' => '0', 'columnName' => 'email_canonical'))
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php line 415

    at Doctrine\ORM\Mapping\Driver\AnnotationDriver->loadMetadataForClass('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', object(ClassMetadata))
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/Driver/MappingDriverChain.php line 103

    at Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain->loadMetadataForClass('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', object(ClassMetadata))
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php line 117

    at Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata(object(ClassMetadata), object(ClassMetadata), true, array('Ylly\CrmBundle\Entity\User'))
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php line 318

    at Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php line 211

    at Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 295

    at Doctrine\ORM\EntityManager->getClassMetadata('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php line 67

    at Doctrine\ORM\Repository\DefaultRepositoryFactory->createRepository(object(EntityManager), 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php line 50

    at Doctrine\ORM\Repository\DefaultRepositoryFactory->getRepository(object(EntityManager), 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 759

    at Doctrine\ORM\EntityManager->getRepository('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/src/Ylly/CmsBundle/Controller/CmsBaseController.php line 93

    at Ylly\CmsBundle\Controller\CmsBaseController->getRepo('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/src/Ylly/Extension/SiteCustomerBundle/Controller/AdminController.php line 79

    at Ylly\Extension\SiteCustomerBundle\Controller\AdminController->getSiteCustomerRepo()
        in /home/jaybe/www/yProx/src/Ylly/Extension/SiteCustomerBundle/Controller/AdminController.php line 15

    at Ylly\Extension\SiteCustomerBundle\Controller\AdminController->indexAction()
        in  line 

    at call_user_func_array(array(object(AdminController), 'indexAction'), array())
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2952

    at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), '1')
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2924

    at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), '1', true)
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 3063

    at Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(object(Request), '1', true)
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2331

    at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
        in /home/jaybe/www/yProx/web/admin_dev.php line 14

Here is the stack trace of my error.
If this is not what you need, tell me what do you want and how to get it.
Thank you.





[DDC-3313] [GH-1139] Single entity flush Created: 18/Sep/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of goetas:

Url: https://github.com/doctrine/doctrine2/pull/1139

Message:

The current `flush` behavior seems to be inconsistent or not well documented.



 Comments   
Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1139] was labeled:
https://github.com/doctrine/doctrine2/pull/1139

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1139] was labeled:
https://github.com/doctrine/doctrine2/pull/1139





[DDC-3303] @ORM\Embedded does not work with extending classes Created: 10/Sep/14  Updated: 10/Sep/14

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

Type: Bug Priority: Major
Reporter: TheBelgarion Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux, Symfony 2.5 ORM 2.5.*@dev
doctrine/annotations = "v1.2.0",



 Description   

I update my symfony 2.5 with ORM 2.5. to try out the Embedded function.
I currently does not work correctly with extending class

/**
 * @ORM\Entity
 * @ORM\Table(name="A", uniqueConstraints={@UniqueConstraint(name="id", columns={"id"})})
 */
class A extends B {}
abstract class Item {

    /**
     * @var $bonus
     * @ORM\Embedded(class="Bonus")
     *
     */
    private $bonus;
}

it only works if i put the definition of the Embedded properties directly in class A ( but it works with all normal properties defined in the Abstract )






[DDC-3298] Persisting one to one not nullable relational entity Created: 08/Sep/14  Updated: 30/Mar/15

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

Type: Bug Priority: Major
Reporter: Bil Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: onetoone, persist
Environment:

Use with Symfony 2.5



 Description   

When having a not nullable onetoone unidirectional relation and trying to persist the parent entityn sql throws this exception : SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'deliveryMode_id' cannot be null.

Scheme is Shop has a deliveryMode :

class Shop{

...

/**

  • @ORM\OneToOne(targetEntity="acme\Bundle\DeliveryBundle\Entity\DeliveryMode", cascade= {"all"}

    , orphanRemoval=true)

  • @ORM\JoinColumn(nullable=false)
  • @Assert\Valid
    */
    private $deliveryMode;
    ...
    }

When I do a :

$shop=new Shop();
$deliveryMode=new DeliveryMode();
$shop->setDeliveryMode($deliveryMode);
...
$entityManager->persist($shop);
$entityManager->flush();

Then, above exception is thrown

BUT: When I put in on a doctrine transaction, it works perfectly, and it also works when I remove the "not nullable" constraint, deliveryMode is perfectly persisted.

It seems to me there a bug with the order of executing the inserts, the deliveryMode should be inserted, then the shop, I think that is not the case



 Comments   
Comment by webDEVILopers [ 27/Mar/15 ]

Same problem here with the following annotations:

class Bundle
{
    /**
     * @ORM\OneToOne(targetEntity="ParttypeStateNokBlocked", mappedBy="bundle", cascade={"persist"})
     */
    public $parttypeStateNokBlocked;

    /**
     * @param field_type $parttypeStateNokBlocked
     */
    public function setParttypeStateNokBlocked($parttypeStateNokBlocked) {
        $this->parttypeStateNokBlocked = $parttypeStateNokBlocked;
    }
}

class ParttypeStateNokBlocked
{
    /**
     * @ORM\OneToOne(targetEntity="Bundle", inversedBy="parttypeStateNokBlocked")
     * @ORM\JoinColumn(name="bundle_id", referencedColumnName="id")
     */
    public $bundle;

    public function setBundle(\Plusquam\Bundle\ContractBundle\Entity\Bundle $bundle = null)
    {echo "setting bundle";exit;
        $this->bundle = $bundle;

        return $this;
    }
}

Error: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'bundle_id' cannot be null

The setBundle method is not called. I tested the SQL Query for inserting the bundle and it works fine.

Comment by Patrick Laxton [ 30/Mar/15 ]

I guess I'm stupid to ask, but isn't your foreign key not nullable, which you cannot set because you don't have any key right now?
Could you mysqldump your database structure? (Or pgdump, or whatever DBS you're using)

Comment by webDEVILopers [ 30/Mar/15 ]

Here is my setup causing the error in 2.4.7 and 2.5.0-DEV:
https://gist.github.com/webdevilopers/a8b39361d65b7d9d5ca4





[DDC-3297] Refreshing and locking entities ignores deleted records Created: 07/Sep/14  Updated: 07/Sep/14

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

Type: Bug Priority: Major
Reporter: Glen Ainscow Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If you refresh or lock an entity that has been deleted elsewhere, no exception is thrown, so it appears as if the record still exists.

Example:

    $blogId = 1;

    $em = (get em from somewhere);

    $blog = $em->find('App_Model_Blog', $blogId);

    var_dump($blog->getTitle());

    // This could be part of a separate request or transaction.
    $em->getConnection()->exec(sprintf('DELETE FROM blogs WHERE id = %d', $blogId));

    $stmt = $em->getConnection()->query(sprintf('SELECT * FROM blogs b WHERE b.id = %d', $blogId));

    var_dump($stmt->rowCount() === 0 ? 'DELETED' : 'NOT DELETED');

    //$em->beginTransaction();

    //$em->lock($blog, LockMode::PESSIMISTIC_WRITE);

    //$em->commit();

    $em->refresh($blog);

    var_dump($blog->getTitle());





[DDC-3296] JoinColumns seems to only populate one JoinColumn Created: 04/Sep/14  Updated: 04/Sep/14

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

Type: Bug Priority: Major
Reporter: Daniel Platt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

Symfony 2.3.19



 Description   

I have two entities that are linked via two properties (trackingClickId and trackingSiteId).

However it seems to miss the second JoinColumn.

[Mapping] FAIL - The entity-class '...\Entity\SaleData' mapping is invalid:

  • The join columns of the association 'click' have to match to ALL identifier columns of the target entity '..\Entity\SaleData', however 'tracking_site_id' are missing.
TrackingData.php
class TrackingData
{

    /**
     * @ORM\Column(name="tracking_click_id", type="integer")
     * @ORM\Id
     */
    private $trackingClickId;

    /**
     * @ORM\Column(name="tracking_site_id", type="integer")
     * @ORM\Id
     * @Assert\NotBlank
     */
    private $trackingSiteId;

    /**
     * @ORM\OneToMany(targetEntity="SaleData", mappedBy="click")
     * @ORM\JoinColumns=({
     *      @ORM\JoinColumn(name="tracking_click_id", referencedColumnName="tracking_click_id"),
     *      @ORM\JoinColumn(name="tracking_site_id", referencedColumnName="tracking_site_id"), 
     * })
     */
    private $sales;
    
}
SaleData.php
class SaleData
{

    /**
     * @ORM\Column(name="tracking_site_id", type="integer")
     * @ORM\Id
     * @Assert\NotBlank
     */
    private $trackingSiteId;

    /**
     * @ORM\Column(name="tracking_click_id", type="integer")
     * @ORM\Id
     * @Assert\NotBlank
     */
    private $trackingClickId;

    /**
     * @ORM\ManyToOne(targetEntity="TrackingData", inversedBy="sales")
     * @ORM\JoinColumns=({
     *      @ORM\JoinColumn(name="tracking_click_id", referencedColumnName="tracking_click_id"),
     *      @ORM\JoinColumn(name="tracking_site_id", referencedColumnName="tracking_site_id")
     * })
     */
    private $click;
}

I have been poking around in Doctrine\ORM\Tools\SchemaValidator (L:215).

var_dump($identifierColumns, $assoc['joinColumns']);

array(2) {
  [0] =>
  string(17) "tracking_click_id"
  [1] =>
  string(16) "tracking_site_id"
}
array(1) {
  [0] =>
  array(6) {
    'name' =>
    string(17) "tracking_click_id"
    'unique' =>
    bool(false)
    'nullable' =>
    bool(true)
    'onDelete' =>
    NULL
    'columnDefinition' =>
    NULL
    'referencedColumnName' =>
    string(17) "tracking_click_id"
  }
}





[DDC-3291] Cannot use eq expression for comparison of DateTime Created: 01/Sep/14  Updated: 02/Sep/14

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

Type: Bug Priority: Major
Reporter: Przemyslaw Wrobel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When I use return ArrayCollection::matching() with criteria defined with eq expression like that:

Criteria::create()->where(Criteria::expr()->eq('day', $day))

I get no results since equality operator uses === comparison which will almost always return false for objects. The only way I found to get around this is to use in operator instead

Criteria::create()->where(Criteria::expr()->in('day', array($day)))





[DDC-3284] Yaml mapping. Comment on table and realtion Created: 29/Aug/14  Updated: 12/Dec/14

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

Type: Documentation Priority: Major
Reporter: Vladimir Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Windows, XAMPP, PHP5.3, ZF2, Doctrine-ORM



 Description   

Is there any way to comment my tables and table relations with yml schema?
I can comment plain field like this

        prediction:
            type: text
            nullable: true
            length: null
            fixed: false
            options:                
                comment: 'program prediction'

But for relation:

        project:
            targetEntity: File\Entity\File
            cascade: {  }
            mappedBy: null
            inversedBy: null
            joinColumns:
                project:
                    referencedColumnName: id
            orphanRemoval: false
            options:                
                comment: 'File with project data'

Or for whole table:

Program\Entity\Program:
    type: entity
    table: program
    options:
        comment: 'State program table'

It doesn't work at all. When I perform migrations those comments are totally ignored. And I can't find any documentation for yml mapping table commenting



 Comments   
Comment by Steve Müller [ 29/Aug/14 ]

Commenting tables is a vendor specific feature and therefore not all database vendors support it. I think currently it is only possible to comment tables via mapping for MySQL. The mapping you provided for commenting tables should work however. See here: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/Driver/YamlDriver.php#L247-L249
I'm not quite sure what you mean by commenting relations. Where would you expect Doctrine to add a comment to?

Comment by Vladimir [ 29/Aug/14 ]

I mean commenting a column that is a foreign key. Like 'project' column above that is a link to Files table and entity.

Comment by Steve Müller [ 01/Sep/14 ]

Unfortunately commenting columns part of an association mapping is not possible in ORM at the moment.

Comment by Martijn Zijlstra [ 09/Dec/14 ]

I tried doing this with annotations by adding a column annotation to the relation, but this effectively removed the relation alltogether. So no workaround yet.

Comment by Steve Müller [ 12/Dec/14 ]

Commenting foreign key columns is simply not supported yet via ORM mapping.





[DDC-3282] Pagination class CountOutputWalker has poor performance with MySQL Created: 28/Aug/14  Updated: 28/Aug/14

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

Type: Improvement Priority: Major
Reporter: Frédéric Rocheron Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

GNU/Linux CentOS 6.5, Php 5.4.32, MySQL 5.5.39, Symfony 2.5.3



 Description   

When the CountOutputWalker is used for pagination, it creates a count query of this type :

    SELECT %s AS dctrn_count
    FROM (
        SELECT DISTINCT "here are the identifiers from the original query"
        FROM (
            "here is the original query"
        ) dctrn_result
    ) dctrn_table

The problem is that the original query inside the count query is executed without limiting the results number each time the pagination has to count the total number of rows. And when the total number of rows returned by the original query is large and/or with big selected rows, it can hurt badly the performance, even kill the server.
Maybe I don't understand something but in my opinion this count query does exactly what we try to avoid with pagination : load all data at one time !
So I don't understand why things are done this way. Again, I'm not a db specialist so I'm almost sure I'm missing something.

But the thing is I've met these performance issues with big select queries on a medium amount of rows (~35000) on MySQL (using knp-components Pager).
The ugly solution I found was to use the CountWalker instead of the CountOutputWalker except when the query has a "HAVING" clause. That was because the CountWalker produce a better count query for performance but cannot handle well "HAVING" clauses (as far as I know).
Finally I think the solution is to modify the CountWalker so it can take care of more complex queries and/or improve the CountOutputWalker to preserve performance.

Here are some discussions related to this problem :
Removed use of CountOutputWalker
Count Performance of DoctrineORMAdapter COUNT query and large record sets
Doctrine ORM pagination improvements

Thanks a lot for your time



 Comments   
Comment by Christophe Coevoet [ 28/Aug/14 ]

Well, the issue is that the CountWalker cannot count stuff using a GROUP BY or HAVING clause by design. It is simply impossible to write the given SQL without ending up on what the CountOutputWalker is doing,(maybe a bit simpler in some cases thanks to a complete knowledge of what the query is doing, but not much and not in a general case).

The solution is indeed to tell the Paginator not to use the output walker when you know it is not necessary. This is precisely why there are 2 implementations of the pagination with a boolean flag to switch between them

Comment by Christophe Coevoet [ 28/Aug/14 ]

And the output walker actually perform better than the tree walker in many platforms according to Benjamin Eberlei (not MySQL though), which is why it is hard to choose the best walker for queries being supported by both of them (a project can do it better than the core, as it knows which platform it uses)

Comment by Frédéric Rocheron [ 28/Aug/14 ]

Thank you for your very clear explanations !
I assumed I was missing something but I did not think it was just impossible to solve this problem "automatically" . That's a bit annoying but ok.
The solution for MySQL seems to use the CountWalker for queries without GROUP BY or HAVING clause and CountOutputWalker for other queries. A better solution would be to create a custom hand-made count query for queries with GROUP BY or HAVING clause. This is possible in "knp-components Pager" and, I suppose, in the other pagination libraries using doctrine-orm Tools.

But as "knp-components Pager" does not use the "doctrine-orm Tools Paginator" but only the walkers from doctrine-orm, it doesn't have the boolean flag to switch between CountWalker and CountOutputWalker. The CountOutputWalker is used if doctrine-orm version is 2.3.0 or more and that's it.
I've made a pull request to activate the use of CountWalker for queries without HAVING clause but I think now it's a bad idea. The solution should be to add the same boolean flag to the "knp-components Pager" library. I will talk to them about that.

Thanks again for your time

Comment by Christophe Coevoet [ 28/Aug/14 ]

See https://github.com/KnpLabs/knp-components/issues/114

Comment by Frédéric Rocheron [ 28/Aug/14 ]

great





[DDC-3280] ObjectHydrator does not support iteration over non-distinct result sets Created: 27/Aug/14  Updated: 27/Aug/14

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

Type: Bug Priority: Major
Reporter: Timothy Michael Bradley Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

ObjectHydrator attempts to retrieve previously created objects during iteration (i.e. Query::iterate()). It needs to create an entirely new object because the previous one is not available.

This may also be a performance/scalability issue, and it may be a matter of setting default behavior.

Note that calling Query::useResultCache(false) does not fix this issue.

This part of the code causes a warning because of this issue.

// Update result pointer
$index = $this->identifierMap[$dqlAlias][$id[$dqlAlias]];
$this->resultPointers[$dqlAlias] = $result[$index];
$resultKey = $index

Here is the warning:

Notice: Undefined offset: 0 in [basedir]/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php on line 519





[DDC-3277] Yaml convert-mapping bug Created: 27/Aug/14  Updated: 01/Sep/14

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

Type: Bug Priority: Major
Reporter: Vladimir Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm, yaml, yml
Environment:

Windows+XAMPP, PHP5.3, Zend Framework 2



 Description   

I use yaml mapping in my project for better migration management. For example, I use

    orm:convert-mapping yml ./yml --from-database --namespace="User\Entity\\" --filter="User\Entity\User"

To make yml entites for my User module. In my yml I have smth like this:

      password:
            type: string
            nullable: false
            length: 256
            fixed: false
            comment: ''
        email:
            type: string
            nullable: false
            length: 64
            fixed: false
            comment: ''
        status:
            type: smallint
            nullable: false
            unsigned: false
            comment: ''

I can write a comment to column

         status:
                type: smallint
                nullable: true
                unsigned: false
                comment: '%some comment%'
                column: status

And when I perform migration comment disappears. Here https://github.com/doctrine/migrations/issues/184 I was adviced to use such construction:

    status:
        type: smallint
        nullable: true
        column: status
        options:
            unsigned: false
            comment: '%some comment%'

And It works! But convert-mapping generates wrong code. Does anyone know any way to generate a correct one with convert-mapping?



 Comments   
Comment by Marco Pivetta [ 28/Aug/14 ]

Seems like Christophe Coevoet started working on this: https://github.com/doctrine/doctrine2/pull/1123

Comment by Vladimir [ 29/Aug/14 ]

Thank you very much! Will with feature be available with update through composer?

Comment by Doctrine Bot [ 30/Aug/14 ]

A related Github Pull-Request [GH-1123] was assigned:
https://github.com/doctrine/doctrine2/pull/1123

Comment by Doctrine Bot [ 30/Aug/14 ]

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

Comment by Steve Müller [ 01/Sep/14 ]

Vladimir there is no release date scheduled for 2.5 yet. If you want to use the patch you will have to use "dev-master" version in your composer.json





[DDC-3267] [GH-1117] QueryBuilder - replace deprecated getAlias() by getAliases()[0] Created: 22/Aug/14  Updated: 22/Aug/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of TomasVotruba:

Url: https://github.com/doctrine/doctrine2/pull/1117

Message:






[DDC-3259] Second level & UnitOfWork inconsistencies Created: 19/Aug/14  Updated: 16/Feb/15

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

Type: Improvement Priority: Major
Reporter: Asmir Mustafic Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: second-level-cache


 Description   

Hi!

I have a lot of entities with entity associations as keys and I'm trying to use second level cache.

Looking at the method: UnitOfWork::createEntity($className, array $data, &$hints = array())

  • $className: contains the class name
  • $data: contains the raw data (the row coming from the database)

Enabling the second level cache, DefaultQueryCache::get calls the createEntity method passing a $data that contains object entities and some raw data (https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/DefaultQueryCache.php#L155).

I think that DefaultQueryCache should not introduce a variant of $data and should create a compatible version of $data.



 Comments   
Comment by Marco Pivetta [ 19/Aug/14 ]

Asmir Mustafic do you have any example of where this may be happening?

Comment by Asmir Mustafic [ 19/Aug/14 ]

https://github.com/doctrine/doctrine2/pull/1114

This is the same branch of https://github.com/doctrine/doctrine2/pull/1113, plus this commit (https://github.com/goetas/doctrine2/commit/bfbbb9123fd28f7fa053b76895eaa77e00095aa6) that simply involves the second level cache too.
Travis should fail soon.

Comment by Doctrine Bot [ 19/Aug/14 ]

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

Comment by Asmir Mustafic [ 19/Aug/14 ]

Here the failure https://travis-ci.org/doctrine/doctrine2/jobs/32972996#L402

Comment by Doctrine Bot [ 22/Oct/14 ]

A related Github Pull-Request [GH-1113] was assigned:
https://github.com/doctrine/doctrine2/pull/1113

Comment by Doctrine Bot [ 18/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1113] was labeled:
https://github.com/doctrine/doctrine2/pull/1113

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1113] was labeled:
https://github.com/doctrine/doctrine2/pull/1113

Comment by Doctrine Bot [ 16/Feb/15 ]

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





[DDC-3251] Segmentation fault in ClassMetadataInfo.php Created: 12/Aug/14  Updated: 20/Oct/14

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

Type: Bug Priority: Major
Reporter: Kshitij Parajuli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux dev1 3.9.9-302.fc19.x86_64 #1 SMP Sat Jul 6 13:41:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Fedora release 19 (Schrödinger’s Cat)

PHP 5.5.14 (cli) (built: Jul 16 2014 11:41:07)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

Doctrine Command Line Interface version 2.3.6-DEV



 Description   

I'm seeing a segfault when doing a EntityManager->merge(). Specifically, when on this line in ClassmetadataInfo.php. Details below.

$value = $this->reflFields[$this->identifier[0]]->getValue($entity);

/var/log/messages

Aug 12 08:39:01 dev1 kernel: [62152.629221] php[3539]: segfault at f434172bd1 ip 00007ff432c3aae9 sp 00007fffa060b1b0 error 4 in php[7ff4329e7000+38c000]

strace

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xc4f1053d11} ---
+++ killed by SIGSEGV ++

gdb backtrace:

(gdb) bt
#0  0x00007f8c8f5ceae9 in zend_std_read_property ()
#1  0x00007f8c8f5b61d7 in zend_read_property ()
#2  0x00007f8c8f4ab66e in zim_reflection_property_getValue ()
#3  0x00007f8c8f59a4ab in dtrace_execute_internal ()
#4  0x00007f8c8abb9a46 in xdebug_execute_internal () from /usr/lib64/php/modules/xdebug.so
#5  0x00007f8c8f65a895 in zend_do_fcall_common_helper_SPEC ()
#6  0x00007f8c8f5d45c8 in execute_ex ()
#7  0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#8  0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#9  0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#10 0x00007f8c8f5d45c8 in execute_ex ()
#11 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#12 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#13 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#14 0x00007f8c8f5d45c8 in execute_ex ()
#15 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#16 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#17 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#18 0x00007f8c8f5d45c8 in execute_ex ()
#19 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#20 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#21 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#22 0x00007f8c8f5d45c8 in execute_ex ()
#23 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#24 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#25 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#26 0x00007f8c8f5d45c8 in execute_ex ()
#27 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#28 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#29 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#30 0x00007f8c8f5d45c8 in execute_ex ()
#31 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#32 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#33 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#34 0x00007f8c8f5d45c8 in execute_ex ()
#35 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#36 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#37 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#38 0x00007f8c8f5d45c8 in execute_ex ()
#39 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#40 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#41 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#42 0x00007f8c8f5d45c8 in execute_ex ()
#43 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#44 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#45 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#46 0x00007f8c8f5d45c8 in execute_ex ()
#47 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#48 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#49 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#50 0x00007f8c8f5d45c8 in execute_ex ()
#51 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#52 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
---Type <return> to continue, or q <return> to quit---
#53 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#54 0x00007f8c8f5d45c8 in execute_ex ()
#55 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#56 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#57 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#58 0x00007f8c8f5d45c8 in execute_ex ()
#59 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#60 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#61 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#62 0x00007f8c8f5d45c8 in execute_ex ()
#63 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#64 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#65 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#66 0x00007f8c8f5d45c8 in execute_ex ()
#67 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#68 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#69 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#70 0x00007f8c8f5d45c8 in execute_ex ()
#71 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#72 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#73 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#74 0x00007f8c8f5d45c8 in execute_ex ()
#75 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#76 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#77 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#78 0x00007f8c8f5d45c8 in execute_ex ()
#79 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#80 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#81 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#82 0x00007f8c8f5d45c8 in execute_ex ()
#83 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#84 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#85 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#86 0x00007f8c8f5d45c8 in execute_ex ()
#87 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#88 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#89 0x00007f8c8f659852 in ZEND_INCLUDE_OR_EVAL_SPEC_VAR_HANDLER ()
#90 0x00007f8c8f5d45c8 in execute_ex ()
#91 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#92 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#93 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#94 0x00007f8c8f5d45c8 in execute_ex ()
#95 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#96 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#97 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#98 0x00007f8c8f5d45c8 in execute_ex ()
#99 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#100 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#101 0x00007f8c8f65aee0 in zend_do_fcall_common_helper_SPEC ()
#102 0x00007f8c8f5d45c8 in execute_ex ()
#103 0x00007f8c8f59a3a9 in dtrace_execute_ex ()
#104 0x00007f8c8abb8fcc in xdebug_execute_ex () from /usr/lib64/php/modules/xdebug.so
#105 0x00007f8c8f5abed0 in zend_execute_scripts ()
---Type <return> to continue, or q <return> to quit---
#106 0x00007f8c8f54bc65 in php_execute_script ()
#107 0x00007f8c8f65c8a8 in do_cli ()
#108 0x00007f8c8f436420 in main ()

xdebug trace:

   54.4457   16731856                                           -> Tekelec\DVAT\Service\TagService->createTag() /home/vagrant/dvat/library/Tekelec/DVAT/Service/TagService.php:51
   54.4457   16731856                                             -> Doctrine\ORM\EntityManager->merge() /home/vagrant/dvat/library/Tekelec/DVAT/Service/TagService.php:28
   54.4457   16731904                                               -> is_object() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:632
   54.4457   16731856                                               -> Doctrine\ORM\EntityManager->errorIfClosed() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:636
   54.4457   16731856                                               -> Doctrine\ORM\UnitOfWork->merge() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:638
   54.4458   16731992                                                 -> Doctrine\ORM\UnitOfWork->doMerge() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1701
   54.4458   16732136                                                   -> spl_object_hash() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1744
   54.4458   16732448                                                   -> get_class() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1752
   54.4458   16732496                                                   -> Doctrine\ORM\EntityManager->getClassMetadata() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1752
   54.4458   16732496                                                     -> Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:268
   54.4458   16732448                                                   -> Doctrine\ORM\UnitOfWork->getEntityState() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1760
   54.4458   16732496                                                     -> spl_object_hash() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1367
   54.4458   16732400                                                   -> Doctrine\ORM\Mapping\ClassMetadataInfo->getIdentifierValues() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:1766
   54.4458   16732448                                                     -> ReflectionProperty->getValue() /home/vagrant/dvat/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:672

The reproducing steps are complicated and require propriety code, but this happens most of the time (80+ percent).

Here is the php bug for this: https://bugs.php.net/bug.php?id=67828



 Comments   
Comment by Marco Pivetta [ 12/Aug/14 ]

Did you try clearing your opcode caches? Is this reproducible in insulated environment?

Comment by Kshitij Parajuli [ 12/Aug/14 ]

Yes, I tried clearing the opcode caches (and clearing proxies and restarting the server). This was also reproducible in multiple servers (one production and one development).

It is not yet reproducible in isolated environment, but I am looking at it. Will update the ticket if I find easy reproducing steps.

Comment by Benjamin Eberlei [ 12/Aug/14 ]

Please try without xdebug, this is enabled according to stacktrace.

Comment by Harold Herrera [ 20/Oct/14 ]

I would like get the Doctrine2-orm, but I get an error in the doctrineORM-2.3.6....tar.gz, could you help me please?.

Comment by Marco Pivetta [ 20/Oct/14 ]

Harold Herrera that is a question unrelated with the issue here.





[DDC-3248] PreUpdateEventArgs::setNewValue() does not update Entity state Created: 11/Aug/14  Updated: 11/Aug/14

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

Type: Bug Priority: Major
Reporter: Lukas Kahwe Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

see https://github.com/doctrine/doctrine2/commit/bc6714c2c8d015cb2e3ae198fcb1b98b3bbe35e0#commitcomment-7329820

as well as https://github.com/doctrine/phpcr-odm/pull/539#discussion_r16027731






[DDC-3241] object type fails to save serialized class to postgresql Created: 05/Aug/14  Updated: 05/Aug/14

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

Type: Bug Priority: Major
Reporter: Reno Reckling Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DBAL-964 [GH-653] Update docs to include warni... Resolved

 Description   

Doctrine 2 fails to properly store data from serialize() into postgresql.
This happens because the postgresql pdo driver truncates text on NULL bytes when escaping values. This leads to truncated serialized objects being inserted into the database.

A ugly but working workaround for us is to call json_encode(serialize()) when saving to the database and unserialize(json_decode()) when reading the value back because json_encode properly serializes the NULL bytes of the serialize() output to readable text.

This is pretty ugly though and it would help if doctrine would provide a minimal encoding/decoding function for postgresql that converts all NULL bytes to something else to not break the object type on postgresql.



 Comments   
Comment by Marco Pivetta [ 05/Aug/14 ]

I'm fairly sure that we don't want to invent our own serialization format. Instead, base64_encode could work.

Due to BC compat, we can't introduce it for 2.x, so it would have to be a completely new type.

Comment by Reno Reckling [ 05/Aug/14 ]

Agreed, we'll just go with base64_encode for now.
Maybe someone should update the documentation that using the object type on postgresql is not working as well as that using binary strings containing a NULL byte in any varchar/text column on postgresql is not working either.

Comment by Marco Pivetta [ 05/Aug/14 ]

Reno Reckling just open a pull request against the doctrine/doctrine2 repository

Comment by Reno Reckling [ 05/Aug/14 ]

Marco Pivetta Here you go: https://github.com/doctrine/dbal/pull/653
http://www.doctrine-project.org/jira/browse/DBAL-964

Thanks for the reply.

Comment by Doctrine Bot [ 05/Aug/14 ]

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

Comment by Marco Pivetta [ 05/Aug/14 ]

Merged DBAL-964, but the issue persists here.





[DDC-3238] GROUP BY does not work as expected in MS SQL Server Created: 31/Jul/14  Updated: 18/Aug/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.4.1, 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Spencer Weiss Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

MS SQL Server 2012



 Description   

Running the query taken from this page: <http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html>

$query = $em->createQuery('SELECT u, count(g.id) FROM FundAsset u JOIN u.locations g GROUP BY u.id');

I receive the following error from MS SQL Server:

SQLSTATE[42000]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Column 'fund_assets.active' is invalid in the select list because it is not contained in either an aggregate function or the GROUP BY clause.

It appears that Doctrine's GROUP BY clause does not work correctly in Microsoft SQL Server.



 Comments   
Comment by Marco Pivetta [ 18/Aug/14 ]

Needs a failing test case.





[DDC-3236] Quote table names Created: 31/Jul/14  Updated: 31/Jul/14

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

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


 Description   

Different dbs have different reserved words. I started my project with mysql where i couldnt name my table as "order". After changing to postgre it turned out that "user" is reserved. Although

ALTER TABLE "member" RENAME TO "user";

works.

I know i could use prefixes in yml eg

Com\ApiBundle\Entity\User:
    type: entity
    table: prefix_user

but
-i build my db
-automatically generate my yaml files from it
-then i generate the entities

If i have prefixed table names my entities will have them too.
Besides doctrine is a layer on top of different dbs, it would be nice not to worry about reserved words when i naming my tables.

What is your opinion on this feature.



 Comments   
Comment by Steve Müller [ 31/Jul/14 ]

Benjamin Horn this looks more like a DBAL related issue. Can you please give more details how the broken SQL is created by you? Also please provide information about which DBAL and/or ORM version you are referring to as we have fixed a lot of quotation problems with DDL statements in current DBAL master over the last few months. So please also try using the latest master and see if you can reproduce the issue.
If the issue still persists it would be helpfult to know which database vendor and which version you are using (as different vendors and versions have different reserved keywords).





[DDC-3229] Error when running the tests Created: 24/Jul/14  Updated: 24/Jul/14

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

Type: Bug Priority: Major
Reporter: Jeroen De Dauw Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Fresh clone at 089cca636e0e44a70dd9167b7d813762ea80daca.

php -v
PHP 5.5.9-1ubuntu4.3 (cli) (built: Jul 7 2014 16:36:58)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

j@wd42:~/workspace/doctrine2$ phpunit
PHPUnit 4.3-ge243de0 by Sebastian Bergmann.

Configuration read from /home/j/workspace/doctrine2/phpunit.xml.dist

............................................................. 61 / 2500 ( 2%)
........S.................................................... 122 / 2500 ( 4%)
............................................................. 183 / 2500 ( 7%)
............................................................. 244 / 2500 ( 9%)
............................................................. 305 / 2500 ( 12%)
............................................................. 366 / 2500 ( 14%)
.........................S...SSSS.S.......................... 427 / 2500 ( 17%)
............................................................. 488 / 2500 ( 19%)
....................................................SS....... 549 / 2500 ( 21%)
............................................................. 610 / 2500 ( 24%)
............................................................. 671 / 2500 ( 26%)
............................................................. 732 / 2500 ( 29%)
............................................................. 793 / 2500 ( 31%)
........................................................S.SSS 854 / 2500 ( 34%)
SSSSSSSSS.................................................... 915 / 2500 ( 36%)
..........................................SS................. 976 / 2500 ( 39%)
.............S...S...........S..............................S 1037 / 2500 ( 41%)
........PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65552 bytes) in /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/ProxyGenerator.php on line 280
PHP Stack trace:
PHP 1.

{main}

() /usr/bin/phpunit.phar:0
PHP 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit.phar:586
PHP 3. PHPUnit_TextUI_Command->run() phar:///usr/bin/phpunit.phar/phpunit/TextUI/Command.php:132
PHP 4. PHPUnit_TextUI_TestRunner->doRun() phar:///usr/bin/phpunit.phar/phpunit/TextUI/Command.php:179
PHP 5. PHPUnit_Framework_TestSuite->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:423
PHP 6. PHPUnit_Framework_TestSuite->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestSuite.php:715
PHP 7. PHPUnit_Framework_TestCase->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestSuite.php:715
PHP 8. PHPUnit_Framework_TestResult->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:672
PHP 9. PHPUnit_Framework_TestCase->runBare() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestResult.php:654
PHP 10. PHPUnit_Framework_TestCase->runTest() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:734
PHP 11. ReflectionMethod->invokeArgs() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:859
PHP 12. Doctrine\Tests\ORM\Functional\Ticket\DDC1436Test->testIdentityMap() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:859
PHP 13. Doctrine\ORM\AbstractQuery->getOneOrNullResult() /home/j/workspace/doctrine2/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC1436Test.php:42
PHP 14. Doctrine\ORM\AbstractQuery->execute() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:766
PHP 15. Doctrine\ORM\AbstractQuery->executeIgnoreQueryCache() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:923
PHP 16. Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:977
PHP 17. Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateAllData() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php:147
PHP 18. Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateRowData() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:160
PHP 19. Doctrine\ORM\Internal\Hydration\ObjectHydrator->getEntity() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:432
PHP 20. Doctrine\ORM\UnitOfWork->createEntity() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:268
PHP 21. Doctrine\Common\Proxy\AbstractProxyFactory->getProxy() /home/j/workspace/doctrine2/lib/Doctrine/ORM/UnitOfWork.php:2714
PHP 22. Doctrine\Common\Proxy\AbstractProxyFactory->getProxyDefinition() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:119
PHP 23. Doctrine\Common\Proxy\ProxyGenerator->generateProxyClass() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:218
PHP 24. strtr() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/ProxyGenerator.php:280






[DDC-3228] ORM\Tools\Export\Driver\PhpExporter.php does not properly export manyToOne associations Created: 24/Jul/14  Updated: 24/Jul/14

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

Type: Bug Priority: Major
Reporter: Dan V Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm, schematool
Environment:

PHP 5.5.9-1ubuntu4 (cli)



 Description   

PhpExporter.php fails to check the association for manyToOne/oneToOne and exports all associations as oneToOne.

See https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/PhpExporter.php#L116 where oneToOne is hardcoded if the bitmask matches either manyToOne or oneToOne.

As opposed to YamlExporter.php:

https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/YamlExporter.php#L165

Which does roughly the same thing, but then properly sets the association type by checking the actual association on lines 186 through one 190:

https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/YamlExporter.php#L186-L190






[DDC-3224] getResult(HYDRATE_OBJECT) with joined query is returning reduced number of rows Created: 23/Jul/14  Updated: 17/Sep/14

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

Type: Bug Priority: Major
Reporter: gondo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

osx, PHP-FPM 5.5.13, nginx/1.6.0, mysql 5.6.19 Homebrew



 Description   

given that i have these 2 entities (pseodocode):

/**
 * @ORM\Table(name="entity1", options={"collate"="utf8_unicode_ci", "charset"="utf8"})
 * @ORM\Entity(repositoryClass="Entity1Repository")
 */
class Entity1 {
    /**
     * @var integer
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @var string
     * @ORM\Column(name="name", type="string")
     */
    protected $name;

    /**
     * @var Entity2[]
     * @ORM\OneToMany(targetEntity="Entity2", mappedBy="entity1")
     */
    protected $entity2;
}

/**
 * @ORM\Table(name="entity2", options={"collate"="utf8_unicode_ci", "charset"="utf8"})
 * @ORM\Entity()
 */
class Entity2 {
    /**
     * @var integer
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @var \DateTime
     * @ORM\Column(name="date", type="datetime")
     */
    protected $date;

    /**
     * @var Entity1
     * @ORM\ManyToOne(targetEntity="Entity1", inversedBy="entity2", fetch="EAGER")
     */
    protected $entity1;
}

tables and data

entity1:

id name
1 Jhon
2 Clare

entity2:

id date entity1_id
1 2011-01-01 00:00:01 1
2 2012-02-02 00:00:02 1
3 2013-03-03 00:00:03 2
4 2014-04-04 00:00:04 2

my query builder

use Doctrine\ORM\EntityRepository;

class Entity1Repository extends EntityRepository
{
    public function getData()
    {
        $qb = $this
            ->createQueryBuilder('Entity1')
            ->select('Entity1, Entity2.date')
            ->join('Entity1.entity2', 'Entity2', Join::WITH, 'Entity2.date > :date')
            ->setParameter('date', '2000-01-01 00:00:01')
        ;
        $result1 = $qb->getQuery()->getArrayResult(); // HYDRATE_ARRAY
        $result = $qb->getQuery()->getResult(); // HYDRATE_OBJECT
        
//        return $result1;
//        return $result2;
    }
}

proper result is this:

id name date
1 Jhon 2011-01-01 00:00:01
1 Jhon 2012-02-02 00:00:02
2 Clare 2013-03-03 00:00:03
2 Clare 2014-04-04 00:00:04

what is happening

$result1 = $qb->getQuery()->getArrayResult(); // HYDRATE_ARRAY

is really returning proper number of rows

BUT and here comes the BUG finally:

$result2 = $qb->getQuery()->getResult(); // HYDRATE_OBJECT

is returning just 2 rows:

id name date
1 Jhon 2011-01-01 00:00:01
2 Clare 2013-03-03 00:00:03

this is because somehow entities are made unique.

my workaround

as a workaround, what i have to do is, to exectute 2 queries. 1st to get just Entity1.ids joined with Entity2.dates by using `getArrayResult()`
and second query to get Entity1 objeces by unique ids from 1st query.
and than manualy join those results in php.



 Comments   
Comment by Marco Pivetta [ 23/Jul/14 ]

I see that you are using Join::WITH, but not providing a conditional in the example. Are you filtering a fetch-joined association?

Comment by gondo [ 23/Jul/14 ]

sorry i've tried to simplify my structure as much as it was possible, there are actually real conditions, one of them is date condition (among many others). i've updated my code

Comment by Marco Pivetta [ 23/Jul/14 ]

There are still some inconsistencies in the issue - where is that query parameter used, for example?

Comment by gondo [ 23/Jul/14 ]

im using it in EntityRepository (sorry, didnt know thats important) i ll update my code
and the whole code is in Symfony2 project (web and command line applications)

Comment by Marco Pivetta [ 23/Jul/14 ]

What I mean is that in

->setParameter('date', new \DateTime('last month'))

, parameter :date does not exist in the DQL.

Comment by gondo [ 23/Jul/14 ]

i see, sorry its part of JOIN condition, i've updated the code





[DDC-3221] Invalid binding for primary key of entity relation Created: 21/Jul/14  Updated: 21/Jul/14

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

Type: Bug Priority: Major
Reporter: Alexandr Smaga Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Hello.

We use doctrine2 ORM with doctrine/doctrine-bundle in our symfony2 based project. We developed functionality which is similar to some kind of import process.

And we have an issue that appears from time to time in different points during the import.

Issue is following:
Lets imagine we have 3 entities Account, Contact, Contact Address.
Account has many to one relation on contact and contact has one to many relation on contact address.

Our import creates all 3 entities and persist only Account, contact and address are persisted via cascade persist.
We have writer that contains following code

    public function write(array $items)
    {
        try {
            $this->entityManager->beginTransaction();
            foreach ($items as $item) {
                $this->entityManager->persist($item);
            }
            $this->entityManager->commit();
        } catch (\Exception $exception) {
            $this->entityManager->rollback();

            throw $exception;
        }
        $this->entityManager->flush();
        $this->entityManager->clear();
    }

So we clear EntityManager for each batch in order to avoid high memory consumption.
Import fails during different entities insert, but errors are very similar.
Example of error is

> [error] An exception occurred while executing 'INSERT INTO ... VALUES (?, ?, ?, ?, ?)' with params ["__start__", "2014-07-21 00:55:35", 0, null, 21]:
>
> SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`DB`.`account`, CONSTRAINT `FK_B3D57B301023C4EE` FOREIGN KEY (`contact_id`) REFERENCES `contact` (`id`) ON DELETE CASCADE)

After debugging I found that problem is in BasicEntityPersister#prepareUpdateData

$uow->getEntityIdentifier($newVal);


returns oid that is real one, but UOW contains not the same ID as in $newVal entity. It seems like spl_object_hash duplicates oid.

Any help is appreciated.
Thanks in advance.






[DDC-3220] Association mappings of embedded class not loaded into entity classMetadata Created: 21/Jul/14  Updated: 21/Jul/14

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

Type: Bug Priority: Major
Reporter: Anatolie Marinescu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

method inlineEmbeddable from Doctrine\ORM\Mapping\ClassMetadataInfo mapped only columns, but relations is omitted






[DDC-3215] wrong quotation Created: 16/Jul/14  Updated: 20/Jan/15

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

Type: Bug Priority: Major
Reporter: revrev Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: dql, orm


 Description   

when doctrine build query´s, for example when you doing

$entitity->getTest()->clear();

following queries are generated (test_id is integer in mysql):

DELETE FROM test WHERE test_id = '6'

Is this right?
For me the right query would be:

DELETE FROM test WHERE test_id = 6

as in http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html
6 will be converted to float, this can be an issue, or?

Comparisons that use floating-point numbers (or values that are converted to floating-point numbers) are approximate because such numbers are inexact. This might lead to results that appear inconsistent:

mysql> SELECT '18015376320243458' = 18015376320243458;
        -> 1
mysql> SELECT '18015376320243459' = 18015376320243459;
        -> 0

this also happens in dql sometimes, why doctrine does this not automatic right due to description in the entities?

     /**
     * @ORM\Id @ORM\Column(type="integer")
     * @ORM\GeneratedValue
     */


 Comments   
Comment by Marco Pivetta [ 16/Jul/14 ]

Could you please convert this to a failing test case? Doctrine doesn't quote integers as strings by default.

Comment by revrev [ 16/Jul/14 ]

i try to describe what i have done

i have an Entity with:

    /**
     * @ORM\ManyToMany(targetEntity="Messen", inversedBy="vertrag_messen")
     * @ORM\JoinTable(name="vertrag_messen")
     **/
    private $vertrag_messen;

    public function __construct()
    {
        $this->vertrag_messen = new \Doctrine\Common\Collections\ArrayCollection();
    }

    public function getMessen()
    {
        return $this->vertrag_messen;
    }

when i now clear the Data

$entitity->getMessen()->clear();

following query is created
DELETE FROM vertrag_messen where messe_id = '6'

Should here not set the value 6 as integer (param_int) (DELETE FROM test vertrag_messen where messe_id = 6) that mysql doesn´t have to cast the value? (http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html) or is this not an problem?

Comment by Marco Pivetta [ 16/Jul/14 ]

is messe_id in your entity an integer or a string at the moment in time when that query is being executed?

Comment by revrev [ 16/Jul/14 ]

the value comes automatic
$entitity = $em->getRepository('Base\Entities\Vertrag')>find(intval($data["id"]));

i don´t set messe_id here

Comment by Marco Pivetta [ 16/Jul/14 ]

Can you var_dump the Base\Entities\Messe instance?

Comment by revrev [ 16/Jul/14 ]

object(stdClass)#1014 (64) {
["__CLASS__"]=>
string(24) "Base\Entities\Vertrag"
["id"]=>
int(6)
[„vertrag_messen"]=>
array(1)

Unknown macro: { [0]=> string(20) "BaseEntitiesMessen" }


["erstellungsdatum"]=>
object(stdClass)#1210 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2013-09-28T00}

["zeitraumvon"]=>
NULL
["zeitraumbis"]=>
NULL
["jahr"]=>
int(2014)
["created"]=>
object(stdClass)#1178 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2013-09-28T19}

["updated"]=>
object(stdClass)#1177 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2014-07-16T17}

["uuid"]=>
string(36) "52470c58-4288-45eb-b75f-0c41c0a81437"
}

Comment by Marco Pivetta [ 17/Jul/14 ]

yeah, integer identifier there.
Could you verify if the problem also comes up with current master? I think this issue is related with another one that was fixed some months ago in 2.5.x-dev

Comment by Mathias Dietrich [ 20/Jan/15 ]

@Marco Pivetta:

I was affected by exact the same issue. Even when running git master at the beginning of last week, it was still broken.
Today I retestet. Luckily your latest commits (from beginning with: 445798ed46291f2639b3657142bd2f934d1be8a6) to the BasicEntityPersister seemed fixed it.

@revrev:
Could you please retest your example? This bug might be fixed. Thx.





[DDC-3211] Annotation @ORM\Table(name="schema.table") don't generate sql using OCI8 Created: 09/Jul/14  Updated: 12/Jul/14

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

Type: Bug Priority: Major
Reporter: Jorge Potosme Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cli, mapping, oci8, oracle, orm, symfony
Environment:

OS: Fedora 20
Web Server: Apache
DBMS: Oracle 12c
Framework: Symfony2
PHP version: 5.5.14
DBMS Driver: OCI8



 Description   

Using Symfony and "doctrine/orm": "2.4.@dev", "doctrine/doctrine-bundle": "1.3.@dev", with OCI8(Oracle Call Interface)
I have an entity
/**
* @ORM\Entity
* @ORM\Table(name="rrhh.usuario")
*/
class Usuario implements UserInterface

{ ... }

When i use de CLI (php app/console doctrine:schema:create --dump-sql) this don't show nothing, the output is empty.

If i change (name="rrhh.usuario") to (name="usuario", schema="rrhh") the CLI show the sql query but without the schema.



 Comments   
Comment by Marco Pivetta [ 09/Jul/14 ]

Duplicates this issue





[DDC-3203] "Orphan Removal" for ManyToMany and "Cascade remove" doesn't trigger "preRemove" callback on related entity Created: 01/Jul/14  Updated: 19/Dec/14

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

Type: Bug Priority: Major
Reporter: Tadej Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Latest ZendFramework2, latest ZF2 DoctrineModule and latest ZF2 DoctrineORMModule



 Description   

I'm not sure if it's me, but I couldn't get "preRemove" callback/event working when "remove" action is triggered from related entity, but it works where the entity itself (the one with "preRemove" event) is removed directly.

According to documentation:
"If an association is marked as CASCADE=REMOVE Doctrine 2 will fetch this association. If its a Single association it will pass this entity to ´EntityManager#remove()`"....and similar for multiple entities.
DOC: http://doctrine-orm.readthedocs.org/en/latest/reference/working-with-objects.html?highlight=working-with-objects%20removing-entities#removing-entities

"preRemove event is called on every entity when its passed to the EntityManager#remove()"
DOC: http://docs.doctrine-project.org/en/latest/reference/events.html#preremove

So according to documentation "preRemove" should get triggered on "cascade remove", but it doesn't get in my case. Is this normal behavior or a bug?

I'm not sure if it the problem might be in any of ZF2 modules, but I've decided to post the issue here, since I'm referring to documentation of this project.

Beside that I've also noticed that "orphan removal" doesn't work on ManyToMany, although documentation says that it's supported (on IRC they've said that it may be a bug in documentation, that it is not really yet supported...they found no code changes when documentation was changed).
DOC:
http://docs.doctrine-project.org/en/latest/reference/working-with-associations.html#orphan-removal



 Comments   
Comment by Oliver Hoff [ 19/Dec/14 ]

Orphan removal can not be supported for Many-To-Many relations, because the feature makes the assumption that the related entity is "privately owned" by the entity defining the orphan removal feature. In a Many-To-Many relation a related entity can be related to multiple entities and therefore is not privately owned by the relation defining entity.





[DDC-3200] [GH-1077] Support filter parameters in Configuration Created: 01/Jul/14  Updated: 24/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jmikola:

Url: https://github.com/doctrine/doctrine2/pull/1077

Message:

Based on work done in doctrine/mongodb-odm#908

My understanding is that this makes it easier to setup filters at boot time, instead of having to fetch them from the collection later on.

For added context, the related PR from MongoDB ODM's Symfony bundle is doctrine/DoctrineMongoDBBundle#255



 Comments   
Comment by Doctrine Bot [ 11/Nov/14 ]

A related Github Pull-Request [GH-1077] was assigned:
https://github.com/doctrine/doctrine2/pull/1077

Comment by Doctrine Bot [ 24/Jan/15 ]

A related Github Pull-Request [GH-1077] was labeled:
https://github.com/doctrine/doctrine2/pull/1077





[DDC-3197] [GH-1074] [DDC-3160] Alternate fix for DDC-2996 bug Created: 26/Jun/14  Updated: 06/Jul/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of zimmermanj42:

Url: https://github.com/doctrine/doctrine2/pull/1074

Message:

The fix implemented for DDC-2996 seems to have broken quite a bit of code outside of Doctrine (for instance, the popular DoctrineExtensions project).

I'm not too well versed in Doctrine internals, but looking at the fix, I found it odd that an entity would live in both the insertion and update tracking in the unit of work.

This implementation should fix the case described in DDC-2996, while not creating any side effects with objects that are scheduled to be inserted.

I've ran this test with the Doctrine test suite and have also tested this change with the DoctrineExtensions project; unless I'm doing something wrong, it seems to have good results.

Again, I'm not too well versed in the inner workings of Doctrine, but I did a little research, poked around some code, and came up with this.



 Comments   
Comment by Doctrine Bot [ 06/Jul/14 ]

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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





[DDC-3195] indexBy implementation on containsKey of PersistentCollection in EXTRA LAZY mode uses property name as column name instead of column name Created: 26/May/14  Updated: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: jos de witte Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Any



 Description   

indexBy implementation on containsKey (and possibly other EXTRA LAZY implemented methods) of PersistentCollection in EXTRA LAZY mode uses property name as column name instead of column name for OneToMany collections

For example property = fieldName, column name field_name.
Set indexBy on OneToMany annotation to fieldName (as it should be ) and it tries to use fieldName in backend instead of field_name






[DDC-3189] blob doctrine2 not inserting file in mysql Created: 24/Jun/14  Updated: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: Gustavo Monti Rocha Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux Ubuntu 12.04, Mysql 5


Attachments: PNG File a.png     Zip Archive testedoctrineupload.zip    

 Description   

I have an entity mapped as:

/**
 * @Entity @Table(name="Upload")
**/
class Upload
{
/** @Id @Column(type="integer") @GeneratedValue **/
protected $id;

/** @Column(type="string") **/
protected $nome;

/** @Column(type="blob") **/
protected $arquivo;

When I use this (WORKS)

 $query = "INSERT INTO Upload1 (name, size, type, content ) "."VALUES ('$fileName', '$fileSize', '$fileType', '$content')";

 mysql_query($query)

When I use this doctrine way (NOT WORKING, if you try to get this file from mysql, return a corrupted or empty file)

$upload = new Upload();

$upload-> setContent($content);
$upload-> setName($fileName);
$upload-> setSize($fileSize);
$upload-> setType($fileType);

$entityManager->persist($upload);
$entityManager->flush();

My html file:

<form method="post" enctype="multipart/form-data">
<table width="350" border="0" cellpadding="1" cellspacing="1" class="box">
<tr> 
<td width="246"> 
<input type="hidden" name="MAX_FILE_SIZE" value="2000000">
<input name="userfile" type="file" id="userfile"> 
</td>
<td width="80"><input name="upload" type="submit" class="box" id="upload" value=" Upload    "></td>
</tr>
</table>
</form>


 Comments   
Comment by Gustavo Monti Rocha [ 24/Jun/14 ]

trying to insert this image

Comment by Gustavo Monti Rocha [ 24/Jun/14 ]

Using:
$entityManager->getConnection()>getConfiguration()>setSQLLogger( new Doctrine\DBAL\Logging\EchoSQLLogger());

Getting:
"START TRANSACTION" INSERT INTO Upload (name, type, size, content) VALUES (?, ?, ?, ?) array(4) { [1] => string(5) "a.png" [2] => string(9) "image/png" [3] => int(264547) [4] => string(270342) "‰PNG  \0\0\0 IHDR\0\0@\0\0„\0\0\0v/jõ\0\0\0sBITÛáOà\0\0\0tEXtSoftware\0gnome-screenshotï¿>\0\0 \0IDATxœìw|TÅöÀÏܲ{·$›^I¥“Лҫ€ QPô©`

{êÏγ÷^ŸýYÀ‚ˆ\"¢ô %½m’í햙ߛ,›mÙe¾>š½÷Ι™3gæÎœ;]3ÿR P( …B¡P( …\0\0³X¾Ÿ†X]ŸÞ]ÿÂôP(\0àÜnñ¯N…B¡P( …B¡P(„B\0\0\\.÷ñ’ÊüünݺÇøîÚl¶m;æçfh4\0@BUR)”3®©šR( …B¡P( …ræa2Y+«ëV\0@4……}

Y–<¸§×KEÙ±ãHaaßâ¢#n·\0Ãf¦§ÄÇÇþÅé¦PÎ0¨‹B¡P( …B¡P(g(„ÙttTJ5\"\0< g§æefe¥ú?3rd¿Š £V.W7ì&\0˜âF+‰ø%9uÆF\0HINø«pôx…ZÅuÉL¥“Ô(‘Ù³¯\0ú÷í}ã¶9°A‡Óãr¥Åé¯n"... } array(4)

{ [1] => string(6) "string" [2] => string(6) "string" [3] => string(7) "integer" [4] => string(4) "blob" }

"COMMIT"

Comment by Steve Müller [ 26/Jun/14 ]

This looks more like a DBAL issue. Can you please provide the error/exception message that you receive from the driver/database server? Also do you use PDOMySQL or mysqli driver?

Comment by Gustavo Monti Rocha [ 26/Jun/14 ]

Steve,

I'm not getting any error/expection. Table looks like insert the blob file but when I try to download it is corrupted. You could see at getting .zip file and executing it.

I'm using PDOMysql.

Comment by Marco Pivetta [ 26/Jun/14 ]

This would probably need a data sample to reproduce the issue.

Comment by Gustavo Monti Rocha [ 26/Jun/14 ]

Marco,

you could use project attached and image in order to reproduce.

Comment by Marco Pivetta [ 26/Jun/14 ]

Gustavo Monti Rocha you should actually provide a functional test for this in case, see https://github.com/doctrine/dbal/tree/master/tests/Doctrine/Tests/DBAL

For example, the zip file you uploaded fails on various includes, and doesn't show the failures to me.





[DDC-3188] Call to a member function getValue() on a non-object in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php Created: 24/Jun/14  Updated: 27/Jun/14

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

Type: Bug Priority: Major
Reporter: Daniel Imhoff Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.4.11
opensuse
apache2



 Description   

This is the line that causes the fatal error: https://github.com/doctrine/doctrine2/blob/v2.4.2/lib/Doctrine/ORM/UnitOfWork.php#L678

This is the association that is breaking it (i.e. reflFields[ 'user' ] is a non-object):

Tweet.php
/**
 * @ManyToOne(targetEntity="User")
 * @JoinColumn(name="user_id", referencedColumnName="id")
 *
 * @var User
 */
protected $user;

This is the pk of the referenced entity.

User.php
/**
 * @Id
 * @Column(name="id", type="bigint", nullable=false)
 *
 * @var int
 */
protected $id;

If an exception was thrown due to missing metadata information, I could catch it, but fatal errors due to this bug have been crashing our scripts and they've had to be manually restarted.

Let me know what other information is needed.

Full stack trace:

PHP 5. Doctrine\ORM\EntityManager->flush() our_code.php
PHP 6. Doctrine\ORM\UnitOfWork->commit() vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:389
PHP 7. Doctrine\ORM\UnitOfWork->computeChangeSets() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:297
PHP 8. Doctrine\ORM\UnitOfWork->computeScheduleInsertsChangeSets() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:703
PHP 9. Doctrine\ORM\UnitOfWork->computeChangeSet() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:404
PHP Fatal error: Call to a member function getValue() on a non-object in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 678



 Comments   
Comment by Marco Pivetta [ 24/Jun/14 ]

Did you actually validate your mappings?

Comment by Daniel Imhoff [ 24/Jun/14 ]

I did not validate the mapping. I did not know about the orm:validate-schema until just now. I will fix these errors and resubmit if there is still an issue.

Sorry about that, thanks.

Comment by Daniel Imhoff [ 24/Jun/14 ]

The tweet and user relationship is not in the list of invalid mappings.

Comment by Marco Pivetta [ 26/Jun/14 ]

Are User and Tweet in the same namespace?

Comment by Daniel Imhoff [ 27/Jun/14 ]

Yes, and I've since then used the FQNS. I would get a class not found error when validating schema.
This is something that I know can't really be debugged by you guys, I was just hoping for a little direction. We are using memcache to store our metadata, and we are clearing and regenerating the metadata during every deploy (it is not autogenerated). I'm now using a commit hash as the namespace of the metadata, so we'll see if this fixes the issue.

Comment by Marco Pivetta [ 27/Jun/14 ]

It looks like a typo (CasESensiTIViTy issue) to me.





[DDC-3184] Invalid hydration of entities using ManyToOne relation via queryBuilder Created: 23/Jun/14  Updated: 25/Mar/15

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

Type: Bug Priority: Major
Reporter: Dmitry Korotovsky Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File DDC3184Test.php    

 Comments   
Comment by Dmitry Korotovsky [ 23/Jun/14 ]

In master branch all works perfect

Comment by Dmitry Korotovsky [ 23/Jun/14 ]

Marco Pivetta, fix in 2.5 branch will be ported to 2.4 stable version?

Comment by Marco Pivetta [ 23/Jun/14 ]

Dmitry Korotovsky first we'll need to check what commit fixed the issue. Could you git bisect with your test?

Comment by Dmitry Korotovsky [ 23/Jun/14 ]

Yes, i found it: https://github.com/doctrine/doctrine2/commit/38b683838648b549aad0e38ce88c70b6393755b3

Comment by Marco Pivetta [ 23/Jun/14 ]

Assigning to Guilherme Blanco, since he is the author of the fix.





[DDC-3183] Add JsonSerializable to Collections Created: 22/Jun/14  Updated: 22/Jun/14

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

Type: New Feature Priority: Major
Reporter: Gabriel Bull Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, orm


 Description   

Implement this:

http://www.php.net/manual/fr/class.jsonserializable.php

Can't really make this claim if Doctrine is not implementing basic interfaces for collections:

> The missing (SPL) Collection/Array/OrderedMap interface.






[DDC-3182] [GH-1066] Added jsonSerialize method to PersistentCollection Created: 22/Jun/14  Updated: 22/Jun/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of gabrielbull:

Url: https://github.com/doctrine/doctrine2/pull/1066

Message:

Added jsonSerialize.

Here is to commit on collections:
https://github.com/doctrine/collections/pull/33



 Comments   
Comment by Doctrine Bot [ 22/Jun/14 ]

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





[DDC-3181] Class Table Inheritance - wrong table order on insert with more than one level of inheritance Created: 20/Jun/14  Updated: 02/Dec/14

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

Type: Bug Priority: Major
Reporter: M. de Lange Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm
Environment:

oracle



 Description   

note: this issue seems the same as DDC-732

When using class table inheritance with multiple levels i.e.:
Object -> SolidObject -> Building -> House
(House inherits from Building, Building from SolidObject, SolidObject from Object)

Object has the discriminator column and mapping. When persisting a new House entity I get a foreign key error because there is no row in the Building table.

I searched in the Code and found the problem. In the class "Doctrine\ORM\Persisters\JoinedSubclassPersister" in function "executeInserts()" around line 146 the array $subTableStmts is first declared and then filled with insert statements. The statement of the House-table is first added, and then the parent-tables (except the root-table "Object", since that one is executed first).

So the order in which the insert statements are executed is:
1 Insert into Object ...
2 Insert into House ... (which causes the error)
3 insert into Building ...
4 Insert into SolidObject

I edited the source to insert into the parent-tables (first SolidObject, then Building) before inserting into the table that belongs to the class that is persisted (House). And this works



 Comments   
Comment by mohammed [ 26/Nov/14 ]

hello, can you please send me the modified lines or just share with me the whole method executeInserts.
thanks in advance





[DDC-3176] Table-inheritance and OneToOne association as entity ID Created: 18/Jun/14  Updated: 18/Jun/14

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

Type: Bug Priority: Major
Reporter: Elioty Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: association, identity, inheritance, orm
Environment:

Ubuntu 14.04, PHP 5.5.9-1ubuntu4, Symfony 2.5



 Description   

The issue is fully described here:
http://stackoverflow.com/questions/24265731/symfony-doctrine-class-table-inheritance-and-foreign-key-as-primary-key






[DDC-3174] Query Cache not correct working when using SQLFilter Created: 17/Jun/14  Updated: 16/Jan/15

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

Type: Bug Priority: Major
Reporter: