[DDC-3093] [GH-1013] Remove SimpleXmlElement hack Created: 18/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

The functionality it self its already tested by : https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Tools/Export/AbstractClassMetadataExporterTest.php#L155



 Comments   
Comment by Doctrine Bot [ 18/Apr/14 ]

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

Fixed already.





[DDC-3092] [GH-1012] Ddc 3078 slc cache interface ctor removal Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Guilherme Blanco [ 17/Apr/14 ]

Issue now merged! \o/





[DDC-3091] Not set entity to results if use query with JOIN Created: 17/Apr/14  Updated: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Vitaliy Zhuk Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi.
I have a problem, if i can use query with JOIN without grouping (DISTINCT) by identifier entity. Problem: not set entities to result, if entity has cached in ObjectHydration.

For example:

SQL query:

SELECT 
  b0_.id AS id0,
  b0_.hash AS hash1, 
  b0_.mii AS mii2, 
  b0_.iin AS iin3, 
  b0_.last_digits AS last_digits4, 
  b0_.number AS number5, 
  b0_.holder AS holder6, 
  p1_.keyword AS keyword7, 
  t2_.client AS client8, 
  CONCAT(b0_.hash, CONCAT(p1_.keyword, t2_.client)) AS sclr9 

FROM bank_card b0_ 
  INNER JOIN transaction_bank_card t2_ ON (t2_.bank_card_id = b0_.id) 
  INNER JOIN projects p1_ ON (t2_.project_key = p1_.keyword) 

WHERE (p1_.keyword = 'project1' AND t2_.client = '123') OR (p1_.keyword = 'project2' AND t2_.client = '321') /* ... Other where */

GROUP BY sclr9

Mysql result:

id0 hash1 mii2 iin3 last_digits4 number5 holder6 keyword7 client8 sclr9
28 1d741fd06f3315dad28039926effc5d7 5 533330 2763 533330******2763 John Doe p6 78165 1d741fd06f3315dad28039926effc5d7p678165
34 58b021876f625e3000137cd835f5fe40 5 555456 5047 555456******5047 OLOLO OLOLO p6 78165 58b021876f625e3000137cd835f5fe40p678165
2 887d30e9b4d18676c6e0dc8e21e36d28 5 556458 4251 556458******4251 Monkey Testing p6 78165 887d30e9b4d18676c6e0dc8e21e36d28p678165
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 100673 bb14a77f2e363cd144b669f0b594d304p6100673
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 100922 bb14a77f2e363cd144b669f0b594d304p6100922
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 101441 bb14a77f2e363cd144b669f0b594d304p6101441
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 78165 bb14a77f2e363cd144b669f0b594d304p678165
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 85550 bb14a77f2e363cd144b669f0b594d304p685550
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 85566 bb14a77f2e363cd144b669f0b594d304p685566
1 bb14a77f2e363cd144b669f0b594d304 4 432114 1118 432114******1118 Monkey Testing p6 85768 bb14a77f2e363cd144b669f0b594d304p685768

And the PHP code (from custom entity repository):

$qb
            ->select('bc')
            ->addSelect('p.key AS project_key')
            ->addSelect('tbc.client AS client')
            ->addSelect('CONCAT(bc.hash, CONCAT(p.key, tbc.client)) AS unique_key')
            ->innerJoin('FooBundle:TransactionBankCard', 'tbc', 'WITH', 'tbc.bankCard = bc.id')
            ->innerJoin('BarBundle:Project', 'p', 'WITH', 'tbc.project = p.key')
            ->where($orX)
            ->groupBy('unique_key');

        $result = $qb->getQuery()->getResult();

And this code returned only unique entities by identifier (Identifier: id field), but must returned the all entities from query.

The Object Hyndration has cached created entities, and if the next row is entity (indicate as identifier and dql alias), then hydration not set this entity to result.
Problem code: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php#L569-L572

Thank.






[DDC-3090] Cannot use single table inheritance in entities deriving from classes using class table inheritance Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Przemyslaw Wrobel Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None


 Description   

I have the following classes:

/**
 * @ORM\Table(name="diet_entries")
 * @ORM\Entity
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discriminator", type="string")
 * @ORM\DiscriminatorMap({"recipe" = "Recipe", "ingredient" = "Ingredient" })
 */
abstract class DietEntry {}
/**
 * @ORM\Table(name="recipes")
 */
class Recipe extends DietEntry {}
/**
 * @ORM\Table(name="ingredients")
 * @ORM\InheritanceType("SINGLE_TABLE")
 * @ORM\DiscriminatorColumn(name="discriminator", type="string")
 * @ORM\DiscriminatorMap({ "ingredient" = "Ingredient", "supplement" = "Supplement" })
 */
class Ingredient extends DietEntry {}
/**
 * @ORM\Entity
 */
class Supplement extends Ingredient {}

and these tables: diet_entries, recipes, ingredients.

The idea was not to create the table for supplements since a supplement needs no extra attributes other then those derived from an ingredient, otherwise I would have added Supplement to discriminator map of DietEntry and provided a table for it which is mandatory in JOINED inheritance.
But the problem now is that when a query is build it looks like this:

An exception occurred while executing

SELECT i0_.id AS id0, i0_.name AS name1, i0_.energy AS energy2, d1_.name AS name3, d2_.name AS name4 FROM ingredients i0_ INNER JOIN diet_databases d1_ ON d3_.database_id = d1_.id LEFT JOIN dictionary d2_ ON i0_.group_id = d2_.id WHERE i0_.discriminator IN ('ingredient', 'supplement')

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'i0_.name' in 'field list

The query for Ingredient is missing a join with the diet_entries table from which the ingredient derives. ORM only sees entities/tables down the inheritance path from the Ingredient class but not up from Ingredient to DietEntry



 Comments   
Comment by Marco Pivetta [ 17/Apr/14 ]

Duplicate of DDC-138





[DDC-3089] Doctrine1 to Doctrine2 Oracle type float Created: 17/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

Status: Resolved
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: Antoine Dr Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: None
Environment:

Linux - Oracle 10g



 Description   

I have a big problem migrating an application from Doctrine1 to Doctrine2.

The variable ROUNDNUMBER was set with Doctrine1 in the Oracle 10G database with the following schema :
ApprenticeYeartype:
columns:
id:

{type: integer, notnull: true, primary: true, autoincrement: true}

name:

{type: string(255), notnull: true}

roundNumber:

{type: float, notnull: true}

The values stored in this variable are: 0.1 or 0.5 or 1.0

In Oracle, the data type was set as "NUMBER" with no precision or scale set. I found this "If
a precision is not specified, the column stores values as given. If no scale is
specified, the scale is zero. ".
So there should be no scale which is weird because it worked with the values 0.1, 0.5...
It worked nicely on Symfony1 and Doctrine1, but for the migration to Symfony2 and Doctrine2, I used the command to import the schema from the database "php app/console doctrine:mapping:convert"

The created schema's ROUNDNUMBER variable was set with the Doctrine2 type "Integer". So now I get the variable as an int and not float and so I can't use it.

I tried changing the type to decimal, float etc...
/**

  • @var integer
    *
  • @ORM\Column(name="ROUNDNUMBER", type="integer", nullable=false)
    */
    private $roundnumber;

But I keep getting this error :
[Doctrine\DBAL\DBALException]
An exception occurred while executing 'ALTER TABLE APPRENTICE_YEARTYPE MODI
FY (ROUNDNUMBER DOUBLE PRECISION DEFAULT NULL)':

ORA-01440: column to be modified must be empty to decrease precision or sca
le

If anyone know a solution, please help me !



 Comments   
Comment by Steve Müller [ 17/Apr/14 ]

Looks like you create the column ROUNDNUMBER with an integer type mapping. Use "float" or "decimal" instead. When updating the schema please ensure that your ROUNDNUMBER column contains no data or at least all values in the column have to be NULL. See http://www.techonthenet.com/oracle/errors/ora01440.php
Please note that Doctrine's "float" maps to "DOUBLE PRECISION" and "decimal" to "NUMERIC(p,s)" on Oracle. See the DBAL types documentation for further information: http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/types.html#mapping-matrix

If you need further help, just drop me a line.

Comment by Steve Müller [ 17/Apr/14 ]

Not a Doctrine bug.





[DDC-3088] EntityManager::clear doesn't working with inserting Created: 16/Apr/14  Updated: 16/Apr/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: Adrian Ch Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.4.25-1+sury.org~precise+2 (cli) (built: Feb 12 2014 10:45:30)
Symfony version 2.4.2 - app/dev/debug



 Description   

It looks like EntityManager's clear() method doesn't remove objects that was persisted during script execution.

Bellows are two functions. First one insert 10.000 records and use clear after each flush that should remove objects from memory, but instead of that memory usage growths in each iteration. There isn't any other reference for this objects.

I've checked how it works for reading and with clearing it works perfectly - script uses only constant memory.

 
    private function testInserting($em, $entityClass, $batchSize, $startMemoryUsage)
    {
        for ($i = 1; $i <= 10000; ++$i) {

            $item = new $entityClass();
            $item->setName($i);
            $item->setPresentation($i);
            $em->persist($item);

            if ($i % $batchSize == 0) {
                $em->flush();
                $em->clear();

                $currentMemoryUsage = memory_get_usage();
                printf("%d:\n\t%.2f MB (%.2f MB)\n", $i, $currentMemoryUsage /1024 / 1024, ($currentMemoryUsage - $startMemoryUsage) / 1024 / 1024);
            }
        }
    }
    
    
private function testReading($em, $entityClass, $batchSize, $startMemoryUsage)
    {
        $q = $em->createQuery("select i from $entityClass i");
        $iterableResult = $q->iterate();

        $i = 0;
        while (($row = $iterableResult->next()) !== false) {
            $em->clear();
            if ($i % $batchSize == 0) {
                $currentMemoryUsage = memory_get_usage();
                printf("%d:\n\t%.2f MB (%.2f MB)\n", $i, $currentMemoryUsage /1024 / 1024, ($currentMemoryUsage - $startMemoryUsage) / 1024 / 1024);
            }

            $i++;
        }
    }
    

My results:

1) Reading without clearing ($em->clear(); removed)

0:
22.89 MB (2.63 MB)
1000:
33.41 MB (13.15 MB)
2000:
44.04 MB (23.78 MB)
3000:
53.50 MB (33.24 MB)
4000:
65.13 MB (44.86 MB)
5000:
74.81 MB (54.55 MB)
6000:
84.27 MB (64.01 MB)
7000:
97.96 MB (77.69 MB)
8000:
107.40 MB (87.14 MB)
9000:
117.17 MB (96.91 MB)
10000:
126.61 MB (106.35 MB)

2) Reading with using clear

0:
22.89 MB (2.63 MB)
1000:
26.25 MB (5.99 MB)
2000:
24.74 MB (4.48 MB)
3000:
26.72 MB (6.46 MB)
4000:
24.79 MB (4.52 MB)
5000:
26.76 MB (6.50 MB)
6000:
24.81 MB (4.55 MB)
7000:
26.77 MB (6.51 MB)
8000:
24.83 MB (4.57 MB)
9000:
26.81 MB (6.54 MB)
10000:
24.86 MB (4.60 MB)

3) Inserting without clearing

1000:
29.50 MB (9.24 MB)
2000:
37.76 MB (17.50 MB)
3000:
45.12 MB (24.86 MB)
4000:
54.34 MB (34.07 MB)
5000:
61.79 MB (41.53 MB)
6000:
69.09 MB (48.82 MB)
7000:
76.40 MB (56.13 MB)
8000:
83.75 MB (63.48 MB)
9000:
95.64 MB (75.37 MB)
10000:
102.98 MB (82.71 MB)

4) Inserting with using clear

1000:
27.90 MB (7.63 MB)
2000:
34.64 MB (14.37 MB)
3000:
40.43 MB (20.17 MB)
4000:
48.20 MB (27.93 MB)
5000:
54.12 MB (33.85 MB)
6000:
59.89 MB (39.63 MB)
7000:
65.67 MB (45.40 MB)
8000:
71.43 MB (51.16 MB)
9000:
81.51 MB (61.25 MB)
10000:
87.29 MB (67.02 MB)



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

Would be useful to see what the entity class looks like.

Additionally, the ORM version being affected is also needed.





[DDC-3087] Entity code generation skip setters Created: 15/Apr/14  Updated: 15/Apr/14

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

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


 Description   

When executing `orm:generate-entities` to generated methods, do not generate setters when entity is readOnly `@ORM\Entity(readOnly=true)`






[DDC-3086] [GH-1011] Single quotes can't nest Created: 15/Apr/14  Updated: 15/Apr/14  Resolved: 15/Apr/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

I decided to use "... '...' ...", but perhaps you prefer '... \'...\' ...'?



 Comments   
Comment by Doctrine Bot [ 15/Apr/14 ]

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

Comment by Marco Pivetta [ 15/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/68d477a4c6d2dc2c201015a6fceb4e64e5ce744a





[DDC-3085] NULL comparison are not supported for result variables in the HAVING clause Created: 15/Apr/14  Updated: 15/Apr/14

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

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


 Description   

the following DQL query fails saying that score does not point to a class:

SELECT u AS user, SUM(r.value) AS score
FROM User u
LEFT JOIN ResultEntry r WITH r.user = u
GROUP BY u
HAVING score IS NOT NULL AND score >= 5

When removing the condition score IS NOT NULL, the query is working fine. The score result variable can be used in other comparisons:

SELECT u AS user, SUM(r.value) AS score
FROM User u
LEFT JOIN ResultEntry r WITH r.user = u
GROUP BY u
HAVING score >= 5





[DDC-3084] Native query removes duplicate root entities Created: 14/Apr/14  Updated: 15/Apr/14  Resolved: 14/Apr/14

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

Type: Bug Priority: Major
Reporter: Przemyslaw Wrobel Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

I have a query like that:

        $rsm = new ResultSetMappingBuilder($this->_em);
        $rsm->addScalarResult('rank', 'rank');
        $rsm->addRootEntityFromClassMetadata('Application\Entity', 'e');

		$query = $this->_em->createNativeQuery('
            SELECT
            	r.rank, ' . $rsm->generateSelectClause(array('e')) . '
            FROM ...
	    ', $rsm);

        return $query->getResult();

When I issue it at the mysql side it returns 3 rows but doctrine returns only 2 - I have tried getArrayResults() with the same results

The query could return the same entity multiple times for different values of the "rank" scalar value but it seems that doctrine removes those duplicates



 Comments   
Comment by Przemyslaw Wrobel [ 14/Apr/14 ]

the result should be like this: ("rank", "entity")
1, entity1
2, entity2
3, entity2

Comment by Marco Pivetta [ 14/Apr/14 ]

Doctrine ORM groups the values of the root of the selection by identifier during hydration: this is the expected result.

Comment by Przemyslaw Wrobel [ 15/Apr/14 ]

If it is really grouping than I shoud have something like that
entity1, 1
entity2, array(2,3)

Now the problem is that I am losing data - the row: 3, entity2 is missing and I have to resort to DBAL query or do not map to entities but than I cannot use my model logic





[DDC-3083] Persist/Flush silently fails when CTI is applied on an existing table Created: 12/Apr/14  Updated: 13/Apr/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: Frank Liepert Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Given an existing table (= parent table) the integration of a new parent-child relationship with Class Table Inheritance (CTI) leads to a update problem.

First of all a child table is created with a foreign key to the parent table. Next, the discriminator column is added to the parent table. The discriminator map will be auto-generated.

The problem arises when trying to perform persist() and flush() on a child entity. Initially the child table is logically empty. However, the UnitOfWork triggers updateTable() which will fail since there is nothing to update. Instead, an upsert should be performed.

Another sneaky thing is that the repository will return the child class with the updated data after calling flush() on the same request. On the next request the child class is returned with the data loaded from the persister. Of course, the updated data is missing.



 Comments   
Comment by Marco Pivetta [ 13/Apr/14 ]

Frank Liepert do I understand this correctly if I say that you are trying to (pseudo) upcast an entity to a more specific subtype? That is unsupported by the ORM. Could you make just an example snippet of what you described in the issue?

Comment by Frank Liepert [ 13/Apr/14 ]

Marco Pivetta: You have understood really well. If you say that's not supported by the ORM then this is the answer. Still I think that upsert could solve solve the "problem" and I know that there are/have been discussions about upsert.

Right now I will continue to manually insert the missing rows in the child table. After this necessary step the ORM works as expected.

Nevertheless the real bug is that after persist() and flush() the entity manager returns the child object with the "persisted" data of the child table although there are in fact no rows in the child table.

$parentRepository = $em->getRepository('Parent');

$child = $parentRepository ->find(1);
$child->setChildPropertyA('foo');

$em->persist($child);
$em->flush();

$child = $parentRepository ->find(1);
var_dump($child->getChildPropertyA());
// string(3) "foo"

// But: There is no 'foo' in the child table!


/** 
 * NEW REQUEST
 */

$parentRepository = $em->getRepository('Parent');

$child = $parentRepository ->find(1);
var_dump($child->getChildPropertyA());
// NULL

Comment by Marco Pivetta [ 13/Apr/14 ]

Frank Liepert why are $child in the first request and $child in the second request different here? Are you manually changing the data at SQL level?

Comment by Frank Liepert [ 13/Apr/14 ]

Marco Pivetta as I have explained the persist() and flush() in the first request trigger an UPDATE command (Because there is already a row in the parent table?). Given that the child table was manually created before there are no rows on that table at that time and therefore nothing can be updated. Nevertheless the ORM triggers no error and $child looks like having been persisted. In the second request you'll notice that there haven't been persisted any of the data belonging to the child table.





[DDC-3082] [GH-1010] Fixed validation message Created: 11/Apr/14  Updated: 11/Apr/14  Resolved: 11/Apr/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed 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/1010

Message:

A message of the SchemaValidator erroneously mentions the source entity instead of the target entity.



 Comments   
Comment by Doctrine Bot [ 11/Apr/14 ]

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

Comment by Marco Pivetta [ 11/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/8b6b1c68a05035822804ef7ce516dbb2471f6efe





[DDC-3081] [GH-1009] HHVM compatibility Created: 10/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed 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/1009

Message:

With this PR (based on DDC-3078, see #1008) we finally get 100% compatibility with HHVM as we described on http://www.doctrine-project.org/2013/12/23/our-hhvm-roadmap.html

This PR needs to be rebased on master once #1008 is merged.



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/54d9f05e39bc6c0943a48dfb523675c931a1435b





[DDC-3080] [GH-1008] DDC-3078 SLC Cache interface ctor removal Created: 10/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
is required for DDC-3078 Doctrine\ORM\Cache::__construct is in... Resolved

 Description   

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

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

Message:

See DDC-3078 ( http://www.doctrine-project.org/jira/browse/DDC-3078 ) - the cache interface should NOT cover a constructor.



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by https://github.com/doctrine/doctrine2/commit/6af3236ba6f285fe14763866b20ddc1085e6ea39





[DDC-3079] preUpdate in EntityListener not run in transaction Created: 10/Apr/14  Updated: 10/Apr/14

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

Type: Bug Priority: Major
Reporter: Jiri Napravnik Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have entity:

class Article{
	/**
	 * @ORM\OneToMany(targetEntity = "ArticleModule\Model\Entities\ArticlePhoto", mappedBy = "article", cascade = {"persist", "remove"}, orphanRemoval = TRUE)
	 * @ORM\OrderBy({"sequence" = "ASC"})
	 */
	protected $articlePhotos;
}

And Entity Listener with preRemove.

I call

$article->articlePhotos->clear();
...some changes with entity...
$em->flush();

preRemove in Entity Listener is called, BUT before Begin transaction...

I can do
$em->transactional(function(){}); then it's full in transaction..






[DDC-3078] Doctrine\ORM\Cache::__construct is in an interface Created: 10/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Blocker
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, config, second-level-cache

Issue Links:
Dependency
depends on DDC-3080 [GH-1008] DDC-3078 SLC Cache interfac... Resolved

 Description   

CTOR in the interface is a huge problem. This absolutely needs to be fixed before 2.5 is released, or we will have trouble in future.

I'm writing a PoC patch right now.



 Comments   
Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by https://github.com/doctrine/doctrine2/commit/6af3236ba6f285fe14763866b20ddc1085e6ea39





[DDC-3077] [GH-1007] Minor dockblock change Created: 09/Apr/14  Updated: 09/Apr/14  Resolved: 09/Apr/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 09/Apr/14 ]

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

Comment by Marco Pivetta [ 09/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/ac956f2b8c231416da5c683e295fb6b8aa61b177





[DDC-3076] [GH-1006] Handling invalid discriminator values Created: 09/Apr/14  Updated: 16/Apr/14  Resolved: 15/Apr/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Two scenarios:

  • *The DiscriminatorMap is specified via metadata*. In case the entity's discriminator value is not matching with a value of the DiscriminatorMap it will result in a ``Notice: Undefined index ... on line 102`` and ``exception 'Doctrine\Common\Persistence\Mapping\MappingException' with message 'Class '' does not exist' in``. The proposed changes deal with this.
  • *The DiscriminatorMap is automatically generated*. The discriminator value may no longer be invalid if there's just metadata missing for the automatically generated class names. I'm not sure how to deal with that properly.


 Comments   
Comment by Doctrine Bot [ 15/Apr/14 ]

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

Comment by Marco Pivetta [ 15/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/2da74e5147b6babf296ccdca30931525cbbc3cac





[DDC-3075] [GH-1005] Added support of the subselect expressions into NEW expressions Created: 08/Apr/14  Updated: 08/Apr/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 x3ak:

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

Message:

Added support for the subselects into the ���NEW��� Operator Syntax






[DDC-3074] [GH-1004] Removed all useless occurrence of require_once TestInit.php Created: 07/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

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


 Description   

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

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

Message:

As @Ocramius pointed out when discussing about PR #1000, the statement ``require_once [...]TestInit.php`` is no longer useful.

I've removed all occurrence from the test cases.



 Comments   
Comment by Doctrine Bot [ 07/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/73e5bbecbef311194085e30d8b7fd6516bc50425





[DDC-3073] @Column options Created: 07/Apr/14  Updated: 07/Apr/14

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

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


 Description   

The documentation seems to lack a reference to the ability to set options for columns. See:
http://stackoverflow.com/a/11776153/1833322
http://stackoverflow.com/a/14221973/1833322
http://stackoverflow.com/a/18050298/1833322






[DDC-3072] [GH-1003] Let user extend EntityManager Created: 06/Apr/14  Updated: 06/Apr/14  Resolved: 06/Apr/14

Status: Resolved
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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

change new EntityManager into new self in static function create



 Comments   
Comment by Doctrine Bot [ 06/Apr/14 ]

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





[DDC-3071] [GH-1002] Fixed wrongly initialized property. Created: 04/Apr/14  Updated: 04/Apr/14  Resolved: 04/Apr/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed 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/1002

Message:

This removes an incorrect `= array()` initialization on `$parameters`, which is actually an `ArrayCollection` and has its value set in the constructor.



 Comments   
Comment by Doctrine Bot [ 04/Apr/14 ]

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

Comment by Marco Pivetta [ 04/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/4d950a9e10936eb44d2a77953000e3f067a1b8fe





[DDC-3070] [GH-1001] [DDC-3005] Defer invoking of postLoad event to the end of hydration cycle. Created: 04/Apr/14  Updated: 04/Apr/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 Strate:

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

Message:

This feature makes guarantee, that postLoad event fires after all associations are populated.
Test case also provided.






[DDC-3069] [GH-1000] [DDC-3068] EntityManager::find accept array of object as id Created: 04/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Pull Request for ticket http://www.doctrine-project.org/jira/browse/DDC-3068
Here follow the ticket description for you convenience.

According to the documentation, ``EntityManager::find`` should return one entity given it's primary key. When a primary key of an entity is composed of multiple associations, one (me ) would expect that the following works, but it doesn't:
```php
$entity = $_em->find('My\EntityClass', array(
'assoc1' => $instance1,
'assoc2' => $instance2
));
PHP Fatal error: Object of class My\EntityClass could not be converted to string
```
The only working way I've found is the following:
```php
$entity = $_em->find('My\EntityClass', array(
'assoc1' => $instance1->getId(),
'assoc2' => $instance2->getId()
));
```
I think that this second scenario is not correct, since expose implementation details.



 Comments   
Comment by Doctrine Bot [ 18/Apr/14 ]

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/10a0daf6203b6d2ea0c92e30edb07ca7e83058b3 this issue was fixed.





[DDC-3068] EntityManager::find does not accept an array of object as a primary key Created: 03/Apr/14  Updated: 18/Apr/14  Resolved: 18/Apr/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3, 2.4, Git Master
Fix Version/s: 2.5
Security Level: All

Type: Improvement Priority: Minor
Reporter: Giorgio Premi Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

According to the documentation, EntityManager::find should return one entity given it's primary key. When a primary key of an entity is composed of multiple associations, one (me ) would expect that the following works, but it doesn't:

$entity = $_em->find('My\EntityClass', array(
    'assoc1' => $instance1,
    'assoc2' => $instance2
));
PHP Fatal error:  Object of class My\EntityClass could not be converted to string

The only working way I've found is the following:

$entity = $_em->find('My\EntityClass', array(
    'assoc1' => $instance1->getId(),
    'assoc2' => $instance2->getId()
));

I think that this second scenario is not correct, since expose implementation details.

I've created a patch on my github fork, I'll create a pull request ASAP.



 Comments   
Comment by Guilherme Blanco [ 18/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/10a0daf6203b6d2ea0c92e30edb07ca7e83058b3 issue was fixed.





[DDC-3067] [GH-999] DDC-3065 null value in in criteria support Created: 03/Apr/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
is required for DDC-3065 Generated 'IN' clause doesn't handle ... In Progress

 Description   

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

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

Message:

See DDC-3065 (http://www.doctrine-project.org/jira/browse/DDC-3065)

This MAY be a breakage, since the following API now works as expected:

```php
$repository->findBy(['fieldName' => [null]]);
$repository->findBy(['fieldName' => [123, null]]);
```

Where before, `null` was just ignored



 Comments   
Comment by Doctrine Bot [ 03/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Closed, see : https://github.com/doctrine/doctrine2/pull/998





[DDC-3066] [GH-998] DDC-3065 null value in in criteria support Created: 03/Apr/14  Updated: 03/Apr/14  Resolved: 03/Apr/14

Status: Resolved
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: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-3065 Generated 'IN' clause doesn't handle ... In Progress

 Description   

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

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

Message:

See DDC-3065 (http://www.doctrine-project.org/jira/browse/DDC-3065)

This MAY be a breakage, since the following API now works as expected:

```php
$repository->findBy(['fieldName' => [null]);
$repository->findBy(['fieldName' => [123, null]);
```

Where before, `null` was just ignored



 Comments   
Comment by Doctrine Bot [ 03/Apr/14 ]

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

Comment by Marco Pivetta [ 03/Apr/14 ]

Wrong branch name.





[DDC-3065] Generated 'IN' clause doesn't handle 'null' values (needs to add 'IS NULL' check) Created: 03/Apr/14  Updated: 03/Apr/14

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

Type: Bug Priority: Critical
Reporter: Sam Adams Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: IN, null, orm

Issue Links:
Dependency
depends on DDC-3067 [GH-999] DDC-3065 null value in in cr... Resolved
Reference
is referenced by DDC-3066 [GH-998] DDC-3065 null value in in cr... Resolved

 Description   

BasicEntityPersister::getSelectSQL($criteria) first argument can take an array.
However, if that array contains an 'or' structure like so:

array(
  'mycol'=>array(
    'couldbethis','orthis',null
  )
);

it is converted into:

mycol IN (?)

With the final query looking like:

WHERE mycol IN ('couldbethis','orthis',null)

The problem is, mysql will never be able to match the null.

Possible change to getSelectConditionStatementSQL method:

        if (is_array($value)) {
            $in = sprintf('%s IN (%s)' , $condition, $placeholder);
            $nullKey = array_search(null, $value, true);

            if ($nullKey) {
                return sprintf('(%s OR %s IS NULL)' , $in, $condition);
            } else {
                return $in;
            }
        }

resulting in a final query like:

WHERE (mycol IN ('couldbethis','orthis',null) OR mycol IS NULL)


 Comments   
Comment by Marco Pivetta [ 03/Apr/14 ]

Please see https://github.com/doctrine/doctrine2/pull/998 - I applied your suggested fix and tested it carefully

Comment by Doctrine Bot [ 03/Apr/14 ]

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





[DDC-3064] Parse Error which is pointing to the method getSingleResult(); Created: 02/Apr/14  Updated: 02/Apr/14  Resolved: 02/Apr/14

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

Type: Bug Priority: Major
Reporter: Haneefa Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: orm
Environment:
  1. DoctrineModule for Zend Framework 2


 Description   

syntax error, unexpected ''sidebar_bann' (T_ENCAPSED_AND_WHITESPACE), expecting ']'

TracedError reported from New Relic
Application: ENV2
Timestamp: 02/26/14 10:49:15
Exception Class: E_PARSE
Error Action: /index.php
Uri: /blog
Error message
E_PARSE: syntax error, unexpected ''sidebar_bann' (T_ENCAPSED_AND_WHITESPACE), expecting ']'



 Comments   
Comment by Haneefa [ 02/Apr/14 ]

Please help me to find out the cause of this issue.
Thanks!

Comment by Marco Pivetta [ 02/Apr/14 ]

Could you provide the DQL?

Comment by Haneefa [ 02/Apr/14 ]

I don't have the DQL as this error was logged by newrelic, see the zend stack trace here
…dor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/
HydratorFactory.php (144)
…dor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/
in Doctrine\ODM\MongoDB\Hydrator\HydratorFactory::getHydratorFor called at /vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Hydrator/HydratorFactory.php
HydratorFactory.php (404)
/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/
UnitOfWork.php (2518)
/vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/
Cursor.php (118)
in Doctrine\ODM\MongoDB\Cursor::current called at ?
…alled at /vendor/doctrine/mongodb/lib/Doctrine/MongoDB/
Cursor.php (371)
…alled at /vendor/doctrine/mongodb/lib/Doctrine/MongoDB/
Cursor.php (419)
…alled at /vendor/doctrine/mongodb/lib/Doctrine/MongoDB/
Cursor.php (372)
…alled at /vendor/doctrine/mongodb/lib/Doctrine/MongoDB/
Cursor.php (384)
… at /vendor/doctrine/mongodb/lib/Doctrine/MongoDB/Query/
Query.php (277)

Comment by Marco Pivetta [ 02/Apr/14 ]

Not an ORM issue

Comment by Haneefa [ 02/Apr/14 ]

Can you just light me on this issue? what would I need to do? It is happening when I add a domain name(xxx.extample.com) in where condition. It would be great if you can help me.

Comment by Marco Pivetta [ 02/Apr/14 ]

Haneefa this is an issue tracker, not a support forum. You report issues here once you verified that it is actually a bug, a mistake on our side or something that has to be added or cleaned up in future versions of the software.

Your issue is a problem with MongoDB ODM (not with the ORM), and you should ask on either the mailing list (once you have more detail) or stackoverflow, or IRC (irc.freenode.net#doctrine).

Comment by Haneefa [ 02/Apr/14 ]

Thank you so much!





[DDC-3063] Unexpected behavior with 'WHERE NOT IN' and empty array Created: 01/Apr/14  Updated: 01/Apr/14

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

Type: Bug Priority: Major
Reporter: Tim Stamp Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None
Environment:

CentOS, PHP 5.4, mysql



 Description   

I tried to set version to 2.4.0 but was prevented.

Assume the set 'n' contains 10 records, all with id > 0.

->andWhere('n.id NOT IN (:ids)')->setParameter('ids', [])
returns 0 records.

->andWhere('n.id NOT IN (:ids)')->setParameter('ids', [0])
returns 10 records.


 Comments   
Comment by Marco Pivetta [ 01/Apr/14 ]

This is a simple misunderstanding of how SQL IN() works

Comment by Tim Stamp [ 01/Apr/14 ]

You're right that its invalid SQL, but this is DQL. In SQL this would raise an error, in DQL it says nothing and returns nothing.

Isnt there a way to check if a statement has caused this error?

Comment by Marco Pivetta [ 01/Apr/14 ]

Tim Stamp yeah, when using IN() and NOT IN() you should actually check if the parameters are empty or not before adding the clause.

Comment by Steve Müller [ 01/Apr/14 ]

It's still weird that no error is raised by that. Tim Stamp can you check what SQL is generated by your query?

Comment by Steve Müller [ 01/Apr/14 ]

Hehe I think I got the problem. It might be DBAL related. See:

https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/SQLParserUtils.php#L140
https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/SQLParserUtils.php#L169

Looks like the implementing person did that by intention but don't ask me why.

Comment by Marco Pivetta [ 01/Apr/14 ]

Thats to avoid having an SQL statement like

SELECT * FROM foo WHERE bar IN()

, which is invalid.

Indeed, the NOT IN() case is not contemplated by that.

Comment by Steve Müller [ 01/Apr/14 ]

Just wondering if that kind of implementation isn't changing expectations because it looks like IN(NULL) will select all NULL rows then, even though this is not explicitly requested by the user. I don't care really TBH but this behaviour is not very transparent to the user. Personally I would like to see an error instead... Then at least I know what's going on and can fix that by additional checks instead.

Comment by Marco Pivetta [ 01/Apr/14 ]

Makes sense. Re-opening.

Comment by Steve Müller [ 01/Apr/14 ]

The question is if we can change this behaviour without breaking applications that rely on the current one. Because changing the code to throw an error breaks applications that insist on returning 0 rows for an empty array. I don't know what rules apply here concerning BC. What do you think Marco Pivetta?

Comment by Marco Pivetta [ 01/Apr/14 ]

Steve Müller existing apps should do following anyway:

if ($productIds) {
    $qb->andWhere('p.id IN (:productIds)')->setParameter('productIds', $productIds);
}

If they are not, that's most likely a bug in their codebase.

Comment by Steve Müller [ 01/Apr/14 ]

Agree. Was just wondering about what we can expect and what we can't expect.





[DDC-3062] [GH-997] [FIX] Allow to use ManyToMany with all operators Created: 31/Mar/14  Updated: 31/Mar/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 bakura10:

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

Message:

Hi,

ping @guillhermoblanco : I think this may be blocking for 2.5

I introduced not so long ago support for ManyToMany for Criteria. However, I realized my implementation was really incomplete, because I hard-coded the "=" operator (https://github.com/doctrine/doctrine2/pull/885/files#diff-982b7374bbe9d5f4b6b71f4869a446eaR575). This means that it fails in a lot of cases when you use something different than "eq" for Criteria.

This PR fixes that, however it's a bit hacky. The SqlExpressionVisitor was made by type hinting for a BasicEntityPersister, preventing us from using us for a collection persister. Therefore I added a new interface to keep BC.

There is also a lot of code duplication (the whole "getSelectConditionSQL" was copied from the BasicEntityPersister), but without trait or BC, I have no idea about how to solve it.

All tests pass, test were added for other operators.






[DDC-3061] [GH-996] [DDC-3027] Embedded in MappedSuperclass Created: 31/Mar/14  Updated: 03/Apr/14

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mappedsuperclass, mapping


 Description   

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

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

Message:

The fields from the MappedSuperclass embedded properties are getting mapped directly into the MappedSuperclass fields causing the error.

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






[DDC-3060] [GH-995] Allow cascaded clearing of associated Entities Created: 30/Mar/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/1cd0b26a40dc22b0d11b1860eb058ab9cdc29f36 this issue is fixed.





[DDC-3059] [GH-994] Update EntityGenerator comment Created: 29/Mar/14  Updated: 29/Mar/14  Resolved: 29/Mar/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

fieldVisibility was referred to as a boolean, where it is actually a string.



 Comments   
Comment by Doctrine Bot [ 29/Mar/14 ]

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

Comment by Marco Pivetta [ 29/Mar/14 ]

https://github.com/doctrine/doctrine2/commit/da96f4938a9c6d0fe5c14fa45c28bac35e627358





[DDC-3058] [GH-993] Update JoinColumn.php Created: 28/Mar/14  Updated: 28/Mar/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 KamilKopaczyk:

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

Message:

If $referencedColumnName = 'id' by default, it doesn't make sense to make checks like:
```php
if (empty($joinColumn['referencedColumnName'])) {
```
(ClassMetaDataInfo file)


Considering you map your column
```
@ORM\JoinColumn(onDelete="CASCADE")
```
You'll get JoinColumn with 'id' value, which doesn't let doctrine use naming strategies for referenced column names






[DDC-3057] [GH-992] Fixed typos Created: 28/Mar/14  Updated: 28/Mar/14  Resolved: 28/Mar/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed 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/992

Message:



 Comments   
Comment by Doctrine Bot [ 28/Mar/14 ]

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

Comment by Marco Pivetta [ 28/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/8f688509c83f2176d0c3bb01f024ddf021d36c93





[DDC-3056] Return value mismatch between code under HHVM and Zend Created: 28/Mar/14  Updated: 28/Mar/14

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

Type: Bug Priority: Major
Reporter: Andy hunt Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: hhvm, orm, paginator
Environment:

Two environments:
LAMP stack with PHP 5.4.25 on Ubuntu 12.04
HHVM 3.0.0.-dev (rel) ob Ubuntu 12.04



 Description   

The following code produces differing results under Zend and HHVM runtimes.

// $all::build uses the query builder to select all entities of a type
/** @var \Doctrine\ORM\Query $query **/
$query = $all->build($qb);
$query->setMaxResults($pageSize)->setFirstResult($start);

$paginator = new Paginator($query);
$results = array_values((array)$paginator->getIterator());

Under Zend, $results is a 1-dimensional array containing N elements:
[1, 2, 3].

Under HHVM, $results is a 2-dimensional array containing a single array, containing N elements:
[ [1,3,3] ]



 Comments   
Comment by Christophe Coevoet [ 28/Mar/14 ]

I suggest reporting it to the HHVM team as a bug

Comment by Marco Pivetta [ 28/Mar/14 ]

Also: why are you using an array cast and not iterator_to_array?

Comment by Christophe Coevoet [ 28/Mar/14 ]

@Marco this should be equivalent. Casting a Traversable to array should traverse it. If HHVM does not do it, it is a bug.

Comment by Marco Pivetta [ 28/Mar/14 ]

Christophe Coevoet not really: http://3v4l.org/Z3t4t





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

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

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


 Description   

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



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

Hilz Simon did you try this with master as well?





[DDC-3054] [GH-991] Ability to define custom functions with callback instead of class name Created: 27/Mar/14  Updated: 27/Mar/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 mnapoli:

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

Message:

Right now the only way to define custom DQL functions is by giving the class name, and Doctrine will create the class:

```php
$config->addCustomNumericFunction('FOO', 'My\Custom\DqlFunction');
```

This is very limiting when the custom functions has dependencies, for example it can't be created by a DI container.

The approach I have taken here is very simple: it allows to define a callback instead of the class name: the callback will be called and it should return the instance:

```php
$config->addCustomNumericFunction('FOO', function($funcName)

{ return new My\Custom\DqlFunction($funcName); }

);
```

On a side note, I think it would be great to generalize that approach because currently there are a lot of places where the same constraints apply.






[DDC-3053] [GH-990] Typo in documentation Created: 27/Mar/14  Updated: 27/Mar/14  Resolved: 27/Mar/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This method from AbstractQuery accepts constants from ClassMetadata rather than string



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

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

Comment by Marco Pivetta [ 27/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/ca19db34d2bdea7b661fdd05f0e0991feca80a0c





[DDC-3052] [GH-989] Fix the problem when the lifecycle event can be triggered more then once... Created: 26/Mar/14  Updated: 26/Mar/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 dyangrev:

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

Message:

We recently saw the postUpdate event get trigger multiple time incorrectly, it typically happens when flushing a set of entities persisted whose listener persist and flush another type of entity in it.

Php passes variables to foreach by value, for the function executeUpdates in the UnitOfWork, for example, entities in the $this->entityUpdates could be updated and unset in the listener of the first entity, while them will be updated and trigger listeners again when the process of first entity finishes (although they have already been unset from $this->entityUpdates). Similar for executeInsertion and executeDeletion.






[DDC-3051] PersistentCollection::removeElement() leads to deletion of element, even if it is re-added via add() Created: 26/Mar/14  Updated: 27/Mar/14  Resolved: 26/Mar/14

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

Type: Bug Priority: Minor
Reporter: Daniel Richter Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

PersistentCollection::removeElement() leads to deletion of element, even if it is re-added via add(). This is because internally the element is scheduled for orphan deletion. This leads to unexpected effects, because until the UOW is committed, the relationships are re-established, but after the element is gone.

Suggested fix would be to add the ability to un-schedule an orphan removal and call this from the add() method.



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

This has been normal behavior for a lot of time now. The correct approach is to either avoid removal of the associated object from the collection or re-persisting the object (manually) after having it removed from the collection.

Comment by Daniel Richter [ 26/Mar/14 ]

I worked around by cloning the object, but still I find this unnecessarily inconsistent.

For example:

$order = new Order(); //new object working with ArrayCollection internally
$promotion = new Promotion();

//a sequence of events which might be distributed over different areas of code
$order->addPromotion($promotion);
$order->removePromotion($promotion);
$order->addPromotion($promotion);

$em->persist($order);
$em->flush();

//at this point $promotion is persisted properly.

Compare this to the same sequence of events, but an order that was loaded from the database:

$order = $repository->find(1); //existing order, working with PersistentCollection internally
$promotion = new Promotion();

//same sequence of events
$order->addPromotion($promotion);
$order->removePromotion($promotion);
$order->addPromotion($promotion);

$em->flush();

//now the promotion will NOT be persisted, even though $order->getPromotions() will still return it.

To me this violates the idea that Doctrine stays out of your way and lets you work with your domain objects without worrying too much about the persistence details.

Comment by Marco Pivetta [ 26/Mar/14 ]

Daniel Richter The problem is pretty much the same as creating/removing any element in the object graph.
OrphanRemoval currently allows removal of items from the object graph, and the assumption is that these items will be "gone" when this happens.

To have something like what you are suggesting (persist on addition to a collection) we would need another similar (complementary) feature that doesn't affect OrphanRemoval at all.

OrphanRemoval just works like it should: if you want to propose a complementary functionality, please open a new issue.

Comment by Daniel Richter [ 27/Mar/14 ]

I appreciate your time and response. I don't want to be complainy or unreasonable, but I'm not sure my point has come across.

The persist is happening properly, via cascase: persist. No issue there.

The issue is that the object in question ($promotion in my example) is not an orphan, but still it is removed. I would expect orphan removal to look at the orphan status of objects at the time of the commit, not whether at any point an object has become temporarily detached. I don't think it is reasonable in a large OOP application to keep track of relationship changes during the course of a transaction, it should only matter what the relationships are at the time of the commit.

My suggestion of simply "unscheduling" the orphan removal seems a simple addition to the PersistentCollection. Schedule on removal, unschedule on addition. This seems consistent and symmetric.
I would be happy to submit a PR with this addition, I just want to make sure I understand your objection first.

Thank you for helping me understand.

Comment by Marco Pivetta [ 27/Mar/14 ]

Daniel Richter it could work if the PersistentCollection kept track of removed entities.

You can try with a pull request, but I'm not sure if the feature is going to be accepted by the lead.

Giving it a try won't hurt though, and adding a PersistOnAdd (or something like that) would eventually also be acceptable in my opinion.





[DDC-3050] between does not support literal in first argument Created: 26/Mar/14  Updated: 26/Mar/14  Resolved: 26/Mar/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Bug Priority: Trivial
Reporter: Ryan Korczykowski Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

MySQL



 Description   

This may not be a bug since this feature may not be portable.

The following dql results in an error:

select e from Entity e 
where '2011-01-01' BETWEEN e.periodStart AND e.periodEnd

[Syntax Error] line 0, col 263: Error: Expected =, <, <=, <>, >, >=, !=, got 'BETWEEN'

If I replace the date literal with a bound param it will work as expected.



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

We discourage usage of magic constants in DQL, as well as any form of inclusion of parameters in DQL strings via string concatenation.





[DDC-3049] [GH-988] Exporter support for association fetch modes Created: 26/Mar/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

As reported here: http://www.doctrine-project.org/jira/browse/DDC-3047

Also noticed the fetch modes were not supported for PHP and YAML exporters.



 Comments   
Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Guilherme Blanco [ 16/Apr/14 ]

Merged as of https://github.com/doctrine/doctrine2/commit/4029dc2ea807b1d2ac170b02f36838eb02464004





[DDC-3048] [GH-987] Fixes typo in dql-doctrine-query-language.rst Created: 25/Mar/14  Updated: 25/Mar/14  Resolved: 25/Mar/14

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

Type: Documentation Priority: Trivial
Reporter: Doctrine Bot Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Changes "If you a query" to "If you have a query"



 Comments   
Comment by Doctrine Bot [ 25/Mar/14 ]

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

Comment by Steve Müller [ 25/Mar/14 ]

Fixed in commit: https://github.com/doctrine/doctrine2/commit/048c56bdb0e586524747913360d9063e7df53cc3





[DDC-3047] XML Exporter driver does not export association fetch-mode Created: 25/Mar/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Minor
Reporter: Menno Holtkamp Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

While exporting (annotations based) metadata to XML, the 'fetch-mode' of the associations seems to be skipped by the XML Exporter
https://github.com/doctrine/doctrine2/blob/927d69b61a520e939c2f2e4105329907850e61fa/lib/Doctrine/ORM/Tools/Export/Driver/XmlExporter.php#L234

This should result in an XML attribute named 'fetch' of type 'fetch-type': https://github.com/doctrine/doctrine2/blob/927d69b61a520e939c2f2e4105329907850e61fa/doctrine-mapping.xsd#L277

Will try to come up with a PR + test



 Comments   
Comment by Menno Holtkamp [ 26/Mar/14 ]

Auto-created issue with PR: http://www.doctrine-project.org/jira/browse/DDC-3049

Comment by Guilherme Blanco [ 16/Apr/14 ]

Merged as of https://github.com/doctrine/doctrine2/commit/4029dc2ea807b1d2ac170b02f36838eb02464004





[DDC-3046] The flushed data is not available immediately for querying Created: 25/Mar/14  Updated: 25/Mar/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: alex Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

ubuntu 13.10, mysql 5.5.35



 Description   

Doctrine's persisted data is not accessible by other queries immediately, for details see http://stackoverflow.com/questions/22618689/doctrines-persisted-data-is-not-accessible-by-other-queries-immediately






[DDC-3044] [GH-986] Add last modified time for metadata Created: 22/Mar/14  Updated: 22/Mar/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 c960657:

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

Message:

This patch improves performance during development and does not affect production performance.

Currently, enabling the metadata cache during development gives a remarkable performance boost, but it requires that you manually flush the metadata cache when the metadata has been changed. When running console commands such as ``console orm:schema-tool:update`` (see #979).

With this change, metadata entries fetched from cache are checked for freshness using a quick last modified check. This is much faster than loading the actual metadata using the metadata driver. This allows you to enable the metadata cache during development without the need for manually flushing the metadata cache.

This PR is part 1 of 2. Part 2 is for the doctrine/common repository.

If this PR is accepted, it allows us to optimize the auto-generate proxy classes feature by comparing the last modified time for the metadata with the modified timestamp of the generated file.






[DDC-3043] [GH-985] [WIP] [DDC-3042] SQL Alias collisions in DQL Created: 21/Mar/14  Updated: 04/Apr/14  Resolved: 21/Mar/14

Status: Resolved
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: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-3042 select issue field names with numbers Resolved

 Description   

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

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

Message:

Verifies DDC-3042

Still WIP, no fixes so far.



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

Dupe of DDC-3042

Comment by Doctrine Bot [ 04/Apr/14 ]

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





[DDC-3042] select issue field names with numbers Created: 21/Mar/14  Updated: 04/Apr/14  Resolved: 04/Apr/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3.3, 2.4.1, 2.4.2
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Critical
Reporter: Marc Lindemann Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3043 [GH-985] [WIP] [DDC-3042] SQL Alias c... Resolved

 Description   
$qb = $this->_em->createQueryBuilder();
$qb->select('k.aktiv, k.id, k.firma, k.firma2, k.strasse, k.plz, k.ort, k.plzpostfach, k.postfach, k.bemerkung,
         k.uuid, k.telefon,k.telefonzentrale, k.istmutter, k.isttochter, k.email, k.internet, k.fax, l.id as land, m.id as mutter, m.firma as mutterv, t.id as tochter, t.firma as tochterv, kg.id as kundengruppe, s.id as sic, s.title as sicv,
         kg.title as kundengruppev,m.telefon as telefonmutter,t.telefon as telefontochter, k.id as kdnr')

will create this sql:

SELECT c0_.id AS id0, c0_.aktiv AS aktiv1, c0_.firma AS firma2, c0_.firma2 AS firma23, c0_.strasse AS strasse4, c0_.plz AS plz5, c0_.ort AS ort6, c0_.plzpostfach AS plzpostfach7, c0_.postfach AS postfach8, c0_.hotel AS hotel9, c0_.kuerzel AS kuerzel10, c0_.stornofrist AS stornofrist11, c0_.uuid AS uuid12, c0_.telefon AS telefon13, c0_.telefonzentrale AS telefonzentrale14, c0_.istmutter AS istmutter15, c0_.isttochter AS isttochter16, c0_.trainer AS trainer17, c0_.email AS email18, c0_.internet AS internet19, c0_.fax AS fax20, l6_.id AS id21, c3_.id AS id22, c3_.firma AS firma23, c3_.telefon AS telefon24, c0_.id AS id25, t1_.content AS anfahrt26, t2_.content AS beschreibung27 

as you see, it will create co.firma2 as firma23 and c3_.firma AS firma23,

now when you do:

$query = $qb->getQuery();
$result = $query->getArrayResult();
Array
(
    [0] => Array
        (
            [id] => 11
            [aktiv] => 1
            [firma] => Test GmbH
            [mutterv] => Mutter Test
            [strasse] => 
            [plz] => 
            [ort] => 
            [plzpostfach] => 
            [postfach] => 
            [hotel] => 
            [kuerzel] => 
            [stornofrist] => 0
            [uuid] => 524459b5-7f1c-442b-98dd-3d5cc0a81420
            [telefon] => 0211/415583810
            [telefonzentrale] => 
            [istmutter] => 
            [isttochter] => 
            [trainer] => 
            [email] => 
            [internet] => 
            [fax] => 
            [land] => 3
            [mutter] => 
            [telefonmutter] => 
            [kdnr] => 11
            [anfahrt] => 
            [beschreibung] => 
        )
)

when i change the order of the select , it will work

 $qb->select('k.id, k.aktiv, k.firma, k.strasse, k.plz, k.ort, k.plzpostfach, k.postfach, k.hotel, k.kuerzel, k.stornofrist,  k.firma2,
         k.uuid, k.telefon,k.telefonzentrale, k.istmutter, k.isttochter, k.trainer, k.email, k.internet, k.fax, l.id as land, m.id as mutter, m.firma as mutterv,
         m.telefon as telefonmutter, k.id as kdnr, k.anfahrt, k.beschreibung')


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

Marc Lindemann can you reduce the example to only the fields that are affected? Does this affect also latest ORM?

Comment by Marc Lindemann [ 21/Mar/14 ]

Marco, the Problem only exists when you select like my example

c0_.id AS id0, c0_.aktiv AS aktiv1, c0_.firma AS firma2, (...),  c0_.firma2 AS firma23, 

as you see "firma2" is on the fourth place so it´s selected as "firma23", "m.firma" is on place 24, so it´s also selected as "firma23" (m.firma as mutterv)

Comment by Marco Pivetta [ 21/Mar/14 ]

Marc Lindemann ah, I see it now. This probably requires a change in how the DQL is generated by prefixing numerical indexes with something like an `_`.

Comment by Marco Pivetta [ 21/Mar/14 ]

Marc Lindemann I provided a fix at https://github.com/doctrine/doctrine2/pull/985 - can you try it?

Comment by Marc Lindemann [ 24/Mar/14 ]

Yeah, this works.

Comment by Doctrine Bot [ 04/Apr/14 ]

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

Comment by Marco Pivetta [ 04/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/bfb66f1d85509db9e24ce33e30382c8cccaf2dd7





[DDC-3041] [GH-984] Use boolean values for 'unique' attribute Created: 20/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

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


 Description   

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

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

Message:

As defined in: https://github.com/doctrine/doctrine2/blob/master/doctrine-mapping.xsd#L294

Same as 'nullable' attribute.

It was being exported as a "1" for TRUE and "0" for false



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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





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

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

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


 Description   

I have some fields like

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

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

@ORM\Column -> nullable=false

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

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

answer:

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

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

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

answer:

ALTER TABLE test CHANGE added_at added_at DATETIME NOT NULL;



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

have some news about this problem ?

Comment by Marco Pivetta [ 06/Apr/14 ]

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

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

or if i use additional bundle

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

                    Application Migrations


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

  ++ migrating 20140407004542

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

  ++ migrated (3.46s)

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

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

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

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

Comment by Coroliov Oleg [ 07/Apr/14 ]

Steve Müller, you right. Thanks.





[DDC-3039] [GH-983] Added MEMBER OF and INSTANCE OF to ExpressionBuilder Created: 19/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

As announced in https://groups.google.com/forum/#!topic/doctrine-dev/GhusGQDUU7Q



 Comments   
Comment by Doctrine Bot [ 20/Mar/14 ]

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





[DDC-3038] [GH-982] Failing Test (since commit 53a5a48aed7d87aa1533c0bcbd72e41b686527d8) Created: 18/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

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


 Description   

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

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

Message:

It seems there is a regression since the commit https://github.com/doctrine/doctrine2/commit/53a5a48aed7d87aa1533c0bcbd72e41b686527d8#commitcomment-5696972

Doctrine\ORM\PersistentCollection can be populated in $changeSet if you set a PreUpdate and PostUpdate event. It was not the case before.

Original issue: http://www.doctrine-project.org/jira/browse/DDC-3033



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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

Comment by Doctrine Bot [ 23/Mar/14 ]

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

Comment by Doctrine Bot [ 23/Mar/14 ]

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





[DDC-3037] cslssl Created: 18/Mar/14  Updated: 18/Mar/14  Resolved: 18/Mar/14

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

Type: Bug Priority: Major
Reporter: Cslssl Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None





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

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

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


 Description   

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






[DDC-3035] [GH-981] Throw exepction for invalid mappedBys rather than PHP undefined index warning Created: 17/Mar/14  Updated: 17/Mar/14  Resolved: 17/Mar/14

Status: Resolved
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: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:

This fix throws an appropriate MappingException with an explanation of what is wrong with the mapping rather than just throwing an un-actionable php warning.

Example old error message: "Undefined index: item in /www/apps/rwriter/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php on line 2079���

Example new MappingException message: ���Property items in RcmShoppingCart\Entity\TempOrder specified mappedBy="tempOrderItem" but tempOrderItem is not a property of RcmShoppingCart\Entity\TempOrderItem���



 Comments   
Comment by Doctrine Bot [ 17/Mar/14 ]

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





[DDC-3034] QueryBuilder invalid number of bound params Created: 17/Mar/14  Updated: 17/Mar/14  Resolved: 17/Mar/14

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

Type: Bug Priority: Minor
Reporter: Mike Zukowsky Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: orm, querybuilder
Environment:

PHP 5.4.16, Zend Framework 2.2.5, Doctrine ORM Module 0.8.0



 Description   
    /**
     * @param int  $companyId
     * @param bool $includeDeleted
     * @return \Doctrine\ORM\QueryBuilder
     */
    public function findCompanySubjects($companyId, $includeDeleted = false)
    {
        $qb=$this->createQueryBuilder('t')
            ->addSelect('owner')
            ->innerJoin('t.owner', 'owner')
            ->innerJoin('owner.company', 'company')
            ->andWhere('t.deleted = :deleted')
            ->andWhere('company.id = :id')
            ->orderBy('t.name', 'asc')

            ->setParameter('deleted', $includeDeleted)
            ->setParameter('id', $companyId)
        ;

        return $qb;
    }

Code above does not work for me. I'm still getting an error "Invalid parameter number: number of bound variables does not match number of tokens". However, bound parameters does work with raw DQL and the Query object.



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

Mike Zukowsky what is the complete DQL that is produced for that query? And does it work with a DQL query written directly (rather than the QB)?

Comment by Mike Zukowsky [ 17/Mar/14 ]

Raw DQL is:

SELECT t, owner FROM Domain\Entity\Subject t INNER JOIN t.owner owner INNER JOIN owner.company company WHERE t.deleted = :deleted AND company.id = :id ORDER BY t.name asc

And yes, it does work with a DQL query written directly:

        // $qb from above

        $query=$qb->getQuery()->setParameters(array(
            'deleted' => $includeDeleted,
            'id'      => $companyId
        ));

        debug($query->getArrayResult()); // returns a list of subjects
Comment by Marco Pivetta [ 17/Mar/14 ]

You are returning the QB in your reported code - I'm pretty sure that some interaction with it is going on at a later point in time.

Could you provide the code that is causing the problem? Otherwise, this doesn't look like a bug to me.





[DDC-3033] Regression in computeChangeSets (ManyToMany relation) Created: 17/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: 2.5, 2.4.3

Type: Bug Priority: Major
Reporter: Thomas Lallement Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: orm
Environment:

Ubuntu



 Description   

I discover that computeChangeSet doesn't compute as before from this commit:

https://github.com/doctrine/doctrine2/commit/53a5a48aed7d87aa1533c0bcbd72e41b686527d8#commitcomment-5696972

From this commit, I have a bug when using KNP doctrine behaviors (with a custom code to log the changes on Entities in Database) because when I call the following code, it doesn't return the same changeSet as before:

$uow->computeChangeSet($classMetadata, $entity);
$changeSet = $uow->getEntityChangeSet($entity);

Before the "ManyToMany" properties were not in the $changeSet. Now there are with original value NULL -> new value Doctrine\ORM\PersistentCollection. Is it normal?






[DDC-3032] [GH-980] Added options attribute export to Annotation, Xml & Yaml exporters. Created: 16/Mar/14  Updated: 13/Apr/14  Resolved: 13/Apr/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Options were already supported in annotation/xml/yaml drivers. So now they are taken into account eg in orm:convert-mapping task.



 Comments   
Comment by Doctrine Bot [ 13/Apr/14 ]

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

Comment by Marco Pivetta [ 13/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/da24133306d0b5d313605a7f4c501399ced25198





[DDC-3031] ORM does not understand constants in SELECT clause Created: 15/Mar/14  Updated: 15/Mar/14  Resolved: 15/Mar/14

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

Type: Bug Priority: Major
Reporter: Roman Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: dql, orm


 Description   

It seems that doctrine do not understand constants in SELECT clause.
I try to execute such a query:

SELECT e.id, 'abc' as flag FROM SomeEntity

And I get this error:

[Semantical Error] line 0, col 40 near 'parent, p.weight,': Error: Invalid PathExpression. Must be a StateFieldPathExpression.

There was an issue like this a long time ago: DDC-1077. It's written that it was Resolved, but it does not work.



 Comments   
Comment by Roman [ 15/Mar/14 ]

Sorry, that was my mistake. It works fine!





[DDC-3030] [GH-979] Bypass metadata cache in console commands Created: 15/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

The console commands use the metadata cache. If the metadata has been updated, you manually need to run ``console orm:clear-cache:metadata``.

For most commands, e.g. ``console orm:schema-tool:update``, this is rather annoying. I don't see any good reason why you would generate queries to make your database match the stale metadata in the cache rather than the fresh metadata stored in files.

This patch disables the metadata cache for most commands.



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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





[DDC-3029] DISTINCT , ORDER BY AND Limit in SQL Server Created: 14/Mar/14  Updated: 14/Mar/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: Michał Banaś Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File SQLServerPlatform.php    

 Description   

I don't know if I should report it here , becouse error is in SQLServerPlatform.php file.
basicaly Distinct includes ROWNUM()
So if you add distinct in DQL it will be translated to "select distinct ...... , Rownum()" - which is always distinct offcource.

Here is original version
protected function doModifyLimitQuery($query, $limit, $offset = null)
{
if ($limit > 0) {
if ($offset == 0)

{ $query = preg_replace('/^(SELECT\s(DISTINCT\s)?)/i', '\1TOP ' . $limit . ' ', $query); }

else {
$orderby = stristr($query, 'ORDER BY');

if ( ! $orderby)

{ $over = 'ORDER BY (SELECT 0)'; }

else

{ $over = preg_replace('/\"[^,]*\".\"([^,]*)\"/i', '"inner_tbl"."$1"', $orderby); }

// Remove ORDER BY clause from $query
$query = preg_replace('/\s+ORDER BY(.*)/', '', $query);
$query = preg_replace('/^SELECT\s/', '', $query);

$start = $offset + 1;
$end = $offset + $limit;

$query = "SELECT * FROM (SELECT ROW_NUMBER() OVER ($over) AS doctrine_rownum, $query) AS doctrine_tbl WHERE doctrine_rownum BETWEEN $start AND $end";
}
}

return $query;
}
In Attachenment there is a fixed version of this file.






[DDC-3028] [GH-978] [DDC-2987] Enable empty prefixes for inlined embeddable Created: 13/Mar/14  Updated: 16/Mar/14  Resolved: 16/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This fixes DDC-2987

This makes it possible to map a field from an embeddable to a database field with the same name, without any prefix added.

Example:

  • an embeddable object "Id" with a property "id"
  • per default this would map inline to id_id
  • supplying null or '' as columnPrefix does not work due to the ! empty() check
  • with my little change, if columnPrefix : false is supplied in the mapping config this will now map to a db column "id"

To build Ids as ValueObjects is a very common approach in DDD, so ihmo this is a must have.



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

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

Comment by Guilherme Blanco [ 16/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/383604d4b804017248e10bd7ae8489af4185e9e8





[DDC-3027] Embeddables on mapped supper classes Created: 13/Mar/14  Updated: 13/Mar/14

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

Type: Bug Priority: Minor
Reporter: Antoine Hedgecock Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Deb 7.3, php 5.5.10-1~dotdeb



 Description   

If you have a embeddable on a mapped superclass you get the following error

<?xml version="1.0" encoding="utf-8"?>
<doctrine-mapping>
    <embeddable name="DealFinder\Core\ValueObject\Coordinates">
        <field name="latitude"  type="float" precision="10" scale="6" nullable="true"/>
        <field name="longitude" type="float" precision="10" scale="6" nullable="true"/>
    </embeddable>
</doctrine-mapping>
Doctrine\ORM\Mapping\MappingException: Duplicate definition of column 'coordinates_latitude' on entity 'DealFinder\Location\Entity\LocationEntity' in a field or discriminator column mapping.

Moving it to the entity mapping resolves the issues but gives you duplicated code.






[DDC-3026] Provide DQL TYPE() function to access discriminator column value Created: 12/Mar/14  Updated: 12/Mar/14  Resolved: 12/Mar/14

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

Type: New Feature Priority: Minor
Reporter: Nils Adermann Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: dql


 Description   

It is not currently possible to figure out which type a value is associated with if you do not wish to perform object hydrations. There should be a TYPE() function in DQL which returns the value of the discriminator column or the associated class name, e.g

SELECT u.id, TYPE(u) FROM Some\Base\Class u

which would return

[[1, 'foo'], [2, 'bar']]

if there were two classes foo and bar which inherit from the base class.



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

I'd add that these should be 2 functions:

  • TYPE(e) gives you the class name for a given fetched result
  • DISCRIMINATOR(e) gives you the discriminator value for a given fetched result
Comment by Benjamin Eberlei [ 12/Mar/14 ]

Not an issue or something to add as a new feature. There is no way to get the discriminator value.





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

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

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


 Description   

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

These commands :

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

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

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

Suggested changes :

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





[DDC-3024] Proxy Notice if none of joined tables are primary Created: 11/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
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: Nima Sadjadi Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: orm, proxy
Environment:

nix* server with php 5.3.x



 Description   

In case of ManyToOne/OneToMany if NONE of joined coloumns are primary it throws a proxy notice:
NOTICE: Undefined index: id in /vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php on line 121
Can be replicated this by running:
$somethings = $em->getRepository('Entities\Something')->findBy(array('productId' => "4"));

Something entity is ManyToOne to another OneToMany entity, and this productId is primary on NONE of these two entities/tables.



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

As discussed on the mailing list, this issue requires a failing test case to be confirmed.

Comment by Nima Sadjadi [ 12/Mar/14 ]

I am trying to do so Marco, but I am stuck for $metadata thing I said in that thread, as soon as you advice how to fix that, I will be able to run a failing test.

Comment by Benjamin Eberlei [ 23/Mar/14 ]

not using the primary for the joined columns is not supported and the SchemaValidator already gives an error about that. Runtime checks are not possible here.





[DDC-3023] [GH-977] Fix wrong annotation Created: 11/Mar/14  Updated: 11/Mar/14  Resolved: 11/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Without above fix I'm getting
"[Semantical Error] The annotation "@array" in method Doctrine\ORM\Mapping\ClassMetadataInfo::mapEmbedded() was never imported. Did you maybe forget to add a "use" statement for this annotation?"



 Comments   
Comment by Doctrine Bot [ 11/Mar/14 ]

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

Comment by Marco Pivetta [ 11/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/b30b1a59991c15043f14053acbe7d93c6233465c





[DDC-3022] JOIN without association generates invalid SQL Created: 11/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Bug Priority: Major
Reporter: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: sql-walker


 Description   

I saw in the documentation than since Doctrine 2.4 we could join without associations, using fields.

However I tried it and it generates invalid SQL (I use master). Here is an example:

SELECT a
FROM Namespace\Article a
JOIN Namespace\Authorization authorization WITH a.id = authorization.entityId

Generates the following SQL:

SELECT a0_.id AS id0 FROM Article a0_ INNER JOIN Authorization a1_ AND (a0_.id = a1_.entityId)

As you can see, instead of "INNER JOIN ... ON ..." we have "INNER JOIN ... AND ..." which is invalid.

I can't say if it's a regression of 2.5, or already in 2.4. I can't test my project with 2.4 because I used embedded objects.



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

I wrote a test at https://github.com/doctrine/doctrine2/compare/hotfix;DDC-3022-wrong-arbitrary-join-sql and it doesn't look like the bug is there.

Check your mappings and verify that everything is correct, or alter the given test case to make it fail.

Comment by Matthieu Napoli [ 11/Mar/14 ]

Thank you for trying and sorry for wasting your time _ I had forgotten an empty discriminator map on the "Authorization" class. For my defense the error was kind of weird

It's all good, no bug here.





[DDC-3021] [GH-976] Add cache invalidation strategy to AbstractQuery Created: 11/Mar/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

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


 Description   

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

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

Message:

By adding the cached timestamps of the involved entity tables to the query hash, we will invalidate the cache when any of those tables have changed.



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Closed, see : https://github.com/doctrine/doctrine2/pull/976





[DDC-3020] simplexml_load_file(): I/O warning: failed to load external in XmlDriver.php Created: 11/Mar/14  Updated: 14/Mar/14  Resolved: 11/Mar/14

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

Type: Bug Priority: Blocker
Reporter: Rubens Matrono Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None
Environment:

PHP 5.5.9-1~dotdeb.1 (cli) (built: Feb 9 2014 21:29:47)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies

Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux



 Description   

PHP Warning: simplexml_load_file(): I/O warning : failed to load external entity "/path-to/doctrine/entities/mappings/my_entity.dcm.xml" in /path-to/lib/Doctrine/ORM/Mapping/Driver/XmlDriver.php on line 711

PHP bug:
https://bugs.php.net/bug.php?id=62577

Possible solution:
https://github.com/owncloud/core/pull/7498/files



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

You are not supposed to load external entities in mappings.

Also, mappings are not user input, therefore they are not valid XXE/XEE attack vectors.

Comment by Marco Pivetta [ 11/Mar/14 ]

Deployed a docs fix at https://github.com/doctrine/doctrine2/commit/02daf0049adff040259f1fe86c6a0c846a68c3c1

Comment by Rubens Matrono [ 11/Mar/14 ]

this is not a bug in Doctrine, who wants a quickfix can create a custom driver and force import of XXE/XEE before drivers are used:

class MyQuickFixXmlDriver extends \Doctrine\ORM\Mapping\Driver\XmlDriver
{
    /**
     * {@inheritDoc}
     */
    public function loadMetadataForClass($className, ClassMetadata $metadata)
    {
        $loadEntities = libxml_disable_entity_loader(false);
        parent::loadMetadataForClass($className, $metadata);
        libxml_disable_entity_loader($loadEntities);
    }
} 




[DDC-3019] [GH-975] Added info about automatic discriminator map Created: 11/Mar/14  Updated: 11/Mar/14  Resolved: 11/Mar/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

see https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L257



 Comments   
Comment by Doctrine Bot [ 11/Mar/14 ]

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

Comment by Marco Pivetta [ 11/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/87505c8716bf7df2f7d7c77e8f9a7657571bce78





[DDC-3018] DQL “NEW” Operator and Literal type "String" Created: 09/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.4, Git Master, 2.5
Fix Version/s: 2.5, 2.4.3
Security Level: All

Type: Bug Priority: Major
Reporter: harleaux Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: dql, orm


 Description   

Hello all,

When i use the DQL operator "new" to build data transfert object with string literal expression as field in object constructor, the call to Query::getResult thrown an exception.

Condition :
The string literal expression must be the first parameter of the constructor.

Following DQL :

$query = $em->createQuery('SELECT NEW CustomerDTO('some scalar string', c.name, c.email) FROM Customer c');

$users = $query->getResult();

Thrown exception :

ContextErrorException: Notice: Undefined variable: fieldType in doctrine/orm/lib/Doctrine/ORM/Query/SqlWalker.php line 1527

That happens because in SqlWalker::walkNewObject on the AST\Literal switch case. There is no case for AST\Literal::STRING, so $fieldType isn't defined.

I have also noted if the scalar string isn't the first parameter, $fieldType take the type of previous foreach element.



 Comments   
Comment by Benjamin Eberlei [ 23/Mar/14 ]

Fixed and merged into 2.4 release branch





[DDC-3017] UnitOfWork::$entityIdentifiers does not get updated when saving composite PK with a JoinColum as PK Created: 08/Mar/14  Updated: 31/Mar/14  Resolved: 23/Mar/14

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

Type: Bug Priority: Critical
Reporter: Thomas Rabaix Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

The Sonata Admin Bundle rely on the ``UnitOfWork::getEntityIdentifier`` method to retrieve the object identifier.

We are adding support for composite PK with a FK as described in the gist: https://gist.github.com/rande/9439778 .

The bug occurs when the Material reference is updated on the Color object. The Color has a new set of PK. However the UnitOfWork::$entityIdentifiers is not updated when the object is persisted. So the values stored ``UnitOfWork::$entityIdentifiers`` are invalid for the Color object.

The consequence is that we are unable to redirect the user once the object is saved as the UnitOfWork::getEntityIdentifier refers to the old values.



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

Thomas Rabaix can you please come up with a failing test case for this issue?

Comment by Benjamin Eberlei [ 23/Mar/14 ]

It is not supported to change the identifier. They are assumed to be immutable by Doctrine and we cannot change that, as the consequences are impossible to handle.

Comment by Thomas Rabaix [ 31/Mar/14 ]

Thanks for commenting this issue. So with composite keys the assumption is wrong and from your comment this bug is the expected behavior.

Now, should doctrine provide a secure method to retrieve the identifier keys ?

Comment by Marco Pivetta [ 31/Mar/14 ]

Thomas Rabaix shouldn't you extract identifiers via metadata by having an instance of an entity?

Comment by Thomas Rabaix [ 31/Mar/14 ]

It is what I did: https://github.com/sonata-project/SonataDoctrineORMAdminBundle/blob/master/Model/ModelManager.php#L277-L303

However it will be better to have a clean implementation in the ORM.





[DDC-3016] Criterias do not work with embeddables when matching in memory Created: 07/Mar/14  Updated: 12/Mar/14

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: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using criterias and doing the matching on a collection already loaded in memory, it will not work if filtering on embeddable objects.

Example:

    $criteria = new Criteria();
    $criteria->andWhere($criteria->expr()->eq('actions.view', true));

    $authorizations = $this->authorizations->matching($criteria);

Here the ClosureExpressionVisitor will try to get the property named >actions.view instead of >actions->view.

PHPUnit_Framework_Error_Notice : Undefined property: Tests\...\Model\ArticleAuthorization::$actions.view





[DDC-3015] [GH-974] [SLC] Resolve association cache entry Created: 07/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 07/Mar/14 ]

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





[DDC-3014] [GH-973] Added index flags support in annotation, xml & yaml mapping drivers. Created: 06/Mar/14  Updated: 13/Apr/14  Resolved: 13/Apr/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

It allows specifying eg. fulltext index for MysqlPlatform (the platform already supports it - https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L714 , but it couldn't be used in annotations/xml/yaml/php schemas). And also other platforms use flags for indexes (virtual, clustered etc.).

So now flags can be used like:

```php
/**

  • @Table(...,indexes=
    Unknown macro: {@Index(columns={"description"},flags={"fulltext"})}

    )
    */
    class Foo

    { ... }

    ```

```xml
...
<indexes>
<index name="0" columns="description" flags="fulltext"/>
</indexes>
...
```

```yml
Foo:
...
indexes:
-
columns: [ description ]
flags: [ fulltext ]
```

```php
$metadata->setPrimaryTable(array(
...
'indexes' => array(
array(
'columns' => array('description'),
'flags' => array('fulltext'),
)
),
...
));
```



 Comments   
Comment by Doctrine Bot [ 13/Apr/14 ]

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

Comment by Marco Pivetta [ 13/Apr/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/3a1e24e6801961128c27104919050d40d745030b





[DDC-3013] [GH-972] Capitalize @GeneratedValue (annotations-reference.rst) Created: 05/Mar/14  Updated: 05/Mar/14  Resolved: 05/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

`@GeneratedValue` is capitalized in the rest of the documentation.



 Comments   
Comment by Doctrine Bot [ 05/Mar/14 ]

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

Comment by Marco Pivetta [ 05/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/8d4821b4dcf05ca5a90f969b22494f42b88409c1





[DDC-3012] [GH-971] [SLC] Fix query association proxy Created: 05/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 06/Mar/14 ]

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





[DDC-3011] [GH-970] [DDC-357] Effective toOne joins Created: 05/Mar/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

Status: Resolved
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: Won't Fix Votes: 1
Labels: None

Issue Links:
Reference
relates to DDC-357 Lazy-loading in OneToOne-bidirectiona... Resolved

 Description   

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

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

Message:

  1. What is this?

I've kind of rewriten querying of toOne relations. It is more data and query-count effective.

  1. How?

Let's demonstrate it on `CmsUser` and `CmsAddress` from tests models. Let's solve behaviour for toOne relations that are not mentioned in the query.

SELECT u FROM CmsUser u
    1. lazy + mapped by side

Already implemented, result is that CmsAddress would be proxy.

    1. lazy + inverse side

`CmsUser` has `CmsAddress` relation that is mapped and owned by `CmsAddress` entity.

What has to happen? The identifier of `CmsAddress` cannot be loaded from users table nad has to be added automatic join for the table. Because it's lazy it will be hydrated as proxy, becase that is exactly what I've asked for.

If it would have been eagerly loaded, It would create 1+N queries problem that I'm trying to avoid with this. I have the relation as lazy, if I knew I would have needed it and wanned to optimized, I'd join it, but I didn't.

Result is therefore `CmsUser` entity + `CmsAddress` proxy

    1. eager - both inverse and mapped by sides

The appropriate query component is generated with autojoin and auto selecting of the entity.

If it is self-referencing, the auto join is not generated becase it would cause infinite recursion.

  1. Why?

I've given this a lot of thought and tested it on our not-so-small application. We have unfortunately lot of entitiy relations that are mapped on the inverse side than we need to select, which is effectively killing performace DDC-357(http://www.doctrine-project.org/jira/browse/DDC-357)

I would have to go and list all the entities as partials to save performace creating such monsters as this

$builder = $repository->createQueryBuilder("o")
	->leftJoin("o.voucher", "vu")->addSelect("partial vu.{id}")
	->leftJoin("o.address", "a")->addSelect("a")
	->leftJoin("o.restaurant", "r")->addSelect("partial r.{id, name}")
	->leftJoin("o.payment", "p")->addSelect("partial p.{id}")
	->leftJoin("o.rating", "rat")->addSelect("partial rat.{id}")
	->leftJoin("r.settings", "rs")->addSelect("partial rs.{id}")
	->leftJoin("r.address", "ra")->addSelect("ra")
	->leftJoin("r.position", "rp")->addSelect("partial rp.{id}");
# plus about five more just to make save performace

We all know that hydrating a large result set is a bottleneck and if I say the relation is lazy and I'm not joining it I *really don't want it to be joined with all it's data*!

Now imagine I just want to select few orders and render some data on the page.. I have tens of queries like this just because I have to. This is wrong that the ORM is tripping my feet like this.

  1. What now?

I know I have to solve theese:

  • [ ] more refactoring?
  • [ ] more tests
  • [ ] what to do with issue tests that now have changed behaviour?

Any suggestions?



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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





[DDC-3010] [GH-969] [Doc] added note about Criteria limits on PersistentCollection Created: 04/Mar/14  Updated: 05/Mar/14  Resolved: 05/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 05/Mar/14 ]

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

Comment by Marco Pivetta [ 05/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/7843eed8bc81049c68d322282a8db4b5c50faaec





[DDC-3009] [GH-968] Test: Add failing test Created: 04/Mar/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

It says in http://www.doctrine-project.org/jira/browse/DBAL-446 that this issue has been fixed, but apparently, it hasn't.



 Comments   
Comment by Doctrine Bot [ 17/Apr/14 ]

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

Comment by Guilherme Blanco [ 17/Apr/14 ]

This issue is DBAL related, not ORM.





[DDC-3008] [GH-967] [SLC] Add query builder options Created: 03/Mar/14  Updated: 04/Mar/14  Resolved: 04/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 04/Mar/14 ]

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

Comment by Marco Pivetta [ 04/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328





[DDC-3007] ManyToMany does not respect all column attributes for the jointable Created: 03/Mar/14  Updated: 03/Mar/14

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

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


 Description   

Given following 2 entities:

<?php
class Role {
    /**
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="UUID")
     * @ORM\Column(name="id", type="guid", nullable=false, unique=true, length=36, options={"fixed"=true})
     */
    protected $id;

    /**
     * @ORM\ManyToMany(targetEntity="User", mappedBy="roleList")
     */
    private $userList;
}
<?php
class User {
    /**
     * @ORM\Column(name="id", type="guid", nullable=false, unique=true, length=36, options={"fixed"=true})
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="UUID")
     */
    protected $id;

    /**     *
     * @ORM\ManyToMany(targetEntity="Role", inversedBy="userList")
     * @ORM\JoinTable(name="user_role")
    protected $roleList;
}

It should create a table "user_role" with 2 columns which are CHAR(36).

But it ignores the Column-Attributes and creates a table "user_role" with 2 CHAR(255) columns.

This has various downsides:

  • It's unusable when using MyISAM, because of limited index size. (CREATE TABLE fails, see DBAL-423)
  • If using GUID-Type (see DBAL-423 with the changes from the linked ull request) and specify "length=36" and "fixed=true" on the Column-Annotation, no changes for the entity-tables itself are generated when running orm:schema-tool:update. However, there are still changes for the many-to-many-table generated (because internal "fixed" is false and length is unset) which represent the current state of the columns. These changes are always generated.





[DDC-3005] Events::postLoad fires without filled associations Created: 02/Mar/14  Updated: 10/Apr/14

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: Artur Eshenbrener Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When we load entities throw one dql query like this:

SELECT e, joined_link FROM Entity LEFT JOIN e.link joined_link

In event subscriber, subscribed to postLoad event for instances of Entity property "link" of entity does not contains fetched in same query joined entity, and does not contains proxy object.

Tell me if failing test case needed.



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

The postLoad event is fired without warranty that association entities/proxies will be set:

http://docs.doctrine-project.org/en/latest/reference/events.html#lifecycle-events

Comment by Artur Eshenbrener [ 03/Mar/14 ]

But why? This shounds like involuntary restriction, and I think it can be fixed. Will my PR with fix accepted, or collaborators don't want to change this behaviour?

Comment by Marco Pivetta [ 03/Mar/14 ]

Artur Eshenbrener triggering `postLoad` in the correct moment in time (when all dependencies are loaded) requires a lot of additional complexity to be inserted in various locations of the ORM.

Since `postLoad` is supposed to be used like `__wakeup` and in general for simple tasks, this kind of refactoring/rewrite would be an overkill.

Comment by Artur Eshenbrener [ 04/Mar/14 ]

> requires a lot of additional complexity to be inserted in various locations of the ORM.
Sounds like "It is very hard to implement, and no one want to do this"

> and in general for simple tasks, this kind of refactoring/rewrite would be an overkill.
Disagree with this. Why only simple? I need to deal with associations in this event. Without this I should inject whole EntityManager to my entity, but I dont want to do this.

And I forced to repeat the question: will PR with fix accepted or not?

Comment by Marco Pivetta [ 04/Mar/14 ]

Sounds like "It is very hard to implement, and no one want to do this"

Not really, the main problem here is performance, since hydration would have to be completely redesigned.
Yes, "too hard" is a good reason for something that is an edge case.

And I forced to repeat the question: will PR with fix accepted or not?

Sure thing! Just needs to avoid a massive rewrite though.

Comment by Marco Pivetta [ 04/Mar/14 ]

To give you some hints, Doctrine\ORM\Events::postLoad is triggered in https://github.com/doctrine/doctrine2/blob/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328/lib/Doctrine/ORM/UnitOfWork.php#L2788, and Doctrine\ORM\UnitOfWork#createEntity() is used by all the various hydrators internally.

To ensure that Doctrine\ORM\Events::postLoad is triggered after an entity is fully loaded, the various hydrators must trigger the events after being sure that all data has been set, and that the entity is "ready" for use. That's some copy-paste work :\

Comment by Artur Eshenbrener [ 04/Mar/14 ]

I think the entry point is here: https://github.com/doctrine/doctrine2/blob/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php#L140,
so, copy-paste work is not needed )

Comment by Artur Eshenbrener [ 05/Apr/14 ]

PR is ready: https://github.com/doctrine/doctrine2/pull/1001





[DDC-3004] [GH-966] Simplify build matrix Created: 01/Mar/14  Updated: 02/Mar/14  Resolved: 02/Mar/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-2958 [GH-936] [WIP] Making testing depende... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 02/Mar/14 ]

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

Comment by Marco Pivetta [ 02/Mar/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/63d849b6f0142b341ea85b2c339ad86754911fd2





[DDC-3003] [GH-965] [SLC] Add support for criteria Created: 01/Mar/14  Updated: 01/Mar/14  Resolved: 01/Mar/14

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 01/Mar/14 ]

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





[DDC-3002] [GH-964] [SLC][DDC-2943] Disable slc for pagination queries Created: 01/Mar/14  Updated: 01/Mar/14  Resolved: 01/Mar/14

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

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


 Description   

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

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

Message:

Disable slc for pagination count queries

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



 Comments   
Comment by Doctrine Bot [ 01/Mar/14 ]

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





[DDC-3001] Date and string values in insert statement are between double quotes (" ") Created: 28/Feb/14  Updated: 28/Feb/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: Minor
Reporter: puspadhar das Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: insert, sqlserver
Environment:

Windows 2012 Server, MS SQL 2012, IBM Server



 Description   

While flushing the entity manager, the sql queries generated for INSERT puts the date and string values inside double quotes and the following error is displayed:
SQLSTATE [21S01, 213]: [Microsoft][SQL Server Native Client 11.0][SQL Server]Column name or number of supplied values does not match table definition.
When I copy the statement and replace the double quotes to single quotes, the query is run.



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

puspadhar das can you provide the SQL query that is being attempted, your fixed version as well as the call to DBAL (or ORM) that is causing this problem?





[DDC-3000] [GH-963] SQLFilter -- allows to check if a parameter was set Created: 26/Feb/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Small change to SQLFilter, which allows to check if a parameter was set on filter



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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





[DDC-2999] [GH-962] Stop executeDeletions when there is nothing to to delete anymore Created: 25/Feb/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

A small improvement in `UOW::commit`. Only continue executing the for-loop when there's something to delete. This may save quite some calls to `UOW::executeDeletions`.



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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





[DDC-2998] [GH-961] [DDC-2984] Provide TestCase to reproduce bug Created: 24/Feb/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Guilherme Blanco [ 16/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/5ce6dabe9bb9e81eac6fd261db9bd29f7b7f290c this issue was fixed.

Comment by Doctrine Bot [ 16/Apr/14 ]

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





[DDC-2997] [GH-960] allow passing EntityManagerInterface when creating a HelperSet Created: 23/Feb/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

I've was "extending" EntityManager by decoration-wrapping and was trying to pass my EntityManager to ConsoleRunner::createHelperSet() and the type-hinting didn't allow it.
This fix will allow the $entityManager parameter to be an instance of EntityManagerInterface instead of EntityManager

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

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



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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





[DDC-2996] UnitOfWork::recomputeSingleEntityChangeSet() will not add a new change set Created: 23/Feb/14  Updated: 25/Mar/14  Resolved: 23/Mar/14

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

Type: Bug Priority: Major
Reporter: Matthieu Napoli Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

I have noticed something weird in the UnitOfWork::recomputeSingleEntityChangeSet() and I suspect it is a bug.

If I write a Listener that, on the onFlush() event, changes an entity: the documentation says to call "recomputeSingleEntityChangeSet()". However, in that method, if a change set DOESN'T EXIST, then no changeset seems to be set at all: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L940

        if ($changeSet) {
            if (isset($this->entityChangeSets[$oid])) {
                $this->entityChangeSets[$oid] = array_merge($this->entityChangeSets[$oid], $changeSet);
            }

            $this->originalEntityData[$oid] = $actualData;
        }

As you can see, if a changeset exist, we merge it, but there is no "else".

That "bug" would be consistent with a problem I'm facing: calling recomputeSingleEntityChangeSet() in onFlush() on an entity that previously (at the time of the flush) had no changes, then that entity's changes are not persisted.

Related: people saying recomputeSingleEntityChangeSet() doesn't work (just like me):

So it is a bug? Or is it intended?



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

That "bug" would be consistent with a problem I'm facing

Matthieu Napoli can you provide an example of what your listener is doing? And yes, the assumption is that a changeset for that entity already exists (otherwise it is an insert or delete operation)

Comment by Matthieu Napoli [ 23/Feb/14 ]

I have User which has a UserPreference. When UserPreference is updated in any way, I need to set "User::updatedAt" with the current time. (FYI this is because Timestampable doesn't monitor changes on a "sub-entity").

So indeed, when User is not changed but UserPreference is, the listener will introduce changes on User.

Comment by Marco Pivetta [ 23/Feb/14 ]

Matthieu Napoli tricky. What if the suggested else would just trigger UnitOfWork#computeSingleEntityChangeSet()? I'm not sure if that's going to be a BC break though.

You can workaround that by doing it manually to see if your problem is fixed by this:

if ($uow->getEntityChangeSet()) {
    $uow->recomputeSingleEntityChangeSet(...);
} else {
    $uow->computeSingleEntityChangeSet(...);
}
Comment by Matthieu Napoli [ 25/Feb/14 ]

I was going to try that but computeSingleEntityChangeSet() is private anyway...

> What if the suggested else would just trigger UnitOfWork#computeSingleEntityChangeSet()? I'm not sure if that's going to be a BC break though.

That would be the best solution I think, but I have no idea about BC.

Comment by juan maia [ 17/Mar/14 ]

Is anyone taking a look at this?

I also had a problem that maybe is related to this one.
I was calling (computeChangeSet) inside the same listener, 3 different times, for 3 different entities, but the first one doesnt change the entity (the other 2 was just fine). Then I tried recomputeSingleEntityChangeSet and nothing happened to the entities (the entities are already persisted and I'm just trying to modifying it).

Comment by Benjamin Eberlei [ 23/Mar/14 ]

Fixed

Comment by Matthieu Napoli [ 23/Mar/14 ]

Awesome news thanks

Comment by Vitaliy Zhuk [ 25/Mar/14 ]

I have a problem after update with this commit.
My application control entity insertions/updated and change another field in entity.

Logic example:

Check each entity in insertions
Check each entity in updated

And i call recompute change set in entity in check insertion, this entity added to updated, and the second step not good working, because entity INSERTIONS!

Subscriber, for example:

<?php

namespace Acme\DemoBundle\EventListener\Doctrine;

use Acme\DemoBundle\Entity\Top;
use Doctrine\Common\EventSubscriber;
use Doctrine\ORM\Event\OnFlushEventArgs;
use Doctrine\ORM\Events;

class TopChangedSubscriber implements EventSubscriber
{
    /**
     * On flush event
     *
     * @param OnFlushEventArgs $event
     */
    public function onFlush(OnFlushEventArgs $event)
    {
        $em = $event->getEntityManager();
        $uow = $em->getUnitOfWork();

        $topMetadata = $em->getClassMetadata('DemoBundle:Top');

        foreach ($uow->getScheduledEntityInsertions() as $top) {
            if ($top instanceof Top) {
                $top->setChanged(301 -  $top->getPosition());
 
                // So, i call to recompute, because entity changed.
                // BUG #1? This entity added to entity updates, and getScheduledEntityUpdates returned incorrect data
                // BUG #2? This entity has been insert (1 SQL query) and update (2 SQL query)!
                $uow->recomputeSingleEntityChangeSet($topMetadata, $top);
            }
        }

        foreach ($uow->getScheduledEntityUpdates() as $top) {
            if ($top instanceof Top) {
                $changes = $uow->getEntityChangeSet($top);

                if (isset($changes['position'])) {
                    list ($oldPosition, $newPosition) = $changes['position'];

                    $top->setChanged($oldPosition - $newPosition);

                    $uow->recomputeSingleEntityChangeSet($topMetadata, $top);
                }
            }
        }
    }

    /**
     * {@inheritDoc}
     */
    public function getSubscribedEvents()
    {
        return array(Events::onFlush);
    }
}

Thank.

Comment by Marco Pivetta [ 25/Mar/14 ]

Vitaliy Zhuk as I've already explained in https://github.com/doctrine/doctrine2/commit/d473824279bfee19772bb1692d2a3453a2aff233#commitcomment-5796295, you are not supposed to re-compute changes for insertions.

Comment by Vitaliy Zhuk [ 25/Mar/14 ]

Ok, i can change entity field in insert action?





[DDC-2995] Joined Inheritance Mapping and Filters Created: 22/Feb/14  Updated: 23/Mar/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Bojidar Hristov Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Is there any reason why Inheritance Mapping IS LEFT JOINED not INNER JOINED?

When there is a filter and it's left joined it happens a record might not have parent table record. For example

Class B extends Class A.
Class A have column is_active | and filter activated with is_active = 1 condition.

Final query: LEFT JOIN parent_table s1_ ON p2_.id = s1_.id AND (s1_.is_active = '1')

Record 1 have is_active = false, so result set looks like this:

table_b | table_a
id | id is_active discriminatorColumn
1 | null null null

and occurs exception: The discriminator column ... is missing for ....



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

JTI MUST be left-joined, since not every subclass of the root of the inheritance causes inserts on all of the inheritance tables.

What is the DQL query that is causing the problem?

Comment by Bojidar Hristov [ 22/Feb/14 ]

Hello Marco, I don't query from parent table, but from child. No sense to be LEFT JOINED.

DQL is something like that:

SELECT class1, class2 FROM Class1 class1 JOIN class1.class2 class2;

(Class2 extends Class3)
Class3 have is_active column.

And following filter:

public function addFilterConstraint(ClassMetadata $targetEntity, $targetTableAlias) {
if (!$targetEntity->reflClass->implementsInterface('ActivateableInterface'))

{ return ""; }

return $targetTableAlias . '.is_active = ' . $this->getParameter('isActive');
}

Filter condition is added in LEFT JOINED parent_table. Full example SQL:
SELECT ....
FROM class1 c1
INNER JOIN class2 c2 ON c1.c2_id = c2.id
LEFT JOIN table3 c3 ON c2.id = c3.id AND (c3.is_active = '1')

Comment by Marco Pivetta [ 26/Feb/14 ]

There are two possible solutions here:

  • verify if the selected entity is a leaf of a JTI, and use INNER JOIN on that if possible (probably not optimal, since the selection may be part of a LEFT JOIN itself)
  • add filtering on the discriminator column

Bojidar Hristov can you provide a failing test case to make it easier to work on this?

Comment by Bojidar Hristov [ 26/Feb/14 ]

Yes. Here is it sample failing test.

http://pastebin.com/xi8uUNX5 - Parent Class
http://pastebin.com/XRZLbyGX - Child Class
http://pastebin.com/HuPFb98u - Assoc Class
http://pastebin.com/hGqRk74e - TestCase

Here it should found 0 records because ot JOIN and is_active = true filter.

Comment by Benjamin Eberlei [ 23/Mar/14 ]

Since filters are only available on the root, i guess inner join is really necessary here.





[DDC-2994] [GH-959] Implemented an ObjectPersisterInterface for entity/object storage Created: 21/Feb/14  Updated: 21/Feb/14  Resolved: 21/Feb/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DCOM-235 [GH-317] Implemented an ObjectPersist... Resolved

 Description   

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

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

Message:

      1. Why is this useful?
        Instead of using the ```repositoryClass```, we use 'Repository as a Service'. This means that we inject our repository service instead of doing ```$em->getRepository('MyEntity')```, this provides typehinting and autocomplete in IDEs. This introduces a minor inconvenience, we need to inject an ```EntityManagerInterface``` to provide persist/flush. We don't want the entire ```EntityManagerInterface``` capabilities just to store an object.

Using the ```ObjectPersisterInterface``` we can "hide" the ```EntityManagerInterface``` and only let the code know we have the persist and flush methods available. By default this is implemented on the ```EntityManager```, but is also possible to be mocked or replaced by a custom implementation (rotating entity managers?).



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

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





[DDC-2992] [GH-958] wrong access modifiers "private" instead of "protected" Created: 20/Feb/14  Updated: 21/Feb/14  Resolved: 21/Feb/14

Status: Resolved
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: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

In configuration is parameter:

<parameter key="doctrine.orm.metadata.xml.class">Doctrine\ORM\Mapping\Driver\SimplifiedXmlDriver</parameter>

that suggest that is designed to override in private bundles but when you try to do that it's nessesary to repeat entire body of methods in own class because of "private" access modifiers, i suggest to change them to 'protected' because without that it's makes extending this class more difficult and not clear to understand what is going on inside of this classes.

... I suggest to change this modifiers not only in this class...



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

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





[DDC-2991] [GH-957] makes doctrine less dependent upon the symfony yamp component Created: 20/Feb/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This is the last place in the framework where the class is just too tightly coupled with the symfony yaml component, that the yaml parser alone cannot be overridden without overriding an entire class.
I simply brought it in accordance with "Doctrine\ORM\Mapping\Driver\YamlDriver" where a separate method called loadMappingFile exists to parse the mapping file.



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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





[DDC-2990] [GH-956] Foreign association index names Created: 19/Feb/14  Updated: 23/Feb/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

Issue Links:
Reference
relates to DDC-2989 ORM should allow custom index names f... Open

 Description   

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

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

Message:

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






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

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

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

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

 Description   

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



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

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

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

Comment by Marco Pivetta [ 15/Feb/14 ]

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

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

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

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

Comment by Jonathon Suggs [ 18/Feb/14 ]

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

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

Comment by Jonathon Suggs [ 19/Feb/14 ]

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

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

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

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

Comment by Benjamin Eberlei [ 19/Feb/14 ]

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

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

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

Comment by Jonathon Suggs [ 19/Feb/14 ]

Sorry for the confusion.

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

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

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

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

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

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

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

(abbreviated to the important steps, chronological order)

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

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

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

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

Comment by Jonathon Suggs [ 19/Feb/14 ]

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

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

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

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

Moved this to ORM issues.

Comment by Jonathon Suggs [ 19/Feb/14 ]

Steve I both agree and disagree.

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

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

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

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

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

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

Comment by Jonathon Suggs [ 19/Feb/14 ]

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





[DDC-2988] Notice: Undefined index: joinColumns in BasicEntityPersister.php Created: 19/Feb/14  Updated: 19/Feb/14

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

Type: Bug Priority: Major
Reporter: Dennis Væversted Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Attachments: Text File undefined-joinColumn.patch    
Issue Links:
Duplicate
duplicates DDC-2808 Notice: Undefined index: joinColumns ... Resolved

 Description   

When trying to use findBy on a ManyToMany field i receive the error:

Notice: Undefined index: joinColumns in lib/Doctrine/ORM/Persisters/BasicEntityPersister.php

It seems to be caused internally by the code expecting 'joinColumns' to be directly on the association, however it is found under 'joinTable'.
I have attached a patch that atleast fixes my case, hopefully it can be used to pin-point what the error is.



 Comments   
Comment by Dennis Væversted [ 19/Feb/14 ]

Might be related to this one: http://www.doctrine-project.org/jira/browse/DDC-2808





[DDC-2987] Possibility to use a field / fields from an Embeddable as primary key(s) Created: 19/Feb/14  Updated: 13/Mar/14  Resolved: 13/Mar/14

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

Type: Improvement Priority: Major
Reporter: Anton Stöckl Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None


 Description   

Hi there,

I'm using the brand new embedded objects in doctrine ORM in a DDD application. It's so great that you guys added this feature which enables clean DDD Value Objects!

What does not seem to work so far is using an embeddable as primary key.
I have an enbeddable "CarId" which has only one field "value" representing the uuid for the parent entity "Car".
I tried to get this to work with different approaches, but with no success.

I'm able to define the primary key in the embeddable itself, sample .yml:

_my_namespace_\CarEntity:
    type: entity
    table: car
    repositoryClass: _my_namespace_\ConcreteCarRepository
    fields:
        name:
            type: string
            length: 100
    embedded:
        uuid:
            class: CarUuidValue
        model:
            class: CarModelValue

_my_namespace_\CarIdValue:
    type: embeddable
    id:
        value:
            type: string
            length: 36

This ends up with a valid entity, but the field holding the id is named id_id. Setting an empty columnPrefix does not work:

    /**
     * Inline the embeddable class
     *
     * @param string $property
     * @param ClassMetadataInfo $embeddable
     */
    public function inlineEmbeddable($property, ClassMetadataInfo $embeddable)
    {
        foreach ($embeddable->fieldMappings as $fieldMapping) {
            $fieldMapping['declaredField'] = $property;
            $fieldMapping['originalField'] = $fieldMapping['fieldName'];
            $fieldMapping['fieldName'] = $property . "." . $fieldMapping['fieldName'];

            $fieldMapping['columnName'] = ! empty($this->embeddedClasses[$property]['columnPrefix'])
                    ? $this->embeddedClasses[$property]['columnPrefix'] . $fieldMapping['columnName']
                        : $this->namingStrategy->embeddedFieldToColumnName($property, $fieldMapping['columnName'], $this->reflClass->name, $embeddable->reflClass->name);

            $this->mapField($fieldMapping);
        }
    }

So it is ignored if it's empty because of

! empty($this->embeddedClasses[$property]['columnPrefix'])

So one possibility could be to change this so it accepts empty values or add a switch noPrefix = bool
Not sure if this would break in other places, though. Also it seems quite hacky.

I think a better solution would be to add something like associationKey, maybe embeddedKey, to the mapping.

Would be really great if you could add that feature. I think a Value Object to represent the id of an entity is a must have in a DDD application. It would be possible to passt that id object around, instead of a plain string/integer.



 Comments   
Comment by Anton Stöckl [ 13/Mar/14 ]

DDC-3028 was created from my pull request that fixes this issue





[DDC-2986] OrphanRemoval no longer works on OneToMany relationships after latest Symfony update - 2.3.10 Created: 18/Feb/14  Updated: 18/Feb/14  Resolved: 18/Feb/14

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

Type: Bug Priority: Major
Reporter: Scott Pringle Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: orm


 Description   

Since release of Symfony version 2.3.10 the orphanRemoval feature in a doctrine entity no longer removes deleted entities.



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

Needs a failing test case or better description

Comment by Scott Pringle [ 18/Feb/14 ]

In Symfony version 2.3.9 when using an arrayCollection, if the items are removed from the arrayCollection then flushed the items are removed from the database.

Below are the mapped and inversed sides of the one to many relationship. When the Flush is carried out in Symfony 2.3.9 this works as expected although in 2.3.10 the items are not removed from the database.

    /** 
     * @var ArrayCollection $dinnerMenuItems 
     * 
     * @ORM\OneToMany(targetEntity="DinnerMenuItem", mappedBy="dinnerMenu", cascade={"persist", "remove"}, orphanRemoval=true)
     * @ORM\OrderBy({"position" = "ASC"})
     */
    private $dinnerMenuItems;


    /** 
     * @var DinnerMenu
     *
     * @ORM\ManyToOne(targetEntity="DinnerMenu", inversedBy="dinnerMenuItems")
     * @ORM\JoinColumn(name="menu_id", referencedColumnName="id")
     */
    private $dinnerMenu;

I originally opened this as a Symfony issue although they have just said it is a doctrine issue.

Comment by Marco Pivetta [ 18/Feb/14 ]

This should be verified against doctrine ORM in insulation - "symfony 2.3.9" vs "symfony 2.3.10" doesn't make any difference for the ORM itself, since it is a different unrelated library.

You should probably reduce the scope of the search by looking at the diffs in your composer.lock file so that we can identify if there was a breakage, and where.

Comment by Scott Pringle [ 18/Feb/14 ]

Below is the composer.lock diff. The only change is the Symfony version and this is the difference between it working and not working.

index 36e0cbf..a185179 100644
--- a/composer.lock
+++ b/composer.lock
@@ -3,7 +3,7 @@
         "This file locks the dependencies of your project to a known state",
         "Read more about it at http://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file"
     ],
-    "hash": "b674945e7d9bc77b57cfd87fd75c73a9",
+    "hash": "340fb2e843409e3b13350e4697d3ebcc",
     "packages": [
         {
             "name": "doctrine/annotations",
@@ -3105,16 +3105,16 @@
         },
         {
             "name": "symfony/symfony",
-            "version": "v2.3.10",
+            "version": "v2.3.9",
             "source": {
                 "type": "git",
                 "url": "https://github.com/symfony/symfony.git",
-                "reference": "e4b9ff28b7c357971947ed12f99fbc68ff116830"
+                "reference": "ee1e0f2ef882ccd6a53ff91e5ffc39a22b6a6b74"
             },
             "dist": {
                 "type": "zip",
-                "url": "https://api.github.com/repos/symfony/symfony/zipball/e4b9ff28b7c357971947ed12f99fbc68ff116830",
-                "reference": "e4b9ff28b7c357971947ed12f99fbc68ff116830",
+                "url": "https://api.github.com/repos/symfony/symfony/zipball/ee1e0f2ef882ccd6a53ff91e5ffc39a22b6a6b74",
+                "reference": "ee1e0f2ef882ccd6a53ff91e5ffc39a22b6a6b74",
                 "shasum": ""
             },
             "require": {
@@ -3211,7 +3211,7 @@
             "keywords": [
                 "framework"
             ],
-            "time": "2014-02-12 08:18:23"
+            "time": "2014-01-05 01:24:54"
         },
         {
             "name": "trsteel/ckeditor-bundle",
Comment by Marco Pivetta [ 18/Feb/14 ]

This seems to be only a symfony change - no upgrades/downgrades in doctrine packages?

Comment by Scott Pringle [ 18/Feb/14 ]

Yeah that's correct. That's what I tried to say on the Symfony issue but they closed it straight away. Something in the latest Symfony update has stopped the orphanRemoval annotation from working.

Comment by Scott Pringle [ 18/Feb/14 ]

A fix has been committed to Symfony so this can be closed.

Comment by Scott Pringle [ 18/Feb/14 ]

Issue was related to Symfony and is now fixed

Comment by Marco Pivetta [ 18/Feb/14 ]

Scott Pringle reference to the commit?

Comment by Scott Pringle [ 18/Feb/14 ]

This commit fixed the issue - https://github.com/symfony/symfony/commit/c4ffe02100eb6f4aaf92ad1ccecba1bf666b96fc

Comment by Marco Pivetta [ 18/Feb/14 ]

Not related to ORM

Comment by Marco Pivetta [ 18/Feb/14 ]

Scott Pringle thanks - changed resolution

Comment by Christophe Coevoet [ 18/Feb/14 ]

Yeah, the actual issue is indeed not related to the ORM at all. But the bug report was totally wrong (which is why I classified it as a Doctrine issue): the Symfony bug has nothing to do with orphanRemoval (it is not only the related entity which was not deleted. The element was not removed from the collection at all)





[DDC-2985] [GH-955] iteration risk note Created: 17/Feb/14  Updated: 23/Mar/14  Resolved: 23/Mar/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

> instead of loading the whole result into memory at once

is not the full truth.

There is a certain risk of processes getting killed due to memory allocation with large iteration. This is caused by result buffering of the client. It is not always being visible to PHP as http://www.php.net/manual/en/mysqlinfo.concepts.buffering.php suggests.

This is only a proposal for discussion as I am not certain how to best add the information or if to add it at all (was it obvious before?). Is buffered iteration even a good suggestion for anything but small sets?

On a side-note: is there a way to run unbuffered queries with Doctrine?



 Comments   
Comment by Doctrine Bot [ 23/Mar/14 ]

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





[DDC-2984] Support Custom DBAL types to be used as identifiers Created: 15/Feb/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4, 2.4.1
Fix Version/s: 2.5, 2.4.3
Security Level: All

Type: Improvement Priority: Minor
Reporter: Alexander Miertsch Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

I've tried to use a Value Object that extends the DBAL\Types\StringType as identifier of an Aggregate Root. This is common practice in DDD, f.e. defining a TrackingId as identifier of a Cargo Aggregate. I've written a unit test for my repository and everything seemed to work well until clearing the UnitOfWork and trying to fetch a fresh entity. The error is similar to the one described in DDC-2176. The issue is closed and I don't understand why?

I think the support of Value Objects is a must have in Doctrine. I've checked out the new feature of defining embedded Value Objects and it works as a charm. But without the option to use Value Objects as identifiers Doctrine is missing an important feature!



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

DDC-2176 duplicates DDC-1998

Some clarifications:

  • custom types work as identifiers with the ORM as long as object types implement a __toString method that emulates the unique identifier
  • value objects as identifiers are not yet supported and will likely not be supported for another while because of technical limitations

What you can do to help out is writing a test case showing how you would want to use VOs on associations and identifiers.

Comment by Alexander Miertsch [ 16/Feb/14 ]

thank you for your reply. I have to check with my client if I can spend time to provide a test case. For now, we use the workaround that Yves Berkholz mentioned in his issue DDC-2176 to work with a string represantation of the VO inside the Entity.

The problem is, that the UnitOfWork uses the $idHash as key in the identityMap. If you use a Custom DBAL type as Identifier, the $idHash will be an Object and PHPUnit fails with the error: PHPUnit_Framework_Error_Warning : Illegal offset type in Doctrine\ORM\UnitOfWork.php(2578): ...
Even if the custom type implements a __toString() method.
The error/warning occurs in the same line as of the provided code block of Yves Berkholz:

$this->identityMap[$class->rootEntityName][$idHash] = $entity; // <- 2466 -> now it is line 2578

Comment by Alexander Miertsch [ 24/Feb/14 ]

I send a pull request that reproduces the bug in a TestCase, but DoctrineBot has opened a new issue: DDC-2998.

Comment by Guilherme Blanco [ 16/Apr/14 ]

As of https://github.com/doctrine/doctrine2/commit/5ce6dabe9bb9e81eac6fd261db9bd29f7b7f290c this issue was fixed.





[DDC-2983] TCI association not getting hydrated into sql statement Created: 14/Feb/14  Updated: 23/Mar/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: Machete Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

MySQL, using DoctrineORMModule (zf2 integration)



 Description   

/**
 * @ORM\Entity
 * @ORM\Table(name="base")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discriminator", type="string")
 * @ORM\DiscriminatorMap({
 * "a" = "A",
 * "b" = "B",
 * })
 */
class Base
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
}

/**
 * @ORM\Entity
**/
class A extends Base {
    /**
     * @ORM\ManyToOne(targetEntity="B", inversedBy="as")
     */
    protected $b;

    /**
     * @ORM\OneToMany(targetEntity="C", cascade={"persist"})
     */
    protected $cs;
}

/**
 * @ORM\Entity
**/
class B Extends Base {
    /**
     * @ORM\OneToMany(targetEntity="A", mappedBy="b")
     */
    protected $as;
}

/**
 * @ORM\Entity
**/
class C {
  // ...
}

Doing this:

$a = new A();
$b = new B();

$a->setB($b);
$b->addA($a);

var_dump($a->getB()); // outputs B (b not null!)
var_dump($b->getAs()) // outputs A (private $_elements => [0] class B)

$em->persist($a);
$em->persist($b);
$em->flush();

Leads to

integrity constraint violation, b_id can not be null

aka

INSERT INTO a (id, b_id), (123, null);

I have no idea why this happens. This works:

$a = new A();
$b = new B();

$a->setB($b);
$b->addA($a);

var_dump($a->getB()); // outputs B (b not null!)
var_dump($b->getAs()) // outputs A (private $_elements => [0] class B)

$em->persist($a);
$em->flush();
$em->persist($b);
$em->flush();


 Comments   
Comment by Benjamin Eberlei [ 23/Mar/14 ]

This most likely happens because the UnitOfWork tries to set the owner and reverse incorrectly due to an ordering issue.





[DDC-2982] [GH-954] Multi Get support for Second Level Cache Created: 14/Feb/14  Updated: 23/Mar/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: 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/954

Message:

Hi!
As discussed [here](http://www.doctrine-project.org/jira/browse/DDC-2981) i have implemented some kind of multi-get for second level cache implementation.

I have also created a PR to doctrine/cache component (see https://github.com/doctrine/cache/pull/29) that enables this feature at driver cache level.






[DDC-2981] Multi get for second level cache (Doctrine Cache related) Created: 13/Feb/14  Updated: 13/Feb/14

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: None


 Description   

Hi every body!

I'm developing an application that is highly based on doctrine second-level cache feature.
Using memcache or redis as cache back-end, doctrine have to query thousand times for the cached values (especially on one-to-many and many-to-many associations).
This introduces a lot of latency (and network traffic)...

I'm thinking to add to Doctrine\Common\Cache\Cache interface a method fetchMulti(array $keys) that fetches multiple items in one call. In this way doctrine orm can ask for many items with just one call (for example, here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/DefaultCollectionHydrator.php#L84 this feature can be very useful).

I have made some real-world tests and it can reduce highly the number of total queries (my app runs 190 cache requests instead of 900 cache requests)

Many vendors (memcache, redis, apc ecc) already offer this functionality, but with doctrine-cache we can't use it...

I'm going to implement this feature. Can it be accepted as a pull request?

It may be BC breaking:

  • it can be implemented adding a method inside Doctrine\Common\Cache\Cache interface (more BC breaking but more clean and elegant)
  • it can be implemented adding an interface Doctrine\Common\Cache\MultiCache and later CacheProvider can implement it (less BC breaking)


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

Adding a method to Doctrine\Common\Cache\Cache is not viable because of BC - a new interface would be ok

Comment by Asmir Mustafic [ 13/Feb/14 ]

ok, i agree with you.
But this forces me to check always here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/Region/DefaultRegion.php#L95 if $this->cache is instance of MultiCache

Comment by Marco Pivetta [ 13/Feb/14 ]

Asmir Mustafic or you build a MultiCacheRegion

Comment by Asmir Mustafic [ 13/Feb/14 ]

It can be a good approach. I will try it.
I'm thinking to provide a default implementation of fetchMulti directly inside CacheProvider that internally loops over each key and call CacheProvider::fetch($id) to fetch its value.
Later i will overwrite this behavior inside vendor specific driver (ApcCache, RedisCache...)





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

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

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


 Description   

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






[DDC-2979] [GH-953] Update doc with latest news about extra lazy assoc Created: 12/Feb/14  Updated: 12/Feb/14  Resolved: 12/Feb/14

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

Type: Documentation Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed 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/953

Message:



 Comments   
Comment by Doctrine Bot [ 12/Feb/14 ]

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

Comment by Marco Pivetta [ 12/Feb/14 ]

https://github.com/doctrine/doctrine2/commit/4382304e775ab93f9152e6201121516c7666b11c





[DDC-2976] [GH-952] Add DB-level onDelete CASCADE example Created: 11/Feb/14  Updated: 11/Feb/14  Resolved: 11/Feb/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This adds `onDelete: CASCADE` to the `address` 1-1 relationship just to show how to map a db-level cascade delete.



 Comments   
Comment by Doctrine Bot [ 11/Feb/14 ]

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

Comment by Marco Pivetta [ 11/Feb/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/9b0d7dde91a669f37509dfbf57c2fb78d2cc113f





[DDC-2975] [GH-951] More informational entity not found exception Created: 11/Feb/14  Updated: 17/Apr/14  Resolved: 17/Apr/14

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Apr/14 ]

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

Comment by Fabio B. Silva [ 17/Apr/14 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/6e9b15a48fa9db4db6ba3cbb8c4fa5d40306a07c





[DDC-2974] [GH-950] Can cache empty collections Created: 11/Feb/14  Updated: 12/Feb/14  Resolved: 12/Feb/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Fabio B. Silva
Resolution: Fixed 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/950

Message:

I should be able to cache an "empty" collection.

I have a some objects, where 90% of these have on-to-many relations with zero associated elements.
This causes doctrine to run a query each time, instead of cache it as empty relation.



 Comments   
Comment by Doctrine Bot [ 12/Feb/14 ]

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

Comment by Fabio B. Silva [ 12/Feb/14 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/a3b41046124e345ef75686c03446ceeeff2103ed





[DDC-2973] [GH-949] Add a default lock mode to the EntityManager Created: 10/Feb/14  Updated: 10/Feb/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 BenMorel:

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

Message:

Following [this discussion](https://groups.google.com/forum/#!topic/doctrine-dev/xKGzQcDkilE) on the mailing list, this is a first draft of a proposal to introduce a default lock mode for all entities loaded through an EntityManager.

At the moment, there is no way to set a lock mode for the following use cases:

  • Proxies obtained through `getReference()` and then initialized
  • Entities lazy-loaded through traversal of associations

This proposal introduces the idea of a default lock mode, which can be set at runtime when all reads in a transaction should be locking.

It works this way:

$em->beginTransaction();
$em->getConfiguration()->setDefaultLockMode(LockMode::PESSIMISTIC_WRITE);

// load entities from EntityManager, Repositories or DQL, traverse associations, etc.
// all these entities will be loaded with the given lock mode

$em->commit();
$em->getConfiguration()->setDefaultLockMode(null);

I have successfully tested it with the following use cases:

  • `EntityManager::find()`
  • `EntityRepository::findBy()`
  • DQL queries
  • Proxies
  • Lazy-loaded collections through OneToMany and ManyToMany associations

Before moving forward and writing proper unit tests, I'm looking for your feedback on this proposal. Is this a concept you would be happy to integrate in Doctrine?

If yes, I have a doubt as regards to where the default lock mode should be set: @Ocramius suggested to set it on the `Configuration`; this looked reasonable at first glance, and I have implemented it this way for now. It feels a tiny bit wrong though now that I see it, as I feel like the contents of the Configuration should should only be set during bootstrapping, rather than being set and reset in the controllers as in the example above. I might be wrong obviously.

My suggestion would be to move the default lock mode to the EntityManager, so that the code would become:

$em->beginTransaction();
$em->setDefaultLockMode(LockMode::PESSIMISTIC_WRITE);

Happily waiting for your feedback!






[DDC-2972] [GH-948] Update UnitOfWork.php Created: 10/Feb/14  Updated: 10/Feb/14  Resolved: 10/Feb/14

Status: Closed
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

For datetime objects the comparison doesn't work ex:
array (size=2)
0 =>
object(DateTime)[990]
public 'date' => string '2007-10-25 00:00:00' (length=19)
public 'timezone_type' => int 3
public 'timezone' => string 'Europe/Luxembourg' (length=17)
1 =>
object(DateTime)[1876]
public 'date' => string '2007-10-25 00:00:00' (length=19)
public 'timezone_type' => int 3
public 'timezone' => string 'Europe/Luxembourg' (length=17)

it's the same date but the scrict comparison make the original value is different of the actual value.



 Comments   
Comment by Doctrine Bot [ 10/Feb/14 ]

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

Comment by Alexander [ 10/Feb/14 ]

http://docs.doctrine-project.org/en/latest/cookbook/working-with-datetime.html





[DDC-2971] [GH-947] Cleaned up further unused imports. Created: 09/Feb/14  Updated: 10/Feb/14  Resolved: 10/Feb/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed 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/947

Message:

Further cleanup of unused `use` statements.

Sorry for the extra PR, I previously missed the less obvious ones that were importing classes from their own namespace, for example:

namespace Doctrine\ORM;
use Doctrine\ORM\EntityManagerInterface;



 Comments   
Comment by Doctrine Bot [ 10/Feb/14 ]

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

Comment by Marco Pivetta [ 10/Feb/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/e8f51acdb2f2038ab588682ae4501df4e1c6b33e





[DDC-2970] [GH-946] Cleaned up unused imports Created: 09/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed 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/946

Message:

These `use` statements are not used anywhere in the code.



 Comments   
Comment by Doctrine Bot [ 09/Feb/14 ]

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

Comment by Marco Pivetta [ 09/Feb/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/c4b1d4fa2884ec0e5731f9c562d84e2cbb8957ed





[DDC-2969] [GH-945] Fix CS Created: 09/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 09/Feb/14 ]

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

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

Fixed in commit: https://github.com/doctrine/doctrine2/commit/6cd0861fa3e9702a6bd5304344de93a500323d66





[DDC-2968] [GH-944] Fixed InputOption modes Created: 09/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 09/Feb/14 ]

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





[DDC-2967] [GH-943] Validate embeddables do not contain other embeddables. Created: 09/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed 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/943

Message:

Throws a ```MappingException``` during the metadata loading when it encounters an embeddable that contains other embeddables.



 Comments   
Comment by Doctrine Bot [ 09/Feb/14 ]

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





[DDC-2966] [GH-942] DDC-2965 - Changing ID generation after `flush` makes persisters unusable Created: 09/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

Status: Resolved
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: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-2965 Error after changing IdGenerator to A... Resolved

 Description   

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

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

Message:

As posted on http://www.doctrine-project.org/jira/browse/DDC-2965 by @psliwa (imported his tests)



 Comments   
Comment by Doctrine Bot [ 09/Feb/14 ]

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

Comment by Benjamin Eberlei [ 09/Feb/14 ]

It is not a supported use case to change the metadata after loading them.





[DDC-2965] Error after changing IdGenerator to AssignedGenerator when for this entity class insert has been already executed Created: 08/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

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

Type: Bug Priority: Major
Reporter: Piotr Śliwa Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: mapping, persister

Issue Links:
Reference
is referenced by DDC-2966 [GH-942] DDC-2965 - Changing ID gener... Resolved

 Description   

When you persist and flush entity and then change id generator to AssignedGenerator (and id generator type to NONE) for this entity class and then you persist and flush new entity with assigned id, below error will occur:

Exception: [Doctrine\DBAL\Exception\DriverException] An exception occurred while executing 'INSERT INTO cms_emails (email) VALUES ' with params [13, "example@example.com"]:

SQLSTATE[HY000]: General error: 25 bind or column index out of range

There is test that reproduces this issue:

    public function testPersistEntityAndThenSwitchToAssignedIdGenerator()
    {
        $email = new \Doctrine\Tests\Models\CMS\CmsEmail();
        $email->email = 'example5@example.com';

        $this->_em->persist($email);
        $this->_em->flush();

        $this->assertNotNull($email->id);

        $classMetadata = $this->_em->getClassMetadata('Doctrine\Tests\Models\CMS\CmsEmail');
        $classMetadata->setIdGeneratorType(ClassMetadataInfo::GENERATOR_TYPE_NONE);
        $classMetadata->setIdGenerator(new \Doctrine\ORM\Id\AssignedGenerator());

        $id = 13;

        $newEmail = new \Doctrine\Tests\Models\CMS\CmsEmail();
        $newEmail->email = 'example@example.com';
        $newEmail->id = $id;

        $this->_em->persist($newEmail);
        $this->_em->flush();
        $this->_em->clear();

        $newEmail = $this->_em->find('Doctrine\Tests\Models\CMS\CmsEmail', $id);

        $this->assertNotNull($newEmail);
    }

The problem is in BasicEntityPersister because insertSql is cached and is not cleared after changing id generator. Binded parameters count doesn't match with insert query because there is new parameter: id.



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

Provided a possible fix at https://github.com/doctrine/doctrine2/pull/942

Comment by Doctrine Bot [ 09/Feb/14 ]

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

Comment by Benjamin Eberlei [ 09/Feb/14 ]

It is not a supported use case to change metadata after loading them.





[DDC-2964] [GH-941] Fixed test case for HHVM garbage collection--backported from master Created: 08/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

Status: Resolved
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: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

This change is necessary in order for this test case to work with HHVM



 Comments   
Comment by Doctrine Bot [ 09/Feb/14 ]

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





[DDC-2963] [GH-940] Fixed typo & horizontal scrolling Created: 08/Feb/14  Updated: 09/Feb/14  Resolved: 08/Feb/14

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

The first example was out of sync with the code.

I also updated the 3 code blocks, so the query is fully shown without scrolling.



 Comments   
Comment by Doctrine Bot [ 08/Feb/14 ]

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

Comment by Marco Pivetta [ 08/Feb/14 ]

https://github.com/doctrine/doctrine2/commit/496fa85641fa645a2bd12e49685bf044098c9cdc





[DDC-2962] [GH-939] [DDC-1985] Order Preservation Created: 08/Feb/14  Updated: 09/Feb/14  Resolved: 09/Feb/14

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

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


 Description   

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

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

Message:

Preserve order on all platforms.



 Comments   
Comment by Doctrine Bot [ 09/Feb/14 ]

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





[DDC-2961] [GH-938] Missing join-tables added in example Created: 06/Feb/14  Updated: 06/Feb/14  Resolved: 06/Feb/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

There are 2 many-to-may associations between the users and comments. Both use another join-table. The join-tables user_favorite_comments and user_read_comments must be specified. Otherwise the default "user_comment" is taken twice, resulting in an error.

See https://groups.google.com/forum/#!topic/doctrine-user/Kti36_n6490 and https://groups.google.com/forum/#!topic/doctrine-user/TYwafhgYiSU



 Comments   
Comment by Doctrine Bot [ 06/Feb/14 ]

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

Comment by Marco Pivetta [ 06/Feb/14 ]

https://github.com/doctrine/doctrine2/commit/7ceb9b0b50645c2c92e3408e69f494736885b50c





[DDC-2960] Second level cache fatal error on assocations Created: 06/Feb/14  Updated: 12/Feb/14  Resolved: 12/Feb/14

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

Type: Bug Priority: Major
Reporter: Asmir Mustafic Assignee: Fabio B. Silva
Resolution: Invalid Votes: 0
Labels: None


 Description   

After the first request, that puts in cache the entities, i get a fatal error:

Fatal error: Call to undefined method Doctrine\ORM\Persisters\BasicEntityPersister::getCacheRegion() in /vagrant/project/mercurio-rest/vendor/doctrine/orm/lib/Doctrine/ORM/Cache/DefaultEntityHydrator.php on line 128

I have also posted a question that explain it with a example:
http://stackoverflow.com/questions/21577001/doctrine-second-level-cache-fatal-error-without-cache-on-entity

I don't know if is really related to @Cache annotation...

The fact is that $assocPersister (https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Cache/DefaultEntityHydrator.php#L127) is not a CachedPersister instance.



 Comments   
Comment by Asmir Mustafic [ 06/Feb/14 ]

It happens when an entity is used as id fileld

Comment by Fabio B. Silva [ 07/Feb/14 ]

You have to add ``@Cache`` to all associated entities.

Comment by Asmir Mustafic [ 07/Feb/14 ]

it is a little bit redundant... but acceptable... (is it used to discover in which region save the entity?)

I have tried to put @cache annotations, but when the entity has an association key, it results partially populated (just the primary key).

Anyway, a fatal error is a wrong user experience... it can be fixed

Comment by Asmir Mustafic [ 12/Feb/14 ]

I think that this was fixed here https://github.com/doctrine/doctrine2/commit/7e5a1c6b0d928a63626fea961dd4cecb74ab01de#diff-9f61d3a7fb0439833d89e2d120d298bc
Probably i have not merged the latest master.

Comment by Asmir Mustafic [ 12/Feb/14 ]

Already fixed with https://github.com/doctrine/doctrine2/commit/7e5a1c6b0d928a63626fea961dd4cecb74ab01de#diff-9f61d3a7fb0439833d89e2d120d298bc





[DDC-2959] [GH-937] Extra-lazy for containsKey on collections Created: 06/Feb/14  Updated: 08/Feb/14  Resolved: 08/Feb/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: lazy, relations


 Description   

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

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

Message:

If an association is EXTRA_LAZY and has an indexBy, then
you can call containsKey() without loading the entire collection.



 Comments   
Comment by Doctrine Bot [ 08/Feb/14 ]

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





[DDC-2958] [GH-936] [WIP] Making testing dependencies explicit Created: 06/Feb/14  Updated: 02/Mar/14  Resolved: 02/Mar/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-3004 [GH-966] Simplify build matrix Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 02/Mar/14 ]

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

Comment by Marco Pivetta [ 02/Mar/14 ]

Handled in DDC-3004





[DDC-2957] [GH-935] Remove incorrect (outdated) validation for public fields in SchemaValidator Created: 06/Feb/14  Updated: 19/Feb/14  Resolved: 19/Feb/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: