[DDC-3233] [GH-1092] Arbitrary Join count walkers solution Created: 30/Jul/14  Updated: 30/Jul/14

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

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


 Description   

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

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

Message:

Possible solution for Arbitrary Join problem in pagination count
walkers:
https://groups.google.com/forum/#!topic/doctrine-user/rpPYCDNKOU8

Added a condition to test query component against SelectStatement from
clause






[DDC-2379] [GH-637] Update association-mapping.rst Created: 29/Mar/13  Updated: 29/Jul/14  Resolved: 08/Sep/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 30/Mar/13 ]

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

Comment by Doctrine Bot [ 29/Jul/14 ]

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





[DDC-1769] [GH-332] Fixed DDC-1441 unsing doctrine-common ClassUtils getRealClass() method Created: 05/Apr/12  Updated: 28/Jul/14  Resolved: 07/Apr/12

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


 Description   

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

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

Message:

Fixes http://www.doctrine-project.org/jira/browse/DDC-1441 using helpers from doctrine/common introduced by version 2.2.



 Comments   
Comment by Benjamin Eberlei [ 05/Apr/12 ]

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

Comment by Doctrine Bot [ 28/Jul/14 ]

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





[DDC-3232] [GH-1090] 'EntityRepository' dependencies are accessible, using getters, after instantiation. Created: 28/Jul/14  Updated: 28/Jul/14  Resolved: 28/Jul/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: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Good morning,

An `EntityRepository` object is created using an `EntityManager` and a Mapping `ClassMetadata` object but -previously - those dependencies were not publicly accessible. I've been creating a `QueryBuilder` using `EntityRepository::createQueryBuilder()` to get a hold of the `EntityManager`, which is a little silly.

I added a unit test for `EntityRepository` and made both dependencies accessible.

Thanks,
Dan



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

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





[DDC-1768] [GH-330] improved exception message Created: 05/Apr/12  Updated: 27/Jul/14  Resolved: 04/May/12

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

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


 Description   

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

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

Message:

This makes the exception message more helpful. Before you were basically searching a needle in a haystack.

Note that I haven't been able to run the tests because I don't have PHPUnit 3.6 atm, so please check before merging.



 Comments   
Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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

Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DDC-1764] [GH-326] 2.1.x setDiscriminatorMap fix Created: 04/Apr/12  Updated: 27/Jul/14  Resolved: 07/Apr/12

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

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


 Description   

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

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

Message:

Fixing a bug when calling setDiscriminatorMap from multiple sources (ie: from Events::loadClassMetadata and annotation).

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



 Comments   
Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

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

Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DDC-1767] [GH-329] [DDC-1766] Initial implementation of hydration cache. Created: 04/Apr/12  Updated: 27/Jul/14  Resolved: 07/Apr/12

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: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Duplicate 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/329

Message:



 Comments   
Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 04/Apr/12 ]

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

Comment by Benjamin Eberlei [ 05/Apr/12 ]

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

Comment by Benjamin Eberlei [ 06/Apr/12 ]

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

Comment by Benjamin Eberlei [ 07/Apr/12 ]

Duplicate of DDC-1766

Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DDC-2391] [GH-643] DDC-2390: Remove Query dependency in SqlWalker and Parser Created: 04/Apr/13  Updated: 27/Jul/14  Resolved: 01/May/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei 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 beberlei:

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

Message:

To prevent future problems with illegal Query parameter access and also to decouple the namespaces by removing bidirectional dependency.



 Comments   
Comment by Doctrine Bot [ 01/May/13 ]

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

Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DDC-3231] [GH-1089] Entity repository generator default repository Created: 27/Jul/14  Updated: 27/Jul/14

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

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


 Description   

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

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

Message:






[DDC-2389] [GH-642] replaced direct class in instance creation Created: 04/Apr/13  Updated: 27/Jul/14  Resolved: 04/Apr/13

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: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

return new EntityManager() -> return new static() on line 945
made code more reusable



 Comments   
Comment by Benjamin Eberlei [ 04/Apr/13 ]

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

Comment by Marco Pivetta [ 04/Apr/13 ]

EntityManager should not be extended

Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DDC-2386] [GH-641] Added yml example in ordered-associations.rst Created: 03/Apr/13  Updated: 27/Jul/14  Resolved: 08/Sep/13

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

Type: Documentation Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Added missing yaml example of ordered-associations, and put php, xml and yml codes into a configuration-block instead of separate code-blocks



 Comments   
Comment by Benjamin Eberlei [ 03/Apr/13 ]

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

Comment by Marco Pivetta [ 03/Apr/13 ]

merged

Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DDC-3230] Bug in clear cache Created: 25/Jul/14  Updated: 25/Jul/14

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

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

Windows 7 64bits
PHP 5.5.4 32 bits
pdo_sql_srv 3.0.2 for php 5.5 32 bits
symfony 2.5
gedmo deletable @ dev-master
Redis 2.8.12
PHPRedis php_redis-2.2.5-5.5-nts-vc11-x86
IIS 7.5



 Description   

1. Redis is used for cache/meta/result caching.
2. Entity has property $deleted with gedmo deletable on it.
3. Removing property $deleted (and all related annotations)
4. Symfony commands:

php app/console doctrine:cache:clear-metadata
php app/console doctrine:cache:clear-query
php app/console doctrine:cache:clear-result
php app/console cache:clear --env=prod --no-debug <-- error on this command

5. [ReflectionException]
Property Entity::$deleted does not exist

Trace:

#0 \vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\ClassMetadataInfo.php(989)
#1 \vendor\doctrine\orm\lib\Doctrine\ORM\Mapping\ClassMetadataFactory.php(571)
#2 \vendor\doctrine\common\lib\Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory.php(210) <-- CacheRedis driver called here
#3 \vendor\doctrine\common\lib\Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory.php(114)
#4 \vendor\symfony\symfony\src\Symfony\Bridge\Doctrine\CacheWarmer\ProxyCacheWarmer.php(69)
#5 \vendor\symfony\symfony\src\Symfony\Component\HttpKernel\CacheWarmer\CacheWarmerAggregate.php(48)
#6 \app\bootstrap.php.cache(2513)
#7 \app\bootstrap.php.cache(2284)
#8 \vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle\Command\CacheClearCommand.php(128)
#9 \vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle\Command\CacheClearCommand.php(90)
#10 \vendor\symfony\symfony\src\Symfony\Component\Console\Command\Command.php(252)
#11 \vendor\symfony\symfony\src\Symfony\Component\Console\Application.php(894)
#12 \vendor\symfony\symfony\src\Symfony\Component\Console\Application.php(193)
#13 \vendor\symfony\symfony\src\Symfony\Bundle\FrameworkBundle\Console\Application.php(96)
#14 \vendor\symfony\symfony\src\Symfony\Component\Console\Application.php(124)
#15 \app\console(27)

Why do i think this is a Doctrine bug and not a Symfony bug? Because

php app/console doctrine:cache:clear-metadata
php app/console doctrine:cache:clear-query
php app/console doctrine:cache:clear-result

have been called successfully so RedisCache should not return cache with $this->fieldMappings containing key "deleted"






[DDC-2384] [GH-639] Added abillity to use metacolumn as indexBy Created: 02/Apr/13  Updated: 25/Jul/14  Resolved: 10/May/13

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
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/639

Message:

Added ability to use meta column as indexBy. Useful if association entities is widely used.
Replace #204 PR



 Comments   
Comment by Doctrine Bot [ 10/May/13 ]

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

Comment by Doctrine Bot [ 25/Jul/14 ]

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





[DDC-2380] [GH-638] Fixed typos in docblocks. Created: 30/Mar/13  Updated: 25/Jul/14  Resolved: 01/Apr/13

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


 Description   

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

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

Message:

Hello again, I'm committing the mini fixes in docblock documentation - swapping 'an SQL' for 'a SQL'.

Thanks!



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

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

Comment by Doctrine Bot [ 25/Jul/14 ]

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





[DDC-3229] Error when running the tests Created: 24/Jul/14  Updated: 24/Jul/14

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

Type: Bug Priority: Major
Reporter: Jeroen De Dauw Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Fresh clone at 089cca636e0e44a70dd9167b7d813762ea80daca.

php -v
PHP 5.5.9-1ubuntu4.3 (cli) (built: Jul 7 2014 16:36:58)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

j@wd42:~/workspace/doctrine2$ phpunit
PHPUnit 4.3-ge243de0 by Sebastian Bergmann.

Configuration read from /home/j/workspace/doctrine2/phpunit.xml.dist

............................................................. 61 / 2500 ( 2%)
........S.................................................... 122 / 2500 ( 4%)
............................................................. 183 / 2500 ( 7%)
............................................................. 244 / 2500 ( 9%)
............................................................. 305 / 2500 ( 12%)
............................................................. 366 / 2500 ( 14%)
.........................S...SSSS.S.......................... 427 / 2500 ( 17%)
............................................................. 488 / 2500 ( 19%)
....................................................SS....... 549 / 2500 ( 21%)
............................................................. 610 / 2500 ( 24%)
............................................................. 671 / 2500 ( 26%)
............................................................. 732 / 2500 ( 29%)
............................................................. 793 / 2500 ( 31%)
........................................................S.SSS 854 / 2500 ( 34%)
SSSSSSSSS.................................................... 915 / 2500 ( 36%)
..........................................SS................. 976 / 2500 ( 39%)
.............S...S...........S..............................S 1037 / 2500 ( 41%)
........PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65552 bytes) in /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/ProxyGenerator.php on line 280
PHP Stack trace:
PHP 1.

{main}

() /usr/bin/phpunit.phar:0
PHP 2. PHPUnit_TextUI_Command::main() /usr/bin/phpunit.phar:586
PHP 3. PHPUnit_TextUI_Command->run() phar:///usr/bin/phpunit.phar/phpunit/TextUI/Command.php:132
PHP 4. PHPUnit_TextUI_TestRunner->doRun() phar:///usr/bin/phpunit.phar/phpunit/TextUI/Command.php:179
PHP 5. PHPUnit_Framework_TestSuite->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:423
PHP 6. PHPUnit_Framework_TestSuite->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestSuite.php:715
PHP 7. PHPUnit_Framework_TestCase->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestSuite.php:715
PHP 8. PHPUnit_Framework_TestResult->run() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:672
PHP 9. PHPUnit_Framework_TestCase->runBare() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestResult.php:654
PHP 10. PHPUnit_Framework_TestCase->runTest() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:734
PHP 11. ReflectionMethod->invokeArgs() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:859
PHP 12. Doctrine\Tests\ORM\Functional\Ticket\DDC1436Test->testIdentityMap() /home/j/workspace/doctrine2/vendor/phpunit/phpunit/src/Framework/TestCase.php:859
PHP 13. Doctrine\ORM\AbstractQuery->getOneOrNullResult() /home/j/workspace/doctrine2/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC1436Test.php:42
PHP 14. Doctrine\ORM\AbstractQuery->execute() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:766
PHP 15. Doctrine\ORM\AbstractQuery->executeIgnoreQueryCache() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:923
PHP 16. Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll() /home/j/workspace/doctrine2/lib/Doctrine/ORM/AbstractQuery.php:977
PHP 17. Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateAllData() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php:147
PHP 18. Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateRowData() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:160
PHP 19. Doctrine\ORM\Internal\Hydration\ObjectHydrator->getEntity() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:432
PHP 20. Doctrine\ORM\UnitOfWork->createEntity() /home/j/workspace/doctrine2/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:268
PHP 21. Doctrine\Common\Proxy\AbstractProxyFactory->getProxy() /home/j/workspace/doctrine2/lib/Doctrine/ORM/UnitOfWork.php:2714
PHP 22. Doctrine\Common\Proxy\AbstractProxyFactory->getProxyDefinition() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:119
PHP 23. Doctrine\Common\Proxy\ProxyGenerator->generateProxyClass() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/AbstractProxyFactory.php:218
PHP 24. strtr() /home/j/workspace/doctrine2/vendor/doctrine/common/lib/Doctrine/Common/Proxy/ProxyGenerator.php:280






[DDC-3228] ORM\Tools\Export\Driver\PhpExporter.php does not properly export manyToOne associations Created: 24/Jul/14  Updated: 24/Jul/14

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

Type: Bug Priority: Major
Reporter: Dan V Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm, schematool
Environment:

PHP 5.5.9-1ubuntu4 (cli)



 Description   

PhpExporter.php fails to check the association for manyToOne/oneToOne and exports all associations as oneToOne.

See https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/PhpExporter.php#L116 where oneToOne is hardcoded if the bitmask matches either manyToOne or oneToOne.

As opposed to YamlExporter.php:

https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/YamlExporter.php#L165

Which does roughly the same thing, but then properly sets the association type by checking the actual association on lines 186 through one 190:

https://github.com/doctrine/doctrine2/tree/master/lib/Doctrine/ORM/Tools/Export/Driver/YamlExporter.php#L186-L190






[DDC-3120] Warning: Erroneous data format for unserializing PHP5.6+ Created: 11/May/14  Updated: 24/Jul/14  Resolved: 02/Jun/14

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

Type: Bug Priority: Minor
Reporter: Cornelis Brouwers Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: mapping, orm
Environment:

Webserver Apache/2.4.7 (Win32) OpenSSL/1.0.1e PHP/5.6.0beta2

and

PHP-CLI (Win32) PHP/5.6.0beta2



 Description   

Hi all,

There seems to be something strange going on in the method newInstance() of the class \Doctrine\ORM\Mapping\ClassMetadataInfo.

The original class method looks like this:

\Doctrine\ORM\Mapping\ClassMetadataInfo#newInstance()

    {
        if ($this->_prototype === null) {
            $this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
        }

        return clone $this->_prototype;
    }

What happens now when a class that implements \Serializable is that a "Warning: Erroneous data format for unserializing" shows up and the function unserialize() returns false.

That is because a class that implements \Serializable is expected to have the letter 'C' in the serialize string instead of the letter 'O'.

I've made a quick work-around like this:

\Doctrine\ORM\Mapping\ClassMetadataInfo#newInstance()

    {
        if ($this->_prototype === null) {
            $this->_prototype = @unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
            if ($this->_prototype === false) {
                $this->_prototype = unserialize(sprintf('C:%d:"%s":0:{}', strlen($this->name), $this->name));
            }
        }

        return clone $this->_prototype;
    }

That seems to work in my isolated tests and with Symfony2 and Doctrine2 and FOSUserBundle together.

I've noticed this because the Model\User class from FOSUserBundle implements \Serializable.

I had to implement a check in Model\User class because when using 'C:%d:"%s":0:{}' the $serialized parameter of the unserialize method in the Model\User class is a empty string then.

That warning seems only to happen with PHP5.6+. PHP5.5.12 and below doesn't show that warning.

I hope someone can shine some light on this, thank you,

Cornelis.



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

Indeed, for PHP 5.4+ we should use

ReflectionClass#newInstanceWithoutConstructor()
Comment by Cornelis Brouwers [ 11/May/14 ]

Just tested it. That works as expected, far more better then the dirty hacks I did, thanks a lot!

Any idea when this would be implemented into the code?

Comment by Marco Pivetta [ 11/May/14 ]

Send a pull request and I'll merge it later today (we could also need a failing test with an entity implementing the Serializable interface)

Comment by Evert Harmeling [ 30/May/14 ]

Seems to be a problem in the latest PHP 5.4 version too.

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

Comment by Doctrine Bot [ 30/May/14 ]

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

Comment by Julian Reyes Escrigas [ 02/Jun/14 ]

I am facing this same error i have PHP 5.5.13, I'm using Symfony, Doctrine ORM and FOSUserBUndle

Comment by Marco Pivetta [ 02/Jun/14 ]

Julian Reyes Escrigas the patch landed in master (2.5.x) for now.

Comment by Marco Pivetta [ 02/Jun/14 ]

Merged via DDC-3147

Comment by Thomas Buhk [ 04/Jun/14 ]

When can we expect the version with this bugfix?

Comment by Anthony Rey [ 08/Jun/14 ]

Why don't you tag 2.4.3 version with this fix ? Because the error is already present in PHP 5.5.13 which is a stable version and it's a blocking issue when you're using FOSUserBundle for example. There is also no opened issue refering this version and the due date is in april.

Comment by Jovan Perovic [ 19/Jun/14 ]

I'm still seeing this bug, although my PHP_VERSION_ID is 50600

So, version based condition is no good...

Comment by Marco Pivetta [ 19/Jun/14 ]

The approach to be taken for 50600 is still under discussion in php-internals.

Comment by Cornelis Brouwers [ 20/Jun/14 ]

Hi all,

I've just downloaded PHP5.6RC1 and updated doctrine and the error is back indeed.

A little peek at the code starting on line 866 of file Doctrine\ORM\Mapping\ClassMetadataInfo.php shows this:

    public function newInstance()
    {
        if ($this->_prototype === null) {
            if (PHP_VERSION_ID === 50429 || PHP_VERSION_ID === 50513) {
                $this->_prototype = $this->reflClass->newInstanceWithoutConstructor();
            } else {
                $this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
            }
        }

        return clone $this->_prototype;
    }

As can be seen, PHP5.6 is out of the picture, it only checks for the exact versions 5.4.29 and 5.5.13.

So for the code to work correctly on PHP5.6 one can add PHP5.6 to the test condition, or just skip the test all together if you don't mind the old PHP5.3. According to PHP, ReflectionClass::newInstanceWithoutConstructor is available since PHP >= 5.4.0.

Greetings, Cornelis.

Comment by Marco Pivetta [ 21/Jun/14 ]

As I already pointed out, this is still being discussed in php internals. See http://news.php.net/php.internals/75009

This won't be dealt with in 5.6 until there's either a stable release or internals decides what has to be done.

Comment by Marco Pivetta [ 21/Jun/14 ]

Also, ReflectionClass#newInstanceWithoutConstructor() still doesn't cover the pre-existing "hack" using unserialize, so we're still waiting for a reliable API from PHP core.

Comment by Chase Noel [ 23/Jul/14 ]

Using PHP 5.6RC2 and ORM 2.4.4 I am still experiencing this issue. I have also tested with PHP 5.5.15 and I am still getting the issue. Do i need to be using a different build of ORM to have the fix applied?

Comment by pascall [ 23/Jul/14 ]

Hi,
I'm using 5.6.0beta3 and ORM 2.4.4 and i have the same probleme
Warning: Erroneous data format for unserializing .. in orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 872

and in current code in ClassMetadataInfo.php line 872 is :

public function newInstance()
{
if ($this->_prototype === null) {
if (PHP_VERSION_ID === 50429 || PHP_VERSION_ID === 50513)

{ $this->_prototype = $this->reflClass->newInstanceWithoutConstructor(); }

else {
$this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
}
}

return clone $this->_prototype;
}

Comment by Evert Harmeling [ 23/Jul/14 ]

As stated by Marco Pivetta; "This won't be dealt with in 5.6 until there's either a stable release or internals decides what has to be done.". And besides that 5.6 still is in development, not stable.
If you still want to use 5.6 you can fork the code and extend the 5.4 / 5.5 check to support 5.6.

Comment by Chase Noel [ 23/Jul/14 ]

5.6 has an RC which should mean a stable API, and that only bugs will be fixed before an official stable release?

Comment by Evert Harmeling [ 23/Jul/14 ]

Looking at http://news.php.net/php.internals/75966 it's still being discussed, and they are planning to have it fixed in RC3.

Comment by Marco Pivetta [ 23/Jul/14 ]

Internals still didn't get to a clear decision. Until then, we won't support 5.6 officially.

Comment by Ronan [ 24/Jul/14 ]

Same error encountered with PHP 5.5.13 (cli) (built: May 30 2014 10:43:29)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

(PHP 5.5 installed via http://php-osx.liip.ch/)

Comment by Marco Pivetta [ 24/Jul/14 ]

Ronan what D2 version? We fixed it for 2.4.x (temporarily)

Comment by Ronan [ 24/Jul/14 ]

My bad: reading my composer.lock: doctrine/orm, v2.4.2, ref 0363a5548d9263f979f9ca149decb9cfc66419ab, "time": "2014-02-08 16:35:09"... Well.. this is was an old one !

`composer update` fixed it. Sorry for disturbing.





[DDC-3225] [GH-1087] Remove the error control operator Created: 23/Jul/14  Updated: 24/Jul/14  Resolved: 23/Jul/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:
Reference
is referenced by DDC-3227 [GH-1088] Fix the composer autoload p... Resolved

 Description   

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

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

Message:






[DDC-3227] [GH-1088] Fix the composer autoload paths for the doctrine CLT Created: 24/Jul/14  Updated: 24/Jul/14  Resolved: 24/Jul/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:
Reference
relates to DDC-3225 [GH-1087] Remove the error control op... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 24/Jul/14 ]

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





[DDC-3226] Unable to escape field names in YAML notation Created: 24/Jul/14  Updated: 24/Jul/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: Stepan Anchugov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP Version 5.5.11
MySQL 5.6.16
Darwin Kernel Version 13.3.0
Mac OS 10.9.3



 Description   

As in DDC-1759, I wanted to use some reserved words as my field names (same case: MySQL-backed key-value storage).
DDC-1759 was resolved by escaping the column names in field annotations. However, I'm using YAML files to store my mappings, and I couldn't find a way to set up an escaped field name there.






[DDC-3224] getResult(HYDRATE_OBJECT) with joined query is returning reduced number of rows Created: 23/Jul/14  Updated: 23/Jul/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: Critical
Reporter: gondo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

osx, PHP-FPM 5.5.13, nginx/1.6.0, mysql 5.6.19 Homebrew



 Description   

given that i have these 2 entities (pseodocode):

/**
 * @ORM\Table(name="entity1", options={"collate"="utf8_unicode_ci", "charset"="utf8"})
 * @ORM\Entity(repositoryClass="Entity1Repository")
 */
class Entity1 {
    /**
     * @var integer
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

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

    /**
     * @var Entity2[]
     * @ORM\OneToMany(targetEntity="Entity2", mappedBy="entity1")
     */
    protected $entity2;
}

/**
 * @ORM\Table(name="entity2", options={"collate"="utf8_unicode_ci", "charset"="utf8"})
 * @ORM\Entity()
 */
class Entity2 {
    /**
     * @var integer
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @var \DateTime
     * @ORM\Column(name="date", type="datetime")
     */
    protected $date;

    /**
     * @var Entity1
     * @ORM\ManyToOne(targetEntity="Entity1", inversedBy="entity2", fetch="EAGER")
     */
    protected $entity1;
}

tables and data

entity1:

id name
1 Jhon
2 Clare

entity2:

id date entity1_id
1 2011-01-01 00:00:01 1
2 2012-02-02 00:00:02 1
3 2013-03-03 00:00:03 2
4 2014-04-04 00:00:04 2

my query builder

use Doctrine\ORM\EntityRepository;

class Entity1Repository extends EntityRepository
{
    public function getData()
    {
        $qb = $this
            ->createQueryBuilder('Entity1')
            ->select('Entity1, Entity2.date')
            ->join('Entity1.entity2', 'Entity2', Join::WITH, 'Entity2.date > :date')
            ->setParameter('date', '2000-01-01 00:00:01')
        ;
        $result1 = $qb->getQuery()->getArrayResult(); // HYDRATE_ARRAY
        $result = $qb->getQuery()->getResult(); // HYDRATE_OBJECT
        
//        return $result1;
//        return $result2;
    }
}

proper result is this:

id name date
1 Jhon 2011-01-01 00:00:01
1 Jhon 2012-02-02 00:00:02
2 Clare 2013-03-03 00:00:03
2 Clare 2014-04-04 00:00:04

what is happening

$result1 = $qb->getQuery()->getArrayResult(); // HYDRATE_ARRAY

is really returning proper number of rows

BUT and here comes the BUG finally:

$result2 = $qb->getQuery()->getResult(); // HYDRATE_OBJECT

is returning just 2 rows:

id name date
1 Jhon 2011-01-01 00:00:01
2 Clare 2013-03-03 00:00:03

this is because somehow entities are made unique.

my workaround

as a workaround, what i have to do is, to exectute 2 queries. 1st to get just Entity1.ids joined with Entity2.dates by using `getArrayResult()`
and second query to get Entity1 objeces by unique ids from 1st query.
and than manualy join those results in php.



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

I see that you are using Join::WITH, but not providing a conditional in the example. Are you filtering a fetch-joined association?

Comment by gondo [ 23/Jul/14 ]

sorry i've tried to simplify my structure as much as it was possible, there are actually real conditions, one of them is date condition (among many others). i've updated my code

Comment by Marco Pivetta [ 23/Jul/14 ]

There are still some inconsistencies in the issue - where is that query parameter used, for example?

Comment by gondo [ 23/Jul/14 ]

im using it in EntityRepository (sorry, didnt know thats important) i ll update my code
and the whole code is in Symfony2 project (web and command line applications)

Comment by Marco Pivetta [ 23/Jul/14 ]

What I mean is that in

->setParameter('date', new \DateTime('last month'))

, parameter :date does not exist in the DQL.

Comment by gondo [ 23/Jul/14 ]

i see, sorry its part of JOIN condition, i've updated the code





[DDC-16] DQL Ignores properties of subclasses Created: 15/Sep/09  Updated: 22/Jul/14  Resolved: 24/Feb/13

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

Type: Improvement Priority: Minor
Reporter: Avi Block Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 6
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1377 Doctrine doesn't understand associati... Closed

 Description   

I have a classes B and C which inherit from superclass A. I would like
to get a list of all A's but filter the list to ignore those in C
which have a property d set to 2.

select a from A where a.d == 2 fails because "d" is not a property of A.



 Comments   
Comment by Roman S. Borschel [ 31/Mar/10 ]

Thats indeed tricky. That syntax alone can, however, never work, because there might be several subclasses that have a field named "d", so Doctrine would not know which field you mean.

We might need special syntax for such constructs but I'm not sure it is worth it. If anyone has an idea, just shoot.

Alternatively, apart from using a native query, what about this DQL:

select a from A a where a.id not in (select c.id from C c where c.d = 2)
Comment by Benjamin Eberlei [ 01/Apr/10 ]

I am sorry, but isn't this sort of query a violation of object oriented programming, Accessing a Superclass A and checking for a property that exists on a certain child is not possible in any strict OO language without specific casting into the type beforehand.

Comment by Roman S. Borschel [ 01/Apr/10 ]

Thats why I said "we would need special syntax for such constructs", i.e. casting syntax

However, the alternative query I showed should work just fine for such purposes.

Comment by Menno Holtkamp [ 18/Jul/11 ]

+1 for this request.

When displaying data (stored in a database) to end-users using generated tables, server-side sorting and filtering on properties that belong to subclasses is a common task, for instance to provide the data presented in a JQuery Datatable: http://www.datatables.net.

For this purpose, DQL is great to generate the required queries dynamically. However, since properties of subclasses can currently not be 'accessed', sorting and filtering on these properties becomes impossible, or at least cumbersome to implement. Currently I have lifted/copied specific properties to a general 'value' property of the superclass, which CAN be used for ordering and filtering. Of course, this work-around significantly decreases the power of inheritance strategy in the originally envisioned model.

In Hibernate this seems to have been solved in HQL using downcasting, which seems a viable approach, but as Benjamin already mentioned not a best practice in a strict OO approach. Therefore a specific syntax might be required to hint on the to-be-expected casts:

For additional motivation of this subject, check a recent post of mine at the user groups: http://groups.google.com/group/doctrine-user/msg/caebf8139e06e01a

Comment by Avi Block [ 18/Jul/11 ]

Honestly I gave up on all of this a long time ago, and now use a CQRS approach. I make views, or denormalized tables for every view in my application, and just use straight SQL.

When I need to do creating or updating or whatever, I use doctrine.

Comment by Glen Ainscow [ 19/Jul/11 ]

I would like this as well (though my use case involves joining to the subclass).

Registration has one Opponent (superclass to Player and TeamSelection). I would like to count the number of registrations for a particular team within a specific tournament. For example:

SELECT COUNT(*)
FROM Registration r
INNER JOIN r.opponent CAST TeamSelection ts
INNER JOIN ts.team t
WHERE r.tournament = 1
AND t.name = "Team #1"
Comment by Glen Ainscow [ 19/Jul/11 ]

Thinking about this a bit more, it can actually improve query performance, as it would no longer be necessary to join the other subclasses. In other words, since you're casting the opponent to a TeamSelection, it's not necessary to join to the players table.

A cast should probably also restrict the result using the discriminator column, for example (SQL):

INNER JOIN opponents o ON o.id = r.opponent_d AND o.type = "TeamSelection"
Comment by Guilherme Blanco [ 15/Sep/11 ]

Possible solution:

SELECT p FROM CAST(Person AS User) p

Or:

SELECT a, p FROM Article a JOIN CAST(a.person AS User) p
Comment by Glen Ainscow [ 16/Sep/11 ]

If you're casting a Person (superclass) to a User (subclass), then shouldn't the alias be "u" and not "p"?

i.e. SELECT a, u FROM Article a JOIN CAST(a.person AS User) u

Comment by Benjamin Eberlei [ 16/Sep/11 ]

the alias is that, an alias, you can use whatever you want.

Comment by Glen Ainscow [ 16/Sep/11 ]

Yes I know that, I'm just making sure that I understand the syntax.

Comment by Jaka Jancar [ 18/Feb/12 ]

I just ran into a similar problem and am not sure the above cast solution would do.

I'm trying to do:

SELECT
    s
FROM
    Superclass s
WHERE
    s INSTANCE OF SubclassA OR
    s INSTANCE OF SubclassB AND s.foo = 'bar';

So I'd need to use CAST in a WHERE condition, not in the FROM/JOIN clause, e.g:

SELECT
    s
FROM
    Superclass s
WHERE
    s INSTANCE OF SubclassA OR
    s INSTANCE OF SubclassB AND (CAST s AS SubclassB).foo = 'bar';
Comment by Wladimir Coka [ 03/Apr/12 ]

Is there any workaround? Would be perfect if I could just:

 SELECT a, p FROM Article a JOIN CAST(a.person AS User) p 

(+1 for Guilherme Blanco possible solution)

Comment by Wladimir Coka [ 04/Apr/12 ]

I was trying a workaround:

Before executing the dql query, I change the mapping info of the association to the concrete type that I was going to use. Like this:

        $cmf = $this->em->getMetadataFactory();
        $class = $cmf->getMetadataFor("Article");
        $class->associationMappings["person"]["targetEntity"]="User";

But now my problem is that I'm actually using an inverse side (in query where this is needed), so when I change the targetEntity, the sql join that is generated, is using the table of the concrete class (User in this case) and not the base class (Person)

class Person {
...
	/**
	 * @OneToOne(targetEntity="Order",cascade={"persist"})
	 * @JoinColumn(name="order_id", referencedColumnName="orden_id")
	 */
	private $order;
...
}

class Order {
...
    /**
     * @OneToOne(targetEntity="Person", mappedBy="order")
     */
    private $person;
...
}

The SQL generated is joining as if the "user" table has orden_id field

Comment by Marco Pivetta [ 24/Feb/13 ]

I am closing this one.

The requirement of this issue is basically violating OO principles.

If you really need to filter across multiple child-entities in your inheritance, then try something as following instead:

SELECT
    r
FROM
    Root r
WHERE
    r.id IN (
        SELECT
            c.id
        FROM
            Child c
        WHERE
            c.field = :value
    )

Up-casting is not really a viable solution anyway, since it would be even more weird to cast in DQL and then have hydration still retrieve the root entity type.

Comment by Bogdan Yurov [ 17/Jul/14 ]

@Marco You are wrong. There is no way to do this. It is just not wise to deny a feature just because it violates OO principles when this is the only method.

There are usecases, when we have nothing to do. For example, we are searching through the whole table in STI. We use quick filters like "Like" so there is not need in difficult indexes/additional tables for them. We CAN NOT in ANY way overcome this limitation when we need to use fields of different classes.

This is certainly not a bug, when we may say "WONT FIX" and just ignore all those people who face it.

Comment by Marco Pivetta [ 17/Jul/14 ]

It is just not wise to deny a feature just because it violates OO principles when this is the only method.

We are working on an ORM (Object-Relational-Mapper), therefore Object-Orientation is first-class citizen and prioritized over everything else in the ORM.

There are usecases, when we have nothing to do.

There are use-cases for everything, but that doesn't mean that they should clutter the tool. This does not only apply to Doctrine ORM. An edge case functionality that has multiple workarounds and that cannot be implemented correctly within the tool does NOT need to land in the tool.

I provided a workaround that respects the OO and ORM rules and works also with the OO paradigm. Here is a pseudo-code description of what the DQL I pasted above does:

  • select all objects that are instance of Child by $someCriteria
  • select all objects that are instance of Root
  • iterate over Root instances and filter out those that are not in the results of the first selection

We CAN NOT in ANY way overcome this limitation when we need to use fields of different classes.

Yes you can: there's SQL. SQL is a "structured query language" that is weakly typed and allows this sort of operation natively. This is a problem of the SQL domain, and it should be solved with SQL whenever the DQL becomes too complex/limited. Don't try to stuff a feature that is only possible in the SQL domain into DQL just because they look similar.
They are not the same thing.

This is certainly not a bug, when we may say "WONT FIX" and just ignore all those people who face it.

We are not ignoring the problem: we just point you to the right scope/tools to solve it. DQL has one way of solving it, which may or may not be viable to you. SQL has another way of solving this same problem, and it's not going to be implemented in DQL because DQL is statically typed, and upcasts and type juggling are not going to land in DQL.

Comment by Bogdan Yurov [ 17/Jul/14 ]

If we provide a workaround, is there any way to merge it to master branch? What we can do to vote up this feature?

Comment by Marco Pivetta [ 17/Jul/14 ]

Bogdan Yurov we already tried looking into this multiple times.

The only "clean-ish" solution would be to support upcasting somehow, and the effort and complexity derived from it is not worth it.

Comment by Bogdan Yurov [ 17/Jul/14 ]

@ocramius
What about "CAST()" construction? You were talking about OO, but there are some languages, that could argue with you.

For example, Delphi. It supports casting manually to selected type (for example TObject -> TButton). Does it break best violates OO principles too? No, of course.
Another example is Java. It has exactly same language construction for exactly same purpose. Is doctrine more concentrated on OO principles than Java or Delphi?

Comment by Marco Pivetta [ 22/Jul/14 ]

Bogdan Yurov I think Guilherme Blanco is thinking of providing a cast syntax.





[DDC-3223] Failing test (get id return string type) Created: 22/Jul/14  Updated: 22/Jul/14

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

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

Linux Ubuntu 13.10 / PHP 5.5.3 / Mysql 5.5.x



 Description   

I found an issue in a specific case, when you find a child entity (JOINED) which is linked to another child entity.

If I clone the linked child entity and call getId(), it gives the value as 'string' rather than 'integer'. If I set the property id as public, there is no problem.

If I call getId on the child entity rather than the clone, it gives 'integer' as expected. So it's weird...

See failing test here: https://github.com/doctrine/doctrine2/pull/1086






[DDC-2366] [GH-627] update document on Doctrine cache provider Created: 22/Mar/13  Updated: 22/Jul/14  Resolved: 24/Mar/13

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

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


 Description   

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

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

Message:

A number of methods have been deleted long time ago. But they still show up on the document page.

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/caching.html#deleting

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/caching.html#counting

I checked source code. Most of the methods don't exist. They are better to be removed from the doc. I tried to use those functions and was surprised that they didn't exist.



 Comments   
Comment by Benjamin Eberlei [ 24/Mar/13 ]

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

Comment by Doctrine Bot [ 22/Jul/14 ]

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





[DDC-3132] [GH-1035] Problem with orphanRemoval Created: 21/May/14  Updated: 22/Jul/14  Resolved: 22/Jul/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 raziel057:

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

Message:

Hi,

I created 2 tests to show that we encounter a problem when using orphanRemoval (see https://github.com/raziel057/doctrine2/commit/2e0323534b72f2923e72596414c6dea548be3b1f).

-> The ActionLog is created with no value in the "action" column.

That's not the case when removing manually (see https://github.com/raziel057/doctrine2/commit/7288077cdcb59944063a973ab9a830e04ecb7e3e).

-> The ActionLog is created with value "remove" in the "action" column.

I think the behavior must be the same in the 2 Tests.



 Comments   
Comment by Doctrine Bot [ 22/Jul/14 ]

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





[DDC-2376] [GH-635] Function test for addManyToOne database column mapping Created: 27/Mar/13  Updated: 22/Jul/14  Resolved: 30/Mar/13

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


 Description   

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

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

Message:

When the PHPDriver is used to create a ManyToOne relationship with a table which has a primary key other than id the primary key is not associated correctly.



 Comments   
Comment by Benjamin Eberlei [ 30/Mar/13 ]

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

Comment by Doctrine Bot [ 22/Jul/14 ]

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





[DDC-3222] PostUpdate event destroying collectionUpdates Created: 21/Jul/14  Updated: 21/Jul/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: Critical
Reporter: Jacob Spizziri Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Mac OSX, AMP, php 5.3.27



 Description   

I have an entity that contains a Many-To-Many Unidirectional association. When the association is updated and the entity is flushed the changes are not being persisted to the database.

This is because the postUpdate event is being fired on executeUpdates, which is being called before the collection updates are being processed here:

            // Collection updates (deleteRows, updateRows, insertRows)
            foreach ($this->collectionUpdates as $collectionToUpdate) {
                $this->getCollectionPersister($collectionToUpdate->getMapping())->update($collectionToUpdate);
            }

This is occurring in UnitOfWork->commit() lines 333 through 366.

Apparently the postUpdate listener I wrote was causing the collectionUpdates property to be erased.



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

What does the listener actually do? Doesn't look like a bug to me...

Comment by Jacob Spizziri [ 21/Jul/14 ]

I'm using FOSElasticaBundle/ElasticSearch. On the postUpdate event I'm calling fos:elastica:populate on the entity indexes. Heres the code

<?php

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */

namespace SRC\Bundle\SearchBundle\EventListener;

use Symfony\Component\Console\Input\ArrayInput;
use Symfony\Component\Console\Output\NullOutput;
use Doctrine\ORM\Event\LifecycleEventArgs;
use SRC\Bundle\ProductBundle\Entity\Product;
use SRC\Bundle\UserBundle\Entity\User;

/**
 * Description of SearchIndexer
 *
 * @author jacobspizziri
 */
class SearchIndexer
{	
	protected $container;
	protected $logger;
	
	public function __construct($container, $logger) {
		$this->container = $container;
		$this->logger = $logger;
	}
	
	
	public function postUpdate(LifecycleEventArgs $args){
		$this->index($args);
	}
	
	protected function index($args){
		$entity = $args->getEntity();

		$arguments = false;
		$command = new \FOS\ElasticaBundle\Command\PopulateCommand();
		$command->setContainer($this->container);
		
		//TODO: probably need to specify the --env=prod/dev
		// update Elastica on Product update
		if ($entity instanceof Product) {
			$this->logger->info('Updating Product Search Indexes');
			
			$arguments = array(
					'--index'=>'website',
					'--type' => 'product'
					);
		} else if ($entity instanceof User) {
			$this->logger->info('Updating User Search Indexes');

			$arguments = array(
					'--index'=>'website',
					'--type' => 'user'
					);
		}
		
		
		if($command && $arguments){
			$input = new ArrayInput($arguments);
			$output = new NullOutput();
			
			$result = $command->run($input, $output);
			$this->logger->info('Finished Updating Search Indexes with result: '. strval($result));
		}
	}
}
?>

Am I using this event incorrectly? Should I only be using postPersist?





[DDC-2360] [GH-622] Import EntityManager from proper namespace Created: 21/Mar/13  Updated: 21/Jul/14  Resolved: 01/May/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 21/Mar/13 ]

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

Comment by Doctrine Bot [ 21/Jul/14 ]

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





[DDC-3221] Invalid binding for primary key of entity relation Created: 21/Jul/14  Updated: 21/Jul/14

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

Type: Bug Priority: Major
Reporter: Alexandr Smaga Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Hello.

We use doctrine2 ORM with doctrine/doctrine-bundle in our symfony2 based project. We developed functionality which is similar to some kind of import process.

And we have an issue that appears from time to time in different points during the import.

Issue is following:
Lets imagine we have 3 entities Account, Contact, Contact Address.
Account has many to one relation on contact and contact has one to many relation on contact address.

Our import creates all 3 entities and persist only Account, contact and address are persisted via cascade persist.
We have writer that contains following code

    public function write(array $items)
    {
        try {
            $this->entityManager->beginTransaction();
            foreach ($items as $item) {
                $this->entityManager->persist($item);
            }
            $this->entityManager->commit();
        } catch (\Exception $exception) {
            $this->entityManager->rollback();

            throw $exception;
        }
        $this->entityManager->flush();
        $this->entityManager->clear();
    }

So we clear EntityManager for each batch in order to avoid high memory consumption.
Import fails during different entities insert, but errors are very similar.
Example of error is

> [error] An exception occurred while executing 'INSERT INTO ... VALUES (?, ?, ?, ?, ?)' with params ["__start__", "2014-07-21 00:55:35", 0, null, 21]:
>
> SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`DB`.`account`, CONSTRAINT `FK_B3D57B301023C4EE` FOREIGN KEY (`contact_id`) REFERENCES `contact` (`id`) ON DELETE CASCADE)

After debugging I found that problem is in BasicEntityPersister#prepareUpdateData

$uow->getEntityIdentifier($newVal);


returns oid that is real one, but UOW contains not the same ID as in $newVal entity. It seems like spl_object_hash duplicates oid.

Any help is appreciated.
Thanks in advance.






[DDC-3220] Association mappings of embedded class not loaded into entity classMetadata Created: 21/Jul/14  Updated: 21/Jul/14

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

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


 Description   

method inlineEmbeddable from Doctrine\ORM\Mapping\ClassMetadataInfo mapped only columns, but relations is omitted






[DDC-3219] Ensure PersistentCollection->count() is of type int Created: 21/Jul/14  Updated: 21/Jul/14

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

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

SQL Server 2012



 Description   

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/PersistentCollection.php#L566-L577 does not always return an int. How do i know this? because i compare this count with a php count() with strict checking.

If ($collection->count() !== count($somethingElse))

{ throw new Exception($collection->count() . ' is different then ' . count($somethingElse)); }

and at one time this message showed: 3 is different then 3



 Comments   
Comment by Flip [ 21/Jul/14 ]

My colleague told me that it was his mistake somehow, so i don't know how valid this really is !!!





[DDC-3218] Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given Created: 18/Jul/14  Updated: 18/Jul/14

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

Type: Bug Priority: Major
Reporter: Grégoire Pineau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux / Mint 15
php 5.5.*



 Description   

Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given, called in /home/greg/dev/product/insight/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 1009 and defined

Stack trace:

[1] PHPUnit_Framework_Error: Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given, called in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 1009 and defined
at n/a
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

at PHPUnit_Util_ErrorHandler::handleError('4096', 'Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be of the type array, null given, called in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 1009 and defined', '/project/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php', '47', array('entity' => object(Violation), 'em' => object(EntityManager)))
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

at Doctrine\ORM\Event\PreUpdateEventArgs->__construct(object(Violation), object(EntityManager), null)
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 1009

at Doctrine\ORM\UnitOfWork->executeUpdates(object(ClassMetadata))
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 341

at Doctrine\ORM\UnitOfWork->commit(null)
in /project/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 389

at Doctrine\ORM\EntityManager->flush()
in /project/src/SensioLabs/Bundle/MyBundle/Controller/MyController.php line 127

at SensioLabs\Bundle\MyBundle\Controller\MyController->ignoreAction(object(Request), object(Project), object(Analysis), '4')
in line

at call_user_func_array(array(object(MyController), 'ignoreAction'), array(object(Request), object(Project), object(Analysis), '4'))
in /project/app/bootstrap.php.cache line 1043

at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), '1')
in /project/app/bootstrap.php.cache line 1015

at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), '1', true)
in /project/app/bootstrap.php.cache line 1154

at Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(object(Request), '1', true)
in /project/app/bootstrap.php.cache line 435

at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
in /project/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Client.php line 81

at Symfony\Component\HttpKernel\Client->doRequest(object(Request))
in /project/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Client.php line 111

at Symfony\Bundle\FrameworkBundle\Client->doRequest(object(Request))
in /project/vendor/symfony/symfony/src/Symfony/Component/BrowserKit/Client.php line 319

at Symfony\Component\BrowserKit\Client->request('POST', '/projects/id-foo/analyses/2/rule/4/ignore', array('ignore_rule' => array('comment' => 'Message about why this rule has been ignored', '_token' => 'CxEFTSv4GZQSWYXtRt-eHybaML4z8I0WK1DHiwr8Ih0')))
in /project/src/SensioLabs/Bundle/MyBundle/Test/Client.php line 489

at SensioLabs\Bundle\MyBundle\Test\Client->ignoreRuleViolations('id-foo', '2', '4', false)
in /project/src/SensioLabs/Bundle/MyBundle/Tests/Acceptance/ViolationCommentsTest.php line 217

at SensioLabs\Bundle\MyBundle\Tests\Acceptance\ViolationCommentsTest->testDashboardWithCriticalIgnoredRules()
in line

at ReflectionMethod->invokeArgs(object(ViolationCommentsTest), array())
in /project/vendor/phpunit/phpunit/src/Framework/TestCase.php line 951

at PHPUnit_Framework_TestCase->runTest()
in /project/vendor/phpunit/phpunit/src/Framework/TestCase.php line 817

at PHPUnit_Framework_TestCase->runBare()
in /project/vendor/phpunit/phpunit/src/Framework/TestResult.php line 686

at PHPUnit_Framework_TestResult->run(object(ViolationCommentsTest))
in /project/vendor/phpunit/phpunit/src/Framework/TestCase.php line 753

at PHPUnit_Framework_TestCase->run(object(PHPUnit_Framework_TestResult))
in /project/vendor/phpunit/phpunit/src/Framework/TestSuite.php line 675

at PHPUnit_Framework_TestSuite->run(object(PHPUnit_Framework_TestResult))
in /project/vendor/phpunit/phpunit/src/TextUI/TestRunner.php line 426

at PHPUnit_TextUI_TestRunner->doRun(object(PHPUnit_Framework_TestSuite), array('listGroups' => false, 'loader' => null, 'useDefaultConfiguration' => true, 'configuration' => '/project/app/phpunit.xml.dist', 'filter' => 'testDashboardWithCriticalIgnoredRules', 'testSuffixes' => array('Test.php', '.phpt')))
in /opt/dotfiles/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php line 176

at PHPUnit_TextUI_Command->run(array('/usr/local/bin/phpunit', 'c', 'app/', '-filter', 'testDashboardWithCriticalIgnoredRules', 'src/SensioLabs/Bundle/MyBundle/Tests/Acceptance/ViolationCommentsTest.php'), true)
in /opt/dotfiles/vendor/phpunit/phpunit/PHPUnit/TextUI/Command.php line 129

at PHPUnit_TextUI_Command::main()
in /opt/dotfiles/vendor/phpunit/phpunit/composer/bin/phpunit line 63

I fails in this code

    private function executeUpdates($class)
    {
        $className          = $class->name;
        $persister          = $this->getEntityPersister($className);
        $preUpdateInvoke    = $this->listenersInvoker->getSubscribedSystems($class, Events::preUpdate);
        $postUpdateInvoke   = $this->listenersInvoker->getSubscribedSystems($class, Events::postUpdate);

        foreach ($this->entityUpdates as $oid => $entity) {
            if ($this->em->getClassMetadata(get_class($entity))->name !== $className) {
                continue;
            }

            if ($preUpdateInvoke != ListenersInvoker::INVOKE_NONE) {
// => this line
                $this->listenersInvoker->invoke($class, Events::preUpdate, $entity, new PreUpdateEventArgs($entity, $this->em, $this->entityChangeSets[$oid]), $preUpdateInvoke);
                $this->recomputeSingleEntityChangeSet($class, $entity);
            }

            if ( ! empty($this->entityChangeSets[$oid])) {
                $persister->update($entity);
            }

            unset($this->entityUpdates[$oid]);

            if ($postUpdateInvoke != ListenersInvoker::INVOKE_NONE) {
                $this->listenersInvoker->invoke($class, Events::postUpdate, $entity, new LifecycleEventArgs($entity, $this->em), $postUpdateInvoke);
            }
        }
    }


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

Requires a test case





[DDC-3217] [GH-1084] Update advanced-field-value-conversion-using-custom-mapping-types.rst Created: 17/Jul/14  Updated: 17/Jul/14  Resolved: 17/Jul/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 hartca:

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

Message:

Class name correction.



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

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

Comment by Marco Pivetta [ 17/Jul/14 ]

Merged into master (2.5.x)





[DDC-3215] wrong quotation Created: 16/Jul/14  Updated: 17/Jul/14

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

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


 Description   

when doctrine build query´s, for example when you doing

$entitity->getTest()->clear();

following queries are generated (test_id is integer in mysql):

DELETE FROM test WHERE test_id = '6'

Is this right?
For me the right query would be:

DELETE FROM test WHERE test_id = 6

as in http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html
6 will be converted to float, this can be an issue, or?

Comparisons that use floating-point numbers (or values that are converted to floating-point numbers) are approximate because such numbers are inexact. This might lead to results that appear inconsistent:

mysql> SELECT '18015376320243458' = 18015376320243458;
        -> 1
mysql> SELECT '18015376320243459' = 18015376320243459;
        -> 0

this also happens in dql sometimes, why doctrine does this not automatic right due to description in the entities?

     /**
     * @ORM\Id @ORM\Column(type="integer")
     * @ORM\GeneratedValue
     */


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

Could you please convert this to a failing test case? Doctrine doesn't quote integers as strings by default.

Comment by revrev [ 16/Jul/14 ]

i try to describe what i have done

i have an Entity with:

    /**
     * @ORM\ManyToMany(targetEntity="Messen", inversedBy="vertrag_messen")
     * @ORM\JoinTable(name="vertrag_messen")
     **/
    private $vertrag_messen;

    public function __construct()
    {
        $this->vertrag_messen = new \Doctrine\Common\Collections\ArrayCollection();
    }

    public function getMessen()
    {
        return $this->vertrag_messen;
    }

when i now clear the Data

$entitity->getMessen()->clear();

following query is created
DELETE FROM vertrag_messen where messe_id = '6'

Should here not set the value 6 as integer (param_int) (DELETE FROM test vertrag_messen where messe_id = 6) that mysql doesn´t have to cast the value? (http://dev.mysql.com/doc/refman/5.5/en/type-conversion.html) or is this not an problem?

Comment by Marco Pivetta [ 16/Jul/14 ]

is messe_id in your entity an integer or a string at the moment in time when that query is being executed?

Comment by revrev [ 16/Jul/14 ]

the value comes automatic
$entitity = $em->getRepository('Base\Entities\Vertrag')>find(intval($data["id"]));

i don´t set messe_id here

Comment by Marco Pivetta [ 16/Jul/14 ]

Can you var_dump the Base\Entities\Messe instance?

Comment by revrev [ 16/Jul/14 ]

object(stdClass)#1014 (64) {
["__CLASS__"]=>
string(24) "Base\Entities\Vertrag"
["id"]=>
int(6)
[„vertrag_messen"]=>
array(1)

Unknown macro: { [0]=> string(20) "BaseEntitiesMessen" }


["erstellungsdatum"]=>
object(stdClass)#1210 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2013-09-28T00}

["zeitraumvon"]=>
NULL
["zeitraumbis"]=>
NULL
["jahr"]=>
int(2014)
["created"]=>
object(stdClass)#1178 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2013-09-28T19}

["updated"]=>
object(stdClass)#1177 (3)

Unknown macro: { ["__CLASS__"]=> string(8) "DateTime" ["date"]=> string(25) "2014-07-16T17}

["uuid"]=>
string(36) "52470c58-4288-45eb-b75f-0c41c0a81437"
}

Comment by Marco Pivetta [ 17/Jul/14 ]

yeah, integer identifier there.
Could you verify if the problem also comes up with current master? I think this issue is related with another one that was fixed some months ago in 2.5.x-dev





[DDC-3073] @Column options Created: 07/Apr/14  Updated: 17/Jul/14  Resolved: 17/Jul/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: Flip Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
depends on DDC-3216 [GH-1083] [DDC-3073] Add documentatio... Resolved

 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



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

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

Comment by Doctrine Bot [ 17/Jul/14 ]

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

Comment by Marco Pivetta [ 17/Jul/14 ]

Handled in DDC-3216





[DDC-3216] [GH-1083] [DDC-3073] Add documentation about how to map column options Created: 17/Jul/14  Updated: 17/Jul/14  Resolved: 17/Jul/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

Issue Links:
Dependency
is required for DDC-3073 @Column options Resolved

 Description   

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

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

Message:

Adding documentation about currently accepted column options in mappings. Also providing some more examples how to map column options for each driver.



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

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





[DDC-3213] [GH-1081] Add "additional commands" to the Console Runner Created: 15/Jul/14  Updated: 15/Jul/14  Resolved: 15/Jul/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 kander:

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

Message:

Currently, using Migrations in a Doctrine projects requires you to roll your own CLI. We already have a cli-config.php which is called when running /vendor/bin/doctrine.php - however, that only allows us to inject a HelperSet. It does not offer a mechanism to inject additional commands into the CLI application.

If this patch is accepted, I'll submit a suggestion for Migrations' documentation to call:

ConsoleRunner::addAdditionalCommand(new \Doctrine\DBAL\Migrations\Tools\Console\Command\DiffCommand);
ConsoleRunner::addAdditionalCommand(new \Doctrine\DBAL\Migrations\Tools\Console\Command\ExecuteCommand);
... etc

I'm not 100% whether line 73 should be in ConsoleRunner::addCommands() or ConsoleRunner::run() - I've placed it in run() for now.



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

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





[DDC-3214] [GH-1082] added more informative error messages when invalid parameter count Created: 15/Jul/14  Updated: 15/Jul/14  Resolved: 15/Jul/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 rodnaph:

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

Message:

When an invalid number of parameters is bound current it's not indicated if there are too few or too many (which could help a lot in trying to debug the problem). This change alters the exception message to be more informative as to whether too few or too many parameters have been bound in the query.



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

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





[DDC-2953] ArrayHydrator: Not all items hydrated while orderBy Created: 05/Feb/14  Updated: 14/Jul/14

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

Type: Bug Priority: Critical
Reporter: Mariusz Jaskółka Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: array, hydration
Environment:

Linux and Windows, PHP5


Attachments: File ArrayHydrator.php     File Array_Hydrator_4.2.php     File Array_hydrator_4.2_bugfix.php    

 Description   

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

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

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

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

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

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



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

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

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

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

Comment by Marco Pivetta [ 06/Feb/14 ]

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

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

Version 2.4.2 oryginal file and bugfix

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

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

Comment by Marco Pivetta [ 06/Feb/14 ]

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

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

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

Comment by Marco Pivetta [ 06/Feb/14 ]

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

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

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

Comment by Marco Pivetta [ 06/Feb/14 ]

Mariusz Jaskółka fixed, thanks!

Comment by Marco Pivetta [ 14/Jul/14 ]

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

Comment by Guilherme Blanco [ 14/Jul/14 ]

... and introducing BC breaks.





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

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

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


 Description   

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

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

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

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

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



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

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





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


 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.



 Comments   
Comment by Doctrine Bot [ 14/Jul/14 ]

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





[DDC-3139] [GH-1038] Add documentation for the `HIDDEN` keyword in DQL Created: 27/May/14  Updated: 14/Jul/14  Resolved: 14/Jul/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 michaelperrin:

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

Message:

I can rebase this PR to the `2.2` branch if needed, as the `HIDDEN` keyword is available since this version.



 Comments   
Comment by Doctrine Bot [ 14/Jul/14 ]

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

Comment by Marco Pivetta [ 14/Jul/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/5361676bba4d7bdc81ce728f82e50b5982436489





[DDC-3209] [GH-1079] HHVM compatibility: func_get_args Created: 08/Jul/14  Updated: 14/Jul/14  Resolved: 14/Jul/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 lattwood:

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

Message:

All func_get_args() calls have been moved to the top of the methods
because HHVM doesn't keep a copy of the original args for performance
reasons.

See facebook/hiphop-php#1027 for details.



 Comments   
Comment by Doctrine Bot [ 14/Jul/14 ]

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

Comment by Marco Pivetta [ 14/Jul/14 ]

Won't be fixed in 2.4.x





[DDC-2494] Proxy getId not invoke convertToPHPValue on custom type Created: 08/Jun/13  Updated: 14/Jul/14  Resolved: 12/Jun/13

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

Type: Bug Priority: Critical
Reporter: Eduardo Oliveira Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-3192 Custom types do not get converted to ... Resolved

 Description   

I have a custom type tinyint:
https://gist.github.com/entering/3503d7458e5fbe2f6e02

I was using it a lot and when I updated to doctrine 2.4 beta it break some stuff. At the time i turn all on smallint and solve the problem, now I had time to look into it.

Example, entity Currency:

    /**
     * @var integer
     *
     * @ORM\Column(name="id", type="tinyint", nullable=false, options={"unsigned": true})
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\Column(name="temp", type="tinyint", nullable=false)
     */
    protected $temp;

Entity Campaign:

    /**
     * @var Currency
     *
     * @ORM\ManyToOne(targetEntity="Currency", inversedBy="campaigns")
     * @ORM\JoinColumns({
     *   @ORM\JoinColumn(name="currency_id", referencedColumnName="id", nullable=false)
     * })
     */
    protected $currency;

When i have this piece of code:

var_dump($campaign->getCurrency()->getId());
var_dump($campaign->getCurrency()->getTemp());

I get:
string(1) "1"
int(5)

If I turn id into small int:
int(1)
int(5)

If I switch the order to:

var_dump($campaign->getCurrency()->getTemp());
var_dump($campaign->getCurrency()->getId());

As expected:
int(5)
int(1)

If I place a var_dump on convertToPHPValue I can see that is not being called on getId when getId is lazy.

This looks like a bug introduced when getId started being lazy to save queries.



 Comments   
Comment by Fabio B. Silva [ 10/Jun/13 ]

Before DCOM-96 we ignore custom type fields while looking for identifier getters.
It mean that, when an identifier getter is called the entity will be loaded from database, even though the identifier value is already known.
Then the Type#convertToPHPValue will be invoked..

After we move the proxy generation to common custom types are ignored and the database load its no longer triggered.

Comment by Eduardo Oliveira [ 10/Jun/13 ]

I understand the problem, because I was aware that getId() now doesn't load entity from DB, what is great in performance, I was expecting this for a while.

For me is really bad I cannot have ID's as tinyint (custom type), i suppose Doctrine doesn't support tinyint because is not present in all DB's, but some DB's like MySQL support it, I agree that Doctrine doesn't need to support all types out the box, but custom types should work exactly like native types, shouldn't be second class citizens.

If this is a limitation that is difficult to overpass and there are no plans to "fix" it, should be listed here: http://docs.doctrine-project.org/en/latest/reference/limitations-and-known-issues.html

And should be listed as BC in here: https://github.com/doctrine/doctrine2/blob/master/UPGRADE.md

If there are plans to fix this problem and is just a case of someone put hands on the code I can give it a shot even I'm not completely familiar with Doctrine code.

Comment by Marco Pivetta [ 10/Jun/13 ]

I don't think the bug is related with lazy loading. Identifiers are never hydrated into proxies anyway.

What the problem here seems to be is that the type conversion is not applied to meta columns.

You can check and see if there's code about type conversion in meta columns.

Comment by Eduardo Oliveira [ 10/Jun/13 ]

"What the problem here seems to be is that the type conversion is not applied to meta columns."

Marco I'm not sure If I follow you.

So when ID of entity Currency is a smallint a var_dump($campaign->getCurrency()) give this: https://gist.github.com/entering/5751908

  protected $id =>
  string(1) "1"

Is a string, the cast is done on getId()

Looking at the proxy created:

    /**
     * {@inheritDoc}
     */
    public function getId()
    {
       	if ($this->__isInitialized__ === false) {
            return (int)  parent::getId();
        }

        $this->__initializer__ && $this->__initializer__->__invoke($this, 'getId', array());

        return parent::getId();

The cast is written here: https://github.com/doctrine/doctrine2/blob/2.3/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L259

Just to be sure I placed a var_dump inside convertToPHPValue of SmallIntType and on getId() is not called, but if I force the load of entity from DB (code below) converToPHPValue is called.

var_dump($campaign->getCurrency()->getCode());
var_dump($campaign->getCurrency()->getId());

So the problem here is that convertToPHPValue is never called on getId() on proxy when entity is not initialized, the problem is masked with the cast "written on hand" inside the getId().

The way I see it the getId() on proxy should all the time call convertToPHPValue, that way it would be correct with all types (native and custom).

The proxy with tinyint:

    /**
     * {@inheritDoc}
     */
    public function getId()
    {
        if ($this->__isInitialized__ === false) {
            return  parent::getId();
        }


        $this->__initializer__ && $this->__initializer__->__invoke($this, 'getId', array());

        return parent::getId();
    }

Before custom tinyint was working on Identifiers because getId() would need to load entity from DB, the entity would be hydrate and the convertToPHPValue called at that time, now getId() doesn't load entity from DB so is never called.

To me a cast (int) on proxy that is decided according the name type is a ugly hack, inside if ($this->_isInitialized_ === false) it should call all the time convertToPHPValue.

Comment by Fabio B. Silva [ 11/Jun/13 ]

A possible solution : https://github.com/doctrine/doctrine2/pull/690

Comment by Fabio B. Silva [ 12/Jun/13 ]

Fixed : https://github.com/doctrine/doctrine2/commit/6937061b23ec4de63081efac800415e09dcbcb4f





[DDC-3192] Custom types do not get converted to PHP Value when result is gotten from custom query Created: 26/Jun/14  Updated: 14/Jul/14  Resolved: 14/Jul/14

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

Type: Bug Priority: Major
Reporter: Alexander Kurilo Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: sql-walker

Issue Links:
Duplicate
is duplicated by DDC-3194 [GH-1073] Add missing type mapping Resolved
Reference
relates to DDC-2494 Proxy getId not invoke convertToPHPVa... Resolved

 Description   

The description would be the same as in DDC-2494. It fixes only entity persister, so it works as expected when entity manager's find() is used, but query results that are gotten by DQL query still suffer from the issue: SQLWalker doesn't set type mapping information into the ResultSetMapping.

Pull request with test case in on the way.



 Comments   
Comment by Alexander Kurilo [ 26/Jun/14 ]

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

Comment by Doctrine Bot [ 14/Jul/14 ]

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

Comment by Marco Pivetta [ 14/Jul/14 ]

Merged in https://github.com/doctrine/doctrine2/commit/b80149344dfadcfbdb1d9f4061c5012dec89d223 - discussion at https://github.com/doctrine/doctrine2/pull/1073





[DDC-3194] [GH-1073] Add missing type mapping Created: 26/Jun/14  Updated: 14/Jul/14  Resolved: 14/Jul/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-3192 Custom types do not get converted to ... Resolved

 Description   

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

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

Message:

Fixes DDC-2494, references DDC-3192.

Custom types of joined column are ignored when the query is issued using DQL (query or builder). Entity manager's `findX()`s work as expected because the issue was fixed for entity persister in #690 (DDC-2494).



 Comments   
Comment by Alexander Kurilo [ 26/Jun/14 ]

This is a copy of DDC-3192 — so please, close either one.

Comment by Doctrine Bot [ 14/Jul/14 ]

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

Comment by Marco Pivetta [ 14/Jul/14 ]

Duplicate of DDC-3192





[DDC-2767] ID property of MayToOne association has wrong type Created: 30/Oct/13  Updated: 14/Jul/14

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

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


 Description   

I'm seeing the following behaviour in some Doctrine code I'm writing:

$entity = array_pop($qb->getQuery()->getResult());
echo gettype($entity->getId()) . ' ' . $entity->getId();
// prints: integer 123

$association = $entity->getAssociation(); // unidirectional ManyToOne link to some other entity
echo gettype($association->getId()) . ' ' . $association->getId();
// prints: string 345

When I load the associated entity directly (via find() f.x.), it's ID has the integer type as expected, and the database structure looks correct, too.

I'm not entirely sure if this is a problem in my code or some issue in QueryBuilder or some other Doctrine component, but if someone could point me into the right direction, that would really be helpful.

I guess normally the type of the ID is not so important because you're not supposed to access it directly anyways, but I need to provide backward compatibility for a lot of code written against a different ORM API that provided exactly this behaviour.



 Comments   
Comment by flack [ 07/Nov/13 ]

After some research, the problem sounds kind of similar to

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

only that in my case, it's not a custom type, but a builtin one that is not working. But AFAICT, in both cases it's getting the ID from a proxy that is problematic

Comment by Doctrine Bot [ 14/Jul/14 ]

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





[DDC-2498] [GH-690] [DDC-2494] Apply type conversion to meta columns Created: 11/Jun/13  Updated: 14/Jul/14  Resolved: 12/Jun/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4
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/690

Message:

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



 Comments   
Comment by Doctrine Bot [ 12/Jun/13 ]

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

Comment by Marco Pivetta [ 12/Jun/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/6937061b23ec4de63081efac800415e09dcbcb4f

Comment by Doctrine Bot [ 14/Jul/14 ]

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





[DDC-3211] Annotation @ORM\Table(name="schema.table") don't generate sql using OCI8 Created: 09/Jul/14  Updated: 12/Jul/14

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

Type: Bug Priority: Major
Reporter: Jorge Potosme Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cli, mapping, oci8, oracle, orm, symfony
Environment:

OS: Fedora 20
Web Server: Apache
DBMS: Oracle 12c
Framework: Symfony2
PHP version: 5.5.14
DBMS Driver: OCI8



 Description   

Using Symfony and "doctrine/orm": "2.4.@dev", "doctrine/doctrine-bundle": "1.3.@dev", with OCI8(Oracle Call Interface)
I have an entity
/**
* @ORM\Entity
* @ORM\Table(name="rrhh.usuario")
*/
class Usuario implements UserInterface

{ ... }

When i use de CLI (php app/console doctrine:schema:create --dump-sql) this don't show nothing, the output is empty.

If i change (name="rrhh.usuario") to (name="usuario", schema="rrhh") the CLI show the sql query but without the schema.



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

Duplicates this issue





[DDC-2021] Array Data in Member OF Created: 09/Sep/12  Updated: 11/Jul/14  Resolved: 11/Jul/14

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

Type: New Feature Priority: Major
Reporter: vahid sohrabloo Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: array, dql

Issue Links:
Reference
is referenced by DDC-3210 [GH-1080] possible fix for DDC-2021 Resolved

 Description   

Hi.
First sorry for my bad english.
In
SELECT u.id FROM CmsUser u WHERE :groupId MEMBER OF u.groups
DQL we can't use Array of groupId like



 Comments   
Comment by Daniel Sippel [ 09/Jul/14 ]

+1

Simple solution could be this: use SQL IN(value) always instead of the equality sign..

Current situation:
500 Internal Server Error - DBALException
1 linked Exception: PDOException »

An exception occurred while executing 'SELECT w0_.id AS id0, w0_.userId AS userId1, w0_.profileName AS profileName2, w0_.url AS url3, w0_.companyName AS companyName4, w0_.firstName AS firstName5, w0_.lastName AS lastName6, w0_.street AS street7, w0_.houseNo AS houseNo8, w0_.postcode AS postcode9, w0_.city AS city10, w0_.phoneNo AS phoneNo11, w0_.faxNo AS faxNo12, w0_.email AS email13, w0_.websiteUrl AS websiteUrl14, w0_.description AS description15, w0_.created AS created16, w0_.updated AS updated17, w0_.offersFurther AS offersFurther18, w0_.companyLogoImageFileExtension AS companyLogoImageFileExtension19, w0_.location AS location20 FROM profile w0_ WHERE 1 = 1 AND (GLength(LineString(w0_.location, GeomFromText(?)))*100 < 30) AND EXISTS (SELECT 1 FROM profile_attribute_mapping p1_ INNER JOIN profile_attribute w2_ ON p1_.profileattribute_id = w2_.id WHERE p1_.profile_id = w0_.id AND w2_.id = ?, ?)' with params [{}, 1, 2]:

SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' 2)' at line 1
Comment by Daniel Sippel [ 09/Jul/14 ]

pull request https://github.com/doctrine/doctrine2/pull/1080

Solution: use SQL IN(value) always instead of the equality sign

Comment by Doctrine Bot [ 11/Jul/14 ]

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

Comment by Marco Pivetta [ 11/Jul/14 ]

Handled in DDC-3210, see https://github.com/doctrine/doctrine2/commit/ae0ee724252b8aaf41be9b397d3db3375767095d





[DDC-3210] [GH-1080] possible fix for DDC-2021 Created: 09/Jul/14  Updated: 11/Jul/14  Resolved: 11/Jul/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:
Reference
relates to DDC-2021 Array Data in Member OF Resolved

 Description   

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

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

Message:



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

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

Comment by Marco Pivetta [ 11/Jul/14 ]

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





Regression in reComputeSingleEntityChangeset (DDC-3160)

[DDC-3208] Merge DDC-3160 back into 2.4.x Created: 06/Jul/14  Updated: 11/Jul/14  Due: 11/Jul/14  Resolved: 11/Jul/14

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

Type: Sub-task Priority: Blocker
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 3
Labels: changeset, listener, unitofwork

Issue Links:
Reference
is referenced by DDC-2996 UnitOfWork::recomputeSingleEntityChan... Resolved

 Description   

DDC-3160 should be backported to 2.4.4 once user feedback is collected.



 Comments   
Comment by Kevin Bond [ 06/Jul/14 ]

I ran the DoctrineExtensions test suite with ORM 2.4 with this fix and it passed.

Comment by Justin Zimmerman [ 06/Jul/14 ]

For the project I was working on where I started having issues with the 2.4.3 update and Atlantic18/DoctrineExtensions, the DDC-3160 solution did fix the problems that I was seeing. Granted, I am only using the Tree portion of that library, I cannot say anything about the other parts of it.

I just ran a test with the latest DoctrineExtensions code. These are the results I get with running Doctrine 2.4.3:

FAILURES!
Tests: 411, Assertions: 1760, Errors: 71, Skipped: 62.

When I patch up the Doctrine 2.4.3 branch with the DDC-3160 fix, I get much better results:

OK, but incomplete, skipped, or risky tests!
Tests: 411, Assertions: 2410, Skipped: 62.

From what I can tell, this does seem to fix the DoctrineExtensions issues which I believe was eventually tracked down to being caused by the DDC-2996 fix.

Comment by Eric Coleman [ 08/Jul/14 ]

Patch is working for us.

Comment by Marco Pivetta [ 10/Jul/14 ]

Going to merge this back into 2.4.x asap

Comment by Marco Pivetta [ 11/Jul/14 ]

Merged at https://github.com/doctrine/doctrine2/commit/5c5abb6771c1f5ab8318f76aed79ce1da8a0300d





[DDC-1988] Add Any and ManyToAny annotations Created: 18/Aug/12  Updated: 10/Jul/14

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

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


 Description   

It would be really nice to have @Any and @ManyToAny relations/annotations implemented like on Hibernate.
http://docs.jboss.org/hibernate/orm/4.1/javadocs/org/hibernate/annotations/ManyToAny.html
Right now I've implemented these in a Symfony2 bundle (that I'd be happy to share once it's ready and a bit documented), using listeners on postLoad, preFlush and prePersist
However I think this is a very common use case that anyone will encounter at least once/twice in every middle/big-sized project, and for this reason I think this should be implemented as a core feature.






[DDC-3062] [GH-997] [FIX] Allow to use ManyToMany with all operators Created: 31/Mar/14  Updated: 08/Jul/14

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

Type: Bug Priority: Critical
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-2368] [GH-629] Fixed typos in Doctrine Mapping Types section. Created: 24/Mar/13  Updated: 08/Jul/14  Resolved: 08/Sep/13

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

Type: Documentation Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Hello guys! I am fixing some of the documentation in ``basic-mapping.rst`` that display an incorrect use of 'an' where 'a' should reside. Specifically in regards to instances of 'an SQL'.



 Comments   
Comment by Benjamin Eberlei [ 24/Mar/13 ]

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

Comment by Doctrine Bot [ 08/Jul/14 ]

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





[DDC-2332] [UnitOfWork::doPersist()] The spl_objact_hash() generate not unique hash! Created: 05/Mar/13  Updated: 08/Jul/14

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

Type: Bug Priority: Major
Reporter: Krisztián Ferenczi Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Symfony 2.1.8, php 5.4.7 and php 5.4.12, Windows 7


Attachments: Text File hashlogs.txt    

 Description   

I created fixtures and some data was inserted many times without calling the Task entity PrePersist event listener.

I printed the used and generated hash and I saw a Proxies_CG_\Asitly\ProjectManagementBundle\Entity\User hash equal a Task entity hash!



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

Please provide either a code example or a test case. As it stands, this issue is incomplete

Comment by Benjamin Eberlei [ 05/Mar/13 ]

Are you calling EntityManager#clear() inbetween? Because PHP reuses the hashes. The ORM accounts for this.

Comment by Benjamin Eberlei [ 05/Mar/13 ]

This is not a reproduce case, i don't want to execute your whole project.

I want to know, what is the actual bug that you see? Can you just print a list of all the hashes? Because the hashes dont differ at the end, bu tjust somewhere in the middle.

Comment by Krisztián Ferenczi [ 05/Mar/13 ]

I attached a hashlogs.txt file. The last Task class hash is 0000000050ab4aba0000000058e1cb12 ( line 3 129 )

This is not unique, view the line 2 760 . The Task is not being saved and the program don't call the prePersist listener. The "UnitOfWork" believe the entity has been saved because the isset($this->entityStates[$oid]) is true. But it is an other entity.

Comment by Krisztián Ferenczi [ 06/Mar/13 ]

The EntityManager::clear() fix the problem, but this is not "good" and "beautiful" solution. Shows no sign of that conflicts were and this is causing the problem. I was looking for the problem 7 hours.

Comment by Marco Pivetta [ 26/Jun/14 ]

One possible issue here is that a listener registers an entity as managed while a proxy is being loaded.

The given data is still insufficient to actually verify the problem.





[DDC-3207] Paginator does not count according to query max results Created: 05/Jul/14  Updated: 08/Jul/14  Resolved: 06/Jul/14

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

Type: Bug Priority: Major
Reporter: Draeli Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: orm
Environment:

Windows



 Description   

I use Doctrine\ORM\Tools\Pagination\Paginator to have an paginate object and use like this :

$paginator = new Paginator($query);
$paginator->getQuery()->setFirstResult(0)->setMaxResults(1);

In this case when I do a count on object result and have "int 2" in spite I expected "int 1".

I look the class and find may be the problem, why there is this ?

$countQuery->setFirstResult(null)->setMaxResults(null);

in "count" method.

If I remove this line, expected result appear.



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

The paginator will always count over the entire resultset of your query, since that is its primary purpose together with providing iteration over slices of the resultset.

Comment by Draeli [ 06/Jul/14 ]

I can understand the global count but for example (and now I saw why the line I descripbe above is) in case I use with Twig for iterate (with

{% for %}

syntax), the length return by object|length not appear to be what expected because if the goal of Pagination is to expose method to work more easier with object, I supose you must only work with current page object result and the total count must be expose in method but not directly as iterator count result.

Comment by Marco Pivetta [ 06/Jul/14 ]

Draeli the count($paginator) will give you the total items. The current offset and limit can be trusted to get the items in the current page.

Comment by Draeli [ 06/Jul/14 ]

I understood about the count($paginator) but that's not the only point.
Why when I do {{ loop.last }} (inside for loop) this give me "false" in spite it is the last one for the current page ?
Sorry to insist but as simple user of Sf2/Twig/Doctrine I don't understand this logic :/
(or maybe I'm not enough clear)

Comment by Draeli [ 06/Jul/14 ]

To explain more, actually I do a request and give me object :

$paginator = new Paginator($query);
$paginator->getQuery()->setFirstResult(0)->setMaxResults(5);
$Articles = $paginator;

and in the view

{{ dump(Articles|length) }} {# here "int 23" for example in this case because result without limit is 23, ok I understand #}
{% for anArticle in Articles %}
{{ dump(loop.first) }} {# as expected here "true" for the first and false for other #}
{{ dump(loop.last) }} {# always "false" even for the fifth result who is suppose to bu "true" #}
{{ dump(loop.length) }} {# here return always "int 23" in spite expected 5 #}
{% endfor %}
{# for display my 5 object in spite loop.last and loot.length not expected result #}

As you see something is not expected.

Comment by Marco Pivetta [ 06/Jul/14 ]

We can't provide support for Twig integration. That seems to be a Twig specific issue with how twig deals with loops, nothing related with the ORM. Instead, ask on http://stackoverflow.com/

Comment by Draeli [ 06/Jul/14 ]

Ok thank you for your answer, I'm going to ask, just I signal I put question relative to this for Twig here :
https://github.com/symfony/symfony/issues/11316
Have a good day

Comment by Christophe Coevoet [ 07/Jul/14 ]

Iterate over paginator.iterator in Twig, and loop.last will give you wht you want

Comment by Draeli [ 08/Jul/14 ]

A really big thank you Christophe It's work





[DDC-3206] Possible to remove inversedBy (use only mappedBy)? Created: 05/Jul/14  Updated: 07/Jul/14

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

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


 Description   

Hi guys!

This is another developer experience situation. Here is the flow:

1. I setup the owning side of a relationship (let's use ManyToMany, the hardest one for this)

2. Later, I decide to setup the inverse side of the relationship. When I do this, I of course add the `mappedBy` attribute so that it points to the exact property/relationship we're dealing with

3. Then, I also need to go back to the owning side and add `inversedBy`.

Why is step 3 (inversedBy) needed? Isn't this redundant information, since the `mappedBy` fully maps out that these 2 associations form different sides of the same relationship? I would love to remove this, I hate explaining to people starting with relationships to now go back to the main entity to add this key. It feels like duplication, which I think people sense.

Of course, I very well may be wrong and it may be needed .

Thanks!



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

I'd suggest doing the opposite: dropping mappedBy.

I'm not sure why JPA introduced this sort of bidirectional mapping, but for practical purposes, it makes it possible for us to load metadata for associations on both sides of the associations. Without having both mappedBy and inversedBy we'd be forced to scan through all existing mappings to find which pieces of the jigsaw fit together.

I don't think we have a good solution for this except for a "build mappings" step that warms up a cache, and that's a very radical architectural change that we can only introduce in 3.x

Comment by Maxime Veber [ 07/Jul/14 ]

Hi, please excuse me if what I say is wrong and do not hesitate to correct me, it's my first immertion in Doctrine code .

So I checked a little bit the situation in the code. I don't see the problem dropping inversedBy. It's easier understandable for the final user.
In facts right now the ManyToMany work very well with only `mappedBy` options so the `invertedBy` is clearly a duplicated information.

The problem for the implementation of this feature is that the ownerSide is decided by a single method for every mappings, so she's quite complexe. So the method decide only on using `mappedBy` and `invertedBy`. This behavior should be modifiable without too much troubles.

https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php#L1353

But another problem here is that should be discuss is that it's a big BC Break.





[DDC-2316] [GH-588] ClassMetadataInfo: use reflection for creating new instance (on PHP >=5.4) Created: 23/Feb/13  Updated: 06/Jul/14  Resolved: 06/Jul/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: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

On PHP >=5.4, use proper way for instantiating classes without invoking constructor.



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

Scheduling this for 3.0, when we move to php 5.4 or higher requirement

Comment by Doctrine Bot [ 29/Apr/14 ]

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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

Comment by Guilherme Blanco [ 06/Jul/14 ]

Closed as latest PHP weirdos forced us to apply partially this patch.





[DDC-2996] UnitOfWork::recomputeSingleEntityChangeSet() will not add a new change set Created: 23/Feb/14  Updated: 06/Jul/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

Issue Links:
Reference
relates to DDC-3208 Merge DDC-3160 back into 2.4.x Resolved
relates to DDC-3160 Regression in reComputeSingleEntityCh... Resolved

 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-3160] Regression in reComputeSingleEntityChangeset Created: 10/Jun/14  Updated: 06/Jul/14  Resolved: 06/Jul/14

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

Type: Bug Priority: Major
Reporter: flack Assignee: Marco Pivetta
Resolution: Fixed Votes: 3
Labels: None

Issue Links:
Reference
is referenced by DDC-2996 UnitOfWork::recomputeSingleEntityChan... Resolved
Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-3208 Merge DDC-3160 back into 2.4.x Sub-task Resolved Marco Pivetta  

 Description   

I just updated from 2.4.2 to 2.4.3 and watched most of my code break. I haven't found out all the details, but what happens is that entities passed to $em->persist() end up in UoW's entityUpdates array (even though they don't have an identity).

I've found out that the issue goes away when I uncomment this line:

https://github.com/doctrine/doctrine2/blob/v2.4.3/lib/Doctrine/ORM/UnitOfWork.php#L933

I'll try to debug this further when I have some time, and will add comments then



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

Do you have any listeners interacting with your changesets?

Comment by flack [ 10/Jun/14 ]

Yes, I listen to onFlush and then iterate over the insertion/update/deletion arrays

EDIT: Just found out that the entity is listed in both entityInsertions and in entityUpdates. So I guess that explains the missing identity.

Comment by flack [ 10/Jun/14 ]

I've debugged a bit further, and it seems like the following is happening:

    public function onFlush(OnFlushEventArgs $args)
    {
        $em = $args->getEntityManager();
        $uow = $em->getUnitOfWork();

        foreach ($uow->getScheduledEntityInsertions() as $entity)
        {
            $entity->changeSomeProperty(time());
            $cm = $em->getClassMetadata(get_class($entity));
            $em->getUnitOfWork()->recomputeSingleEntityChangeSet($cm, $entity); //<== This adds the entity to $entityUpdates
        }
        // Now, the entity from above will show up here, too, and without any identity, since it has not been flushed yet
        foreach ($uow->getScheduledEntityUpdates() as $entity)
        {
              //if I use entity's identity here, it'll be null
        } 
}

If I remove the recomputeSingleEntityChangeSet call here, the changes I made in the listener won't get persisted. But if I get the list of scheduled updates before iterating over the insertions, then any other changes made to different entities won't get persisted. Maybe UnitOfWork should simply check whether the $entity is already in entityInsertions before adding it to entityUpdates?

Comment by Eugeny Fomin [ 25/Jun/14 ]

We have the same problem.
After upgrade to 2.4.3 several extensions of DoctrineExtensions don't work.
Is that a bug in doctrine?

Comment by Christophe Coevoet [ 25/Jun/14 ]

I thnk we should find a way to fix the BC break we introduced in 2.4.3. This is quite bad.
Having the same entity in entityInsertions and entityUpdates looks weird anyway, as it is not an update

Comment by flack [ 25/Jun/14 ]

BTW: I made a unit test for this:

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

Comment by Justin Zimmerman [ 26/Jun/14 ]

I agree with Christophe Coevoet, it seems odd that an entity would be both scheduled for insertion AND update. But, I don't know too much of the Doctrine internals to say for sure.

I have added a pull request with what seems to work for this. As far as I can tell it passes Doctrine tests and also passes tests for the Tree features in the DoctrineExtensions project (which the DDC-2996 fix broke many portions of).

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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

Comment by Marco Pivetta [ 06/Jul/14 ]

Merged at https://github.com/doctrine/doctrine2/commit/a8035f25a218b5a522fa5fc76e0ce8bef4912f0d - PR at https://github.com/doctrine/doctrine2/pull/1074





[DDC-3164] [GH-1057] Add failing test for DDC-3160 Created: 12/Jun/14  Updated: 06/Jul/14

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

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


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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





[DDC-3197] [GH-1074] [DDC-3160] Alternate fix for DDC-2996 bug Created: 26/Jun/14  Updated: 06/Jul/14

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

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


 Description   

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

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

Message:

The fix implemented for DDC-2996 seems to have broken quite a bit of code outside of Doctrine (for instance, the popular DoctrineExtensions project).

I'm not too well versed in Doctrine internals, but looking at the fix, I found it odd that an entity would live in both the insertion and update tracking in the unit of work.

This implementation should fix the case described in DDC-2996, while not creating any side effects with objects that are scheduled to be inserted.

I've ran this test with the Doctrine test suite and have also tested this change with the DoctrineExtensions project; unless I'm doing something wrong, it seems to have good results.

Again, I'm not too well versed in the inner workings of Doctrine, but I did a little research, poked around some code, and came up with this.



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

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

Comment by Doctrine Bot [ 06/Jul/14 ]

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





[DDC-3204] MySQL and Character Set utf8mb4 Created: 04/Jul/14  Updated: 06/Jul/14  Resolved: 06/Jul/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: eatnut Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: character_set,, mysql,, utf8
Environment:

Debian Jessie, MySQL Community Server 5.7.4 m14



 Description   

1. My MySQL server has default character set `utf8mb4` and collation `utf8mb4_unicode_ci`.

2. Database created for ORM has the same character set and collation as the server.

3. When I use command `doctrine orm:schema-tool:create` to create a schema, a table with character set `utf8` and collation `utf8_unicode_ci` is created (should be utf8mb4 and utf8mb4_unicode_ci).

4. When I use mysql client to create table, no problem at all.

I'm not sure is it intended or not, doctrine will just ignore utf8mb4 character set?



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

Doctrine automatically adds utf8 and utf8_unicode_ci as charset and collation in the DDL used to create tables.

You will need to manually tweak this using additional table-specific mappings.





[DDC-3205] [DX] Interactive Management Command Created: 05/Jul/14  Updated: 06/Jul/14

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

Type: New Feature Priority: Minor
Reporter: Ryan Weaver Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hi guys!

This is part of the Symfony Developer Experience Initiative, which I hope can help Doctrine as well . This is a vision for a console tool to help visualize and manage your Doctrine entities. There are so many options and configuration that I think sometimes either (A) people don't even realize what options are available to them or (B) it's difficult to set everything up correctly (especially with relationships).

Imagine an interactive command that did things like:

  • listed your entities
  • listed fields in your entities (and their options, nullable, unique, etc)
  • Allowed you to change field options (e.g. change a field from nullable true to false
  • Allowed you to see your relationships and change options (cascade, JoinColumn stuff, etc)
  • Allowed you to setup relationships or setup the inverse side of a one-sided relationship
  • Added getters/setters
  • Generated helper methods into repositories (e.g. a method to create a query builder that joins a Product over to ProductImages after creating that relationship).

Does anyone see any issues with this? Obviously, this is HUGE, but it wouldn't need to start huge - it could start simply with some visualization and move from there. I think this could bring down the barrier to entry tremendously, and offer (via generation and visualization) some of the benefits of AR magic without that darn magic .

Thanks!



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

TL;DR: dumping details, yes please! modifying files/mappings, no-go.

A couple of things here:

  • listing entities is already available, see orm:info
  • listing all fields and additional details may be useful as an addition to orm:info via a flag. Implementation is also trivial
  • changing mappings via CLI - I'm really against this proposal. I've already tried getting rid of anything codegen-related from the symfony documentation, and I would not want codegen to land in the ORM. Mappings may come from annotations, from xml configs, from yaml or plain PHP files. They may also be processed by listeners and look completely different from the file counterparts. No, let's stay away from any ORM-driven mapping modification.
  • adding getters/setters, generating repositories, adding fields/associations: Doctrine's codegen is actually ONLY meant to provide an easy migration from a legacy DB to ORM entities+mappings, and we're also trying to get away from it in core.

Note that for mappings there's http://www.pulpo18.com/, which eases the path for newcomers. I also developed something for the ZF2 packages (which I must move to a separate library), see http://stackoverflow.com/a/14574952/347063





[DDC-3199] [GH-1076] Fix switch non-uniform syntax Created: 29/Jun/14  Updated: 02/Jul/14  Resolved: 02/Jul/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 velosipedist:

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

Message:






[DDC-3203] "Orphan Removal" for ManyToMany and "Cascade remove" doesn't trigger "preRemove" callback on related entity Created: 01/Jul/14  Updated: 02/Jul/14

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

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

Latest ZendFramework2, latest ZF2 DoctrineModule and latest ZF2 DoctrineORMModule



 Description   

I'm not sure if it's me, but I couldn't get "preRemove" callback/event working when "remove" action is triggered from related entity, but it works where the entity itself (the one with "preRemove" event) is removed directly.

According to documentation:
"If an association is marked as CASCADE=REMOVE Doctrine 2 will fetch this association. If its a Single association it will pass this entity to ´EntityManager#remove()`"....and similar for multiple entities.
DOC: http://doctrine-orm.readthedocs.org/en/latest/reference/working-with-objects.html?highlight=working-with-objects%20removing-entities#removing-entities

"preRemove event is called on every entity when its passed to the EntityManager#remove()"
DOC: http://docs.doctrine-project.org/en/latest/reference/events.html#preremove

So according to documentation "preRemove" should get triggered on "cascade remove", but it doesn't get in my case. Is this normal behavior or a bug?

I'm not sure if it the problem might be in any of ZF2 modules, but I've decided to post the issue here, since I'm referring to documentation of this project.

Beside that I've also noticed that "orphan removal" doesn't work on ManyToMany, although documentation says that it's supported (on IRC they've said that it may be a bug in documentation, that it is not really yet supported...they found no code changes when documentation was changed).
DOC:
http://docs.doctrine-project.org/en/latest/reference/working-with-associations.html#orphan-removal






[DDC-3202] Hydration fails with inhereted overload Created: 01/Jul/14  Updated: 01/Jul/14

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

Type: Bug Priority: Minor
Reporter: Evgen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: hydration
Environment:

mysql



 Description   

When i use single column with different types hydration not work. No error thrown, but in enity fields wrong data:

Class A

{ /** * @ORM\Column(name="str", type="string") */ protected $value; ... }

Class B extends A

{ /** * @ORM\Column(name="str", type="simple_array") */ protected $value; ... }

column in database created with type tinytext

after query:
SELECT b FROM A;

Entity of class B contain unparsed string in value property, not hydrated as simple_array. But to store B entities i need to parse this strng into array.
in hydrator i see 2 columns str3 and str4 that mapped to "value" propery and to "str" column in database.






[DDC-3201] Add "option" attribute in JoinTable annotation Created: 01/Jul/14  Updated: 01/Jul/14

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

Type: Improvement Priority: Minor
Reporter: Desjardins Jérôme Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Hello,

In my project, i try to use Doctrine 2 with all table in MyISAM because there is an existing project structure.

But when i create Many To Many association, i can't specify the MySQL's engine.

I think this option can be add in @JoinTable

I speak "annotation" (because I use annotations) but I suggest, of course, for all formats

Thanks






[DDC-3200] [GH-1077] Support filter parameters in Configuration Created: 01/Jul/14  Updated: 01/Jul/14

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

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


 Description   

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

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

Message:

Based on work done in doctrine/mongodb-odm#908

My understanding is that this makes it easier to setup filters at boot time, instead of having to fetch them from the collection later on.

For added context, the related PR from MongoDB ODM's Symfony bundle is doctrine/DoctrineMongoDBBundle#255






[DDC-1970] DiscriminatorMap recursion when using self-reference Created: 06/Aug/12  Updated: 01/Jul/14

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

Type: New Feature Priority: Major
Reporter: Krzysztof Kolasiak Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: None


 Description   

I've ran into a problem with self-referencing entity. When fetching an entity, recursion occurs, fetching every related entity defined by ManyToOne relation
(in this example $sponsor), ignoring LAZY or EXTRA_LAZY fetch mode - it executes numerous queries.

/**
 * @ORM\Entity(repositoryClass="Acme\Bundle\UserBundle\Entity\Repository\UserRepository")
 * @ORM\Table(name="f_user")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="type", type="string")
 * @ORM\DiscriminatorMap({"user_person" = "UserPerson", "user_company" = "UserCompany"})
 */
abstract class UserBase extends FOSUser

/* .... */

    /**
     * @var UserBase
     *
     * @ORM\OneToMany(targetEntity="UserBase", mappedBy="sponsor")
     */
    protected $referrals;

    /**
     * @ORM\ManyToOne(targetEntity="UserBase", inversedBy="referrals")
     * @ORM\JoinColumn(name="sponsor_id", referencedColumnName="id")
     */
    protected $sponsor;



 Comments   
Comment by Alexander [ 14/Aug/12 ]

I have changed this into a feature request because you have hit the limitations of using inheritance and self referencing entities.

Doctrine2 cannot currently lazy load UserBase#$sponsor because we don't know which proxy we have to insert. It can either be UserPerson or UserCompany. In order to know this Doctrine2 has to query the actual object to determine its type. The current strategy is then to load the actual entity because we have all data anyway.

In order to implement this feature we need to insert a proxy instead of the actual entity. If we do that there should be no recursion happening.

Comment by Marco Pivetta [ 21/Feb/13 ]

Reduced priority

Comment by Prathap [ 10/May/13 ]

It'd be great if this is a configurable option.

Comment by Kevin Bond [ 01/Jul/14 ]

I have also run into this.





[DDC-2180] [GH-527] Fix documentation for Doctrine\ORM\Query\AST\Node::dispatch() Created: 30/Nov/12  Updated: 30/Jun/14  Resolved: 30/Nov/12

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
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/527

Message:

Because Node::dispatch() is not documented as `@return string`, static code analysis returned the following error in our project:

> void method 'dispatch' result used

This fixes the documentation for this method.



 Comments   
Comment by Benjamin Eberlei [ 30/Nov/12 ]

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

Comment by Doctrine Bot [ 30/Jun/14 ]

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





[DDC-2364] [GH-625] [DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13  Updated: 30/Jun/14

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

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

Issue Links:
Duplicate
duplicates DDC-2363 Duplicated record with orphanRemoval ... Awaiting Feedback

 Description   

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

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

Message:

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



 Comments   
Comment by Doctrine Bot [ 30/Jun/14 ]

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





[DDC-2195] [GH-533] added DiscriminatorMapEntry mapping Created: 11/Dec/12  Updated: 30/Jun/14  Resolved: 16/Dec/12

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: Benjamin Eberlei 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 Padam87:

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

Message:

In Symfony2, if the main entity is in a separate bundle, from a vendor, changing the DiscriminatorMap is not a good idea.
Thats why we should be able to add entries to the map.

Mapping:

yaml:

discriminatorMapEntry: keyHere

annotation:

@DiscriminatorMapEntry("keyHere")

xml:

<discriminator-map-entry name="keyHere" />



 Comments   
Comment by Benjamin Eberlei [ 16/Dec/12 ]

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

Comment by Doctrine Bot [ 30/Jun/14 ]

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





[DDC-3198] [GH-1075] Fixed query cache id generation: added platform to hash Created: 27/Jun/14  Updated: 27/Jun/14  Resolved: 27/Jun/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 vilartoni:

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

Message:

There's an issue with the query cache id generation in `Doctrine\ORM\Query::_getQueryCacheId()`.

If you happen to use different connections to different platforms on the same project and you're using the query cache, you will get an exception the moment you try to execute a query which SQL is different depending on the platform and it has been previously cached for the other platform, as they will share the same cache id.

In order to reproduce the bug it is sufficient with using the Doctrine Paginator in a query:

```
$query = $queryBuilder->setFirstResult(0)
->setMaxResults(50)
->getQuery()
->getResult();
```

If we run the query for the first time with an empty cache in an Oracle connection and later on we try to run the same query in a MySQL connection, we get the following exception:

```
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'ROWNUM' in 'where clause'
```

As it's trying to execute the SQL for Oracle in the MySQL connection due to the same cache id.

This issue can be easily fixed just by taking the platform type into account in the cache id generation.



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

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

Comment by Marco Pivetta [ 27/Jun/14 ]

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





[DDC-3188] Call to a member function getValue() on a non-object in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php Created: 24/Jun/14  Updated: 27/Jun/14

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

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

PHP 5.4.11
opensuse
apache2



 Description   

This is the line that causes the fatal error: https://github.com/doctrine/doctrine2/blob/v2.4.2/lib/Doctrine/ORM/UnitOfWork.php#L678

This is the association that is breaking it (i.e. reflFields[ 'user' ] is a non-object):

Tweet.php
/**
 * @ManyToOne(targetEntity="User")
 * @JoinColumn(name="user_id", referencedColumnName="id")
 *
 * @var User
 */
protected $user;

This is the pk of the referenced entity.

User.php
/**
 * @Id
 * @Column(name="id", type="bigint", nullable=false)
 *
 * @var int
 */
protected $id;

If an exception was thrown due to missing metadata information, I could catch it, but fatal errors due to this bug have been crashing our scripts and they've had to be manually restarted.

Let me know what other information is needed.

Full stack trace:

PHP 5. Doctrine\ORM\EntityManager->flush() our_code.php
PHP 6. Doctrine\ORM\UnitOfWork->commit() vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:389
PHP 7. Doctrine\ORM\UnitOfWork->computeChangeSets() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:297
PHP 8. Doctrine\ORM\UnitOfWork->computeScheduleInsertsChangeSets() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:703
PHP 9. Doctrine\ORM\UnitOfWork->computeChangeSet() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:404
PHP Fatal error: Call to a member function getValue() on a non-object in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 678



 Comments   
Comment by Marco Pivetta [ 24/Jun/14 ]

Did you actually validate your mappings?

Comment by Daniel Imhoff [ 24/Jun/14 ]

I did not validate the mapping. I did not know about the orm:validate-schema until just now. I will fix these errors and resubmit if there is still an issue.

Sorry about that, thanks.

Comment by Daniel Imhoff [ 24/Jun/14 ]

The tweet and user relationship is not in the list of invalid mappings.

Comment by Marco Pivetta [ 26/Jun/14 ]

Are User and Tweet in the same namespace?

Comment by Daniel Imhoff [ 27/Jun/14 ]

Yes, and I've since then used the FQNS. I would get a class not found error when validating schema.
This is something that I know can't really be debugged by you guys, I was just hoping for a little direction. We are using memcache to store our metadata, and we are clearing and regenerating the metadata during every deploy (it is not autogenerated). I'm now using a commit hash as the namespace of the metadata, so we'll see if this fixes the issue.

Comment by Marco Pivetta [ 27/Jun/14 ]

It looks like a typo (CasESensiTIViTy issue) to me.





[DDC-2271] [GH-564] Fix a wrong return type Created: 03/Feb/13  Updated: 27/Jun/14  Resolved: 05/Feb/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
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/564

Message:

`BasicEntityPersister::executeInserts()` is documented as:

@return array An array of any generated post-insert IDs. This will be an empty array
if the entity class does not use the IDENTITY generation strategy.

This PR fixes an empty `return;` that contradicted the documented return type.



 Comments   
Comment by Benjamin Eberlei [ 03/Feb/13 ]

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

Comment by Fabio B. Silva [ 05/Feb/13 ]

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

Comment by Doctrine Bot [ 27/Jun/14 ]

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





[DDC-2350] [GH-614] ObjectHydrator: fix entity namespaces. Created: 14/Mar/13  Updated: 27/Jun/14  Resolved: 04/May/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

  1. Object Hydrator: fix entity namespaces

If you are using Entity Namespace aliases, the ObjectHydrator will throw a notice for an undefined index of your entity namespace.

    1. Problem
      The problem lies in the fact that the prepare() method uses the "className", used in the aliasMap (where you use the namespace alias) to store the local ClassMetadata cache. Though, in a later stage the actual namespace is being used to find this same item.
    1. Fix
      I've changed the way this ClassMetadata cache is built. It now uses the full Entity namespace.


 Comments   
Comment by Doctrine Bot [ 04/May/13 ]

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

Comment by Doctrine Bot [ 27/Jun/14 ]

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





[DDC-213] Persist order of collections Created: 15/Dec/09  Updated: 27/Jun/14

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

Type: New Feature Priority: Major
Reporter: Roman S. Borschel Assignee: Roman S. Borschel
Resolution: Unresolved Votes: 15
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-181 Order of many-to-many relationship Resolved
Reference
is referenced by DDC-250 ArrayCollection Key Column @indexBy Resolved

 Description   

A Collection is like a php array, an ordered map. Hence there should be the possibility to persist this order.



 Comments   
Comment by Christian Heinrich [ 21/May/10 ]

Roman, I'd like to do this one as I have currently a use case for this. Do you have any idea of how to do this? What I'm wondering is whether it is possible to implement this without user intervention. (This would simply mean "store the entities as they were added"). But this would need another column in DB that we'd have to add within oneToMany / manyToMany relationships, but in this case one could save a serialized array holding "entityId => position" key / value pairs.

Afterwards, one could easily rebuild / reorder the collection via $collection->set($entity, $order[$entity->identifier]);

If you've got another thought about this, please don't hesitate to point me into the right direction!

Comment by Benjamin Eberlei [ 22/May/10 ]

this won't be implemented until 2.1, since its a pretty complex feature.

Changes are probably required in:

1. CollectionPersister - Add a new collection persister that takes the position into account
2. SchemaTool - Add a 'col_position' column to either the many-to-many or the one-to-many tables.
3. EntityPersister - Use and extend current order-by support to make the sorting happen

You can implement this already though with some performance hit in update scenarios. If you use the ORDER BY support and implement an API around your entity that abstracts those changes and always sets a "position" field on the many entity that is supposed to be sorted.

Comment by Roman S. Borschel [ 22/May/10 ]

I don't think we necessarily need a new collection persister. Simply adjusting the ManyToManyPersister to be able to deal with it might be sufficient.

For OneToMany, that is always persisted from the "many" side, thus there is no collection persister, we would need to adjust the normal persisters.

They key element for the user should be a new annotation (or corresponding xml/yaml element) @OrderColumn. By default the order should not be persistent, only when an @OrderColumn annotation is present. The name of the order column can have a default, i.e. "position". Thus this enhancement of persisting the order should be fully backwards compatible.

Comment by Roman S. Borschel [ 22/May/10 ]

On another note, the getInsertDiff/getDeleteDiff methods of PersistentCollection should already be "ready" for this. That is, when an element in the collection changed only its position, this is already tracked as a change. However the ManyToManyPersister issues no "UPDATE" queries, it simply deletes and inserts. A position change may be more effectively persisted with an UPDATE.

Comment by Benjamin Eberlei [ 30/Sep/10 ]

From a mailinglist entry, required check/changepoints:

1. ClassMetadata of Many-To-Many associations have to be extended to publish the required datastructure to the ORM.
2. All Metadata Mapping Drivers have to be extended
3. Persisters\ManyToManyCollectionPersister has to be extended to save the key in the many to many table if desired by the user.
4. Schema-Tool has to be extended to create the additional column.
5. PersistentCollection has to be extended so that lazy loading of collections with additional key works.
6. Array- and ObjectHydrator have to be extended to allow fetch join of collections with key column.
7. Discuss wheather to support this for One-To-Many also with the key-column on the many side. This is much more tricky internally though.

Comment by Benjamin Eberlei [ 24/Dec/10 ]

Push back to 2.x, we will have support for DDC-250 first and for this at a later release.

Comment by Thomas Tourlourat - Armetiz [ 07/Feb/12 ]

Hi there,
I'm looking for this feature.

Benjamin Eberlei said that : "You can implement this already", but I don't understand the "how to".

Also,
The problem should be solve if RDBMS had a "natural" order. An order based on item position inside table.

To get this feature without any change on Doctrine, I have remplace the PK defined by the target & mapped field identifier. The new PK is a new field with type "integer" and with auto-increment enable.
In this configuration, Doctrine use the "natural" order of the RDBMS. And I can change order of my item inside Collection and persist it.

It's an very bad solution, but It work before an official support.

Waiting for advices, and solutions,

Thomas.

Comment by Thomas Tourlourat - Armetiz [ 08/Feb/12 ]

Answering to Benjamin Eberlei on the "7. Discuss wheather to support this for One-To-Many also with the key-column on the many side. This is much more tricky internally though.".

I think that for One-To-Many relations, if user want to store the collection order, Doctrine can store the One-To-Many as Many-To-Many with a "model" limitation.
In that case, if storing order collection for Many-To-Many work, it should work for One-To-Many.

What do you think about it ?

Comment by Nicolas [ 29/Feb/12 ]

I think that it must be possible to have two keys ordering : the order isn't obligatory reversible.

For exemple with user and group :

  • You can order groups for one user : with preference by exemple, or importance.
  • And with a different order, users for a group : rank by example.

And maybe more, if you decide to add multi-order : an user show group by his rank in it, if his rank is identical, the order is make by love preference, and after by the importance given by the user (not necessary a number, if we imagine filter on them).

So a default order can be choice with parametized fields and could be :

 
@ManyToMany(targetEntity="Group")
...
@JoinFields ( rank: { type: int} , preference:{type:int}, importance:{type: string, length: 40} )
@OrderByJoinFields({"rank" = "ASC", "preference"="ASC", "importance"="ASC" } )

In this case the order must be optional and would be clean if another order appears in the same scope (DQL...). And manytomany became virtual entities act as other entities except they don't appears permetting in the same time a better conception.

So if the solution take in DDC-181 will become the only solution. This would a good idea to document this. Because, this seems to me a very important point.

My last point is even an unique ordering field created in the join table will be a big and usefull improvement.

Thank a lot for your beautiful work.

Comment by Thomas Tourlourat - Armetiz [ 29/Feb/12 ]

In my point of view, a collection can be order in a single way only.
If you want to add more than one order between User & Group, it's a new collection, a new relation.
Like :

  • User.memberOf() : Group[]
  • Group.members() : User[]
  • Group.importantMembers() : User[]

And it's your role to keep a consistency between members & importantMembers array.

Because ManyToMany join table is the reflection of a state of an ArrayCollection. It's not a usefull feature to be able to store all of the state of an ArrayCollection, even the order of this Array. It's just a normal feature that is really missing

Thomas.

Comment by Nicolas [ 29/Feb/12 ]

I don't think:

If you have three collection, you duplicate one relation 3 times and it's easy in consequence to lost the data integrity and unicity.

By example :

  • Thomas have rank 10 in Admin
  • Thomas think the admin group has importance noted 3 on all of his groups.
  • If a responsable of admin group decide to delete Thomas from it.
  • Thomas, in his ordered list of groups, think always to be in group admin.

So in my idea, the many to many relation isn't just an array collection, but should be an virtual entity. In UML or in Merise method this is a common problem to have a parametized relation. I think an orm should just implement this.

Comment by Thomas Tourlourat - Armetiz [ 29/Feb/12 ]

Hum,
I agree with you.. In a SQL Schema, it's a good choice to add many fields in a ManyToMany join table to description "order".

Comment by Thomas Tourlourat - Armetiz [ 07/Mar/12 ]

I just want to add a piece of Doctrine ORM Document :

"When working with collections, keep in mind that a Collection is essentially an ordered map (just like a PHP array). That is why the remove operation accepts an index/key. removeElement is a separate method that has O ( n) complexity using array_search, where n is the size of the map."

Comment by Thomas Tourlourat - Armetiz [ 23/Mar/12 ]

Hi there,
After several discussions. on IRC, I have changed my point of view.

Doctrine Documentation says : "When working with collections, keep in mind that a Collection is essentially an ordered map (just like a PHP array)".
So, I think that Doctrine have to be able to store or not the order of a Collection. By adding a new field on the Joined table to store the position of each elements.

But I not agree with @Nicolas. Because in his case, he's talking about Association Class : http://etutorials.org/Programming/UML/Chapter+6.+Class+Diagrams+Advanced+Concepts/Association+Class/
Because he's talking of a business logic, he's talking of a dedicated Entity class.

What do you think about it ?

Thomas;

Comment by Thomas Tourlourat - Armetiz [ 31/Aug/12 ]

Any news ?

Comment by Matthieu Napoli [ 16/Oct/12 ]

Hi, any news on this?

If I may add any info to this feature request, maybe something like JPA/Hibernate could be a good start?

See http://docs.oracle.com/javaee/6/api/javax/persistence/OrderColumn.html or http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html/collections.html#collections-indexed

The idea in Hibernate is that you persist the order of the list in an extra column. This column is not a field of the entity however.

Comment by Albert Casademont [ 27/Jun/14 ]

+1, this would be indeed a very nice thing. We are using the @OrderBy annotation as a workaround but it's not quite the same thing

Comment by Marco Pivetta [ 27/Jun/14 ]

Moved to 3.x





[DDC-3193] Paginator hydrating the iterator with only half the limit Created: 26/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/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: Alan Hartless Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

PHP 5.4.24 (cli) (built: Jan 19 2014 21:32:15)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans



 Description   

When using paginator on a left join for a one to many association, Doctrine is only hydrating half the requested results via the limit set by setMaxResults(). It is giving the correct total as indicated by count() but getIterator() is only returning half the requested results.

For example, I have 82 results, with a setMaxResults(50), getIterator() only has 25 hydrated!

My entities are:

Submission
/**

  • @ORM\OneToMany(targetEntity="Result", mappedBy="submission", cascade= {"persist", "remove", "refresh", "detach"}

    )
    */
    private $results;

Result

/**

  • @ORM\ManyToOne(targetEntity="Submission", inversedBy="results")
  • @ORM\JoinColumn(name="submission_id", referencedColumnName="id", nullable=false, onDelete="CASCADE")
    **/
    private $submission;

And I'm using the following query builder in the submission repository:
$q = $this->createQueryBuilder('s')
->select('s, r')
->leftJoin('s.results', 'r')
->setFirstResult(0)
->setMaxResults(0);

It seems to be counting each submissions result as one rather than each submission. So it is returning 50, although its 50 results within 25 submissions. I need to find a way to get it to return 50 submissions instead. Maybe I'm doing something wrong?



 Comments   
Comment by Christophe Coevoet [ 26/Jun/14 ]

Can you post your code configuring the paginator too ?

Comment by Alan Hartless [ 26/Jun/14 ]

Looks like this was my bad. After getting frustrated with trying to get it to work, I had tried all kinds of things including $results = new Paginator($query, false); while I was debugging to see if $fetchJoinCollection made a difference. I had rearranged my query multiple times but forgot to remove the false so of course it continued to fail. Now that I've removed it (so it defaults to true), the query works correctly.

Thanks,
Alan





[DDC-2201] [GH-537] fixed problems with joined inheritance and composite keys Created: 16/Dec/12  Updated: 26/Jun/14  Resolved: 04/May/13

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

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


 Description   

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

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

Message:

SchemaTool now creates all Id columns not just only the first one.
Insert statement for child entity now contains parameter for additional key columns only once.



 Comments   
Comment by Doctrine Bot [ 04/May/13 ]

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

Comment by Doctrine Bot [ 26/Jun/14 ]

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





[DDC-2256] [GH-554] Fixed ObjectHydrator when namespace alias is given. Created: 24/Jan/13  Updated: 26/Jun/14  Resolved: 05/Feb/13

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

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


 Description   

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

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

Message:

Fixes problem when executing native query:
```php
$rsm = new ResultSetMapping();

$rsm->addEntityResult('DbBundle:Player', 'p');
$rsm->addFieldResult('p', 'id', 'id');
$rsm->addFieldResult('p', 'name', 'name');

$rsm->addJoinedEntityResult('DbBundle:User', 'u', 'p', 'user');
$rsm->addFieldResult('u', 'user_id', 'id');

$em->createNativeQuery('...', $rsm);
```

Hydrator couldn't find cached metadata, when "joined entity result" class name wasn't fully qualified name (as in the example above).



 Comments   
Comment by Benjamin Eberlei [ 02/Feb/13 ]

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

Comment by Fabio B. Silva [ 05/Feb/13 ]

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

Comment by Doctrine Bot [ 26/Jun/14 ]

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





[DDC-2326] [GH-595] Fixed broken code block in documentation Created: 01/Mar/13  Updated: 26/Jun/14  Resolved: 12/Mar/13

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

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

Message:



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

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

Comment by Doctrine Bot [ 26/Jun/14 ]

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





[DDC-2328] [GH-597] use the extended proxy interface in the same namespace Created: 01/Mar/13  Updated: 26/Jun/14  Resolved: 03/Mar/13

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

Type: Bug Priority: Blocker
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Fix for this error:

FatalErrorException: Compile Error: Cannot use Doctrine\Common\Proxy\Proxy as Proxy because the name is already in use in .../vendor/doctrine/orm/lib/Doctrine/ORM/Proxy/ProxyFactory.php line 26



 Comments   
Comment by Marco Pivetta [ 03/Mar/13 ]

Marking as blocker - has to go in before 2.4

Comment by Benjamin Eberlei [ 03/Mar/13 ]

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

Comment by Marco Pivetta [ 03/Mar/13 ]

merged

Comment by Doctrine Bot [ 26/Jun/14 ]

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





[DDC-2330] [GH-599] Removed unnecessary "<?php" from the docs Created: 03/Mar/13  Updated: 26/Jun/14  Resolved: 04/Mar/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 04/Mar/13 ]

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

Comment by Doctrine Bot [ 26/Jun/14 ]

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





[DDC-3196] Enabling LIMIT resp. setMaxResults on subquery Created: 19/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Improvement Priority: Major
Reporter: Webdevilopers Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 1
Labels: dql, limit, setMaxResults, subquery
Environment:

PHP, Zend Framework2, DoctrineModule, DoctrineORMModule



 Description   

The following subquery using LIMIT 1 is legal SQL:

(SELECT state FROM contract_states 
WHERE contract_states.contract_id = contracts.id
ORDER BY date DESC, created_at DESC, id DESC LIMIT 1) = ?

I tried to get the same result in DQL using the queryBuilder:

	$qb2 = $this->_em->createQueryBuilder();
    	$qb2->select(array('s2.state'))
    		->from('Application\Entity\ContractState', 's2')
    		->where('s2.contract = c.id')
    		->orderBy('s2.date', 'DESC')
    		->addOrderBy('s2.createdAt', 'DESC')
    		->addOrderBy('s2.id', 'DESC')
    		->setMaxResults(1);
$stateDql = $qb2->getDQL();

or directely via DQL:

    	$stateDql = 'SELECT s2.state FROM Application\Entity\ContractState s2 WHERE s2.contract = c.id
    			ORDER BY s2.date DESC, s2.createdAt DESC, s2.id DESC LIMIT 1';

The DQL was inserted in my query:

	    $qb->select(
	    	array(
	    		'DISTINCT(c.id) AS contract_id',
	    		$qb->expr()->max('s.createdAt') . ' AS state_updated',
	    		's.createdAt',
	    		's.state'
			))
	    	->from('Application\Entity\Contract', 'c')
	    	->join('c.states', 's')
->andWhere('s.state = (' . $stateDql . ')');

The first DQL string did not include a LIMIT part. The second one ended with the following error:
Error: Expected Doctrine\ORM\Query\Lexer::T_CLOSE_PARENTHESIS, got 'LIMIT'

Is there a way to achieve it?

I also tried a workaround by using MAX inside my orderBy which could help:

->addOrderBy($qb->expr()->max('s2.createdAt'), 'DESC')

But this throws an error too:
Error: Expected Doctrine\ORM\Query\Lexer::T_CLOSE_PARENTHESIS, got '('

I hope this is the right place to post the issue. I havn't found a similar topic browsing 'subquery' or 'LIMIT' as keyword.



 Comments   
Comment by Christophe Coevoet [ 19/May/14 ]

There is not LIMIT in DQL. the mx result is not part of the DQL string.

However, is limiting a subquery valid in SQL generally or only on some platforms ?

I know that MySQL supports them only in some subqueries but not all places where subqueries can be used: http://dev.mysql.com/doc/refman/5.6/en/subquery-restrictions.html

Comment by Webdevilopers [ 19/May/14 ]

Thanks for the quick reply.

I think it is not valid on correlated subquery and using them inside the select statement.

The subquery mentioned above is used inside the where statement and will return a legal result in the current MySQL version.

Maybe there is another workaround? As I described setting a max expression in the order clause did not work out either.

Comment by Christophe Coevoet [ 19/May/14 ]

OK, but what about other platforms ? If only MySQL support this, we cannot integrate the feature in DQL

Comment by Webdevilopers [ 20/May/14 ]

I can't speak for other platforms but I will do some research.
Maybe some experts will comment too.
Thanks so far.

Comment by Webdevilopers [ 21/May/14 ]

While I am doing some research can somebody tell if it s possible to male DQL accept the LIMIT by creating a custom extension for the Lexer? E.g.:
https://github.com/beberlei/DoctrineExtensions/blob/master/lib/DoctrineExtensions/Query/Mysql/GroupConcat.php

Comment by Marco Pivetta [ 26/Jun/14 ]

The parser is not really designed for extensions.

Additionally, as Christophe Coevoet said, it's not really possible to support LIMIT in all platforms.





[DDC-3195] indexBy implementation on containsKey of PersistentCollection in EXTRA LAZY mode uses property name as column name instead of column name Created: 26/May/14  Updated: 26/Jun/14

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

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

Any



 Description   

indexBy implementation on containsKey (and possibly other EXTRA LAZY implemented methods) of PersistentCollection in EXTRA LAZY mode uses property name as column name instead of column name for OneToMany collections

For example property = fieldName, column name field_name.
Set indexBy on OneToMany annotation to fieldName (as it should be ) and it tries to use fieldName in backend instead of field_name






[DDC-3189] blob doctrine2 not inserting file in mysql Created: 24/Jun/14  Updated: 26/Jun/14

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

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

Linux Ubuntu 12.04, Mysql 5


Attachments: PNG File a.png     Zip Archive testedoctrineupload.zip    

 Description   

I have an entity mapped as:

/**
 * @Entity @Table(name="Upload")
**/
class Upload
{
/** @Id @Column(type="integer") @GeneratedValue **/
protected $id;

/** @Column(type="string") **/
protected $nome;

/** @Column(type="blob") **/
protected $arquivo;

When I use this (WORKS)

 $query = "INSERT INTO Upload1 (name, size, type, content ) "."VALUES ('$fileName', '$fileSize', '$fileType', '$content')";

 mysql_query($query)

When I use this doctrine way (NOT WORKING, if you try to get this file from mysql, return a corrupted or empty file)

$upload = new Upload();

$upload-> setContent($content);
$upload-> setName($fileName);
$upload-> setSize($fileSize);
$upload-> setType($fileType);

$entityManager->persist($upload);
$entityManager->flush();

My html file:

<form method="post" enctype="multipart/form-data">
<table width="350" border="0" cellpadding="1" cellspacing="1" class="box">
<tr> 
<td width="246"> 
<input type="hidden" name="MAX_FILE_SIZE" value="2000000">
<input name="userfile" type="file" id="userfile"> 
</td>
<td width="80"><input name="upload" type="submit" class="box" id="upload" value=" Upload    "></td>
</tr>
</table>
</form>


 Comments   
Comment by Gustavo Monti Rocha [ 24/Jun/14 ]

trying to insert this image

Comment by Gustavo Monti Rocha [ 24/Jun/14 ]

Using:
$entityManager->getConnection()>getConfiguration()>setSQLLogger( new Doctrine\DBAL\Logging\EchoSQLLogger());

Getting:
"START TRANSACTION" INSERT INTO Upload (name, type, size, content) VALUES (?, ?, ?, ?) array(4) { [1] => string(5) "a.png" [2] => string(9) "image/png" [3] => int(264547) [4] => string(270342) "‰PNG  \0\0\0 IHDR\0\0@\0\0„\0\0\0v/jõ\0\0\0sBITÛáOà\0\0\0tEXtSoftware\0gnome-screenshotï¿>\0\0 \0IDATxœìw|TÅöÀÏܲ{·$›^I¥“Лҫ€ QPô©`

{êÏγ÷^ŸýYÀ‚ˆ\"¢ô %½m’í햙ߛ,›mÙe¾>š½÷Ι™3gæÎœ;]3ÿR P( …B¡P( …\0\0³X¾Ÿ†X]ŸÞ]ÿÂôP(\0àÜnñ¯N…B¡P( …B¡P(„B\0\0\\.÷ñ’ÊüünݺÇøîÚl¶m;æçfh4\0@BUR)”3®©šR( …B¡P( …ræa2Y+«ëV\0@4……}

Y–<¸§×KEÙ±ãHaaßâ¢#n·\0Ãf¦§ÄÇÇþÅé¦PÎ0¨‹B¡P( …B¡P(g(„ÙttTJ5\"\0< g§æefe¥ú?3rd¿Š £V.W7ì&\0˜âF+‰ø%9uÆF\0HINø«pôx…ZÅuÉL¥“Ô(‘Ù³¯\0ú÷í}ã¶9°A‡Óãr¥Åé¯n"... } array(4)

{ [1] => string(6) "string" [2] => string(6) "string" [3] => string(7) "integer" [4] => string(4) "blob" }

"COMMIT"

Comment by Steve Müller [ 26/Jun/14 ]

This looks more like a DBAL issue. Can you please provide the error/exception message that you receive from the driver/database server? Also do you use PDOMySQL or mysqli driver?

Comment by Gustavo Monti Rocha [ 26/Jun/14 ]

Steve,

I'm not getting any error/expection. Table looks like insert the blob file but when I try to download it is corrupted. You could see at getting .zip file and executing it.

I'm using PDOMysql.

Comment by Marco Pivetta [ 26/Jun/14 ]

This would probably need a data sample to reproduce the issue.

Comment by Gustavo Monti Rocha [ 26/Jun/14 ]

Marco,

you could use project attached and image in order to reproduce.

Comment by Marco Pivetta [ 26/Jun/14 ]

Gustavo Monti Rocha you should actually provide a functional test for this in case, see https://github.com/doctrine/dbal/tree/master/tests/Doctrine/Tests/DBAL

For example, the zip file you uploaded fails on various includes, and doesn't show the failures to me.





[DDC-274] Class and namespace naming inconsistency Created: 24/Jan/10  Updated: 26/Jun/14

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

Type: Improvement Priority: Major
Reporter: Glen Ainscow Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 1
Labels: None


 Description   

There are inconsistencies with some class and namespace names that include acronyms.

Examples:

Classes with upper-casing:
ORMException, DBALException, OCI8Connection, etc.

Classes with proper-casing:
RunDqlTask, CliException, MySqlPlatform, etc.

Namespaces with upper-casing:
DBAL, ORM, Doctrine\DBAL\Driver\PDOMsSql, etc.

Namespaces with proper-casing:
Doctrine\Common\Cli, Doctrine\DBAL\Tools\Cli\, Doctrine\ORM\Id, etc.

There is more proper-casing than upper-casing. IMHO, proper-casing is better as it's easier to read "SqlException" than it is to read "SQLException" (the "E" looks like part of the acronym), and things like "CLITask" can be avoided.

I discussed this a bit with Benjamin and Guilherme, and they were unsure and said that the whole team needed to reach consensus.

I'm leaving the priority as "Major" because this should probably be fixed sooner rather than later to prevent compatibility breaks.



 Comments   
Comment by Guilherme Blanco [ 25/Jan/10 ]

Increasing the severity and adding a fix version since this MUST be fixed before next release.

Comment by Roman S. Borschel [ 25/Jan/10 ]

I find this to be of rather minor importance. You're talking of compatibility breaks, but thats only the case if we intend to start being very nitpicky about the naming in the future. We are currently not, and we wont be, so not much risk of later breakage.

We have a rule of thumb already: Acronyms up to 4 characters all uppercase, otherwise normal camelcase.

Now, it is often a matter of taste what is an acronym and what not and also not all acronyms have a clear casing, prime example mysql.

Being too nit-picky here is just a pain in the ass and we won't reach a common consensus anyway.

Comment by Roman S. Borschel [ 25/Jan/10 ]

Oh and we better dont start arguing about whats better to read because there is no chance of agreement. If you ask me I find SQLException better than SqlException. So here we go. Lets better not run down this path.

Comment by Glen Ainscow [ 25/Jan/10 ]

No need to get upset, I'm only trying to help.

I just thought that consistency is usually a good idea, either way.

I have to disagree in that an acronym is an acronym, it's not a matter of taste, the letters either stand for something, or they don't.

As for "mysql", only the SQL part is an acronym. So, MySQL or MySql.

Close if you disagree.

Comment by Roman S. Borschel [ 25/Jan/10 ]

I'm not upset. What made you think so? Maybe I should introduce a every now and then.

There's just no point in arguing about readability.

Like I said, we do have a naming standard even if its not adhered everywhere. The standard is also not something we've made up ourselves because we try to avoid that. When we introduced namespaces, we talked about adopting either the Java or .NET naming standards. We opted for the .NET standards. And there its recommended to write acronyms with up to 4 characters all uppercase.

I dont think there are too many violations of that in the code, probably Cli => CLI and some others but most of it looks ok to me.

UPDATE: Maybe we can gather a list here in this ticket of violations? Cli => CLI would be one. MySql => MySQL another. "Id" is rather an abbreviation of Identifier and not an acronym, to me at least.

Comment by Guilherme Blanco [ 25/Jan/10 ]

It's not a case of getting anyone upset...

But we should fix it and keep consistency of our codebase.

@romanb We should all talk and reach a common sense.
That's our last chance (last alpha) to get this consistency in.

Comment by Roman S. Borschel [ 25/Jan/10 ]

@Guilherme: We do have a naming standard since a year. You want to change the standard now?

Comment by Glen Ainscow [ 25/Jan/10 ]

@Roman,

Just a feeling I got.

This issue was more about consistency (indicated in the title) than moving to proper-case naming.

I think it might be up to 3 characters in .NET, HtmlElement, System.Linq, etc. Anyway, not important.

I agree that Id. is an abbreviation.

There are some more violations. If you decide you want to change them, let me know and I'll compile a list.

Comment by Roman S. Borschel [ 25/Jan/10 ]

@Glen: Yes, a list would be great. I find it hard to be 100% consistent sometimes though because my taste conflicts with the rule. For example, I would prefer "Id" over "ID", especially since it comes directly after ORM "Doctrine\ORM\ID\..." would be a bit too much. But I would not like "Orm" or "Dbal" either. But I think in most cases we can clearly fix the inconsistency. Like CLI or MySQL or MSSQL (or should it be MsSQL?).

Thanks for your help!

We should probably create updated coding standards for Doctrine 2 also, since they differ quite some from Doctrine 1 due to the introduction of namespaces and such. I'll create a ticket for that.

Comment by Glen Ainscow [ 25/Jan/10 ]

I'll do the list for you by tomorrow at the latest, just running out of time ATM.

Id is correct, as mentioned above, so that would be fine. MsSQL is correct (Ms = Microsoft = abbreviation).

Comment by Glen Ainscow [ 25/Jan/10 ]

Found some time ...

Doctrine\Common\Cache\ApcCache -> APCCache
Doctrine\Common\Cli -> CLI
Doctrine\Common\Cli\Printers\AnsiColorPrinter -> ANSIColorPrinter
Doctrine\Common\Cli\CliController -> CLIController
Doctrine\Common\Cli\CliException -> CLIException

Doctrine\DBAL\Driver\PDOMsSql -> PDOMsSQL
Doctrine\DBAL\Driver\PDOMySql -> PDOMySQL
Doctrine\DBAL\Driver\PDOPgSql -> PDOPgSQL
Doctrine\DBAL\Driver\PDOSqlite -> PDOSQLite
Doctrine\DBAL\Logging\EchoSqlLogger -> EchoSQLLogger
Doctrine\DBAL\Logging\SqlLogger -> SQLLogger
Doctrine\DBAL\Platforms\MsSqlPlatform -> MsSQLPlatform
Doctrine\DBAL\Platforms\MySqlPlatform -> MySQLPlatform
Doctrine\DBAL\Platforms\PostgreSqlPlatform -> PostgreSQLPlatform
Doctrine\DBAL\Platforms\SqlitePlatform -> SQLitePlatform
Doctrine\DBAL\Schema\Visitor\CreateSchemaSqlCollector -> CreateSchemaSQLCollector
Doctrine\DBAL\Schema\Visitor\DropSchemaSqlCollector -> DropSchemaSQLCollector
Doctrine\DBAL\Schema\MsSqlSchemaManager -> MsSQLSchemaManager
Doctrine\DBAL\Schema\MySqlSchemaManager -> MySQLSchemaManager
Doctrine\DBAL\Schema\PostgreSqlSchemaManager -> PostgreSQLSchemaManager
Doctrine\DBAL\Schema\SqliteSchemaManager -> SQLiteSchemaManager
Doctrine\DBAL\Tools\Cli -> CLI
Doctrine\DBAL\Tools\Cli\Tasks\RunSqlTask -> RunSQLTask

Doctrine\ORM\Mapping\Driver\PhpDriver -> PHPDriver
Doctrine\ORM\Mapping\Driver\XmlDriver -> XMLDriver
Doctrine\ORM\Mapping\Driver\YamlDriver -> YAMLDriver
Doctrine\ORM\Query\Exec\AbstractSqlExecutor -> AbstractSQLExecutor
(Should Doctrine\ORM\Query\Expr\Andx and Orx be AndX and OrX?)
Doctrine\ORM\Query\SqlWalker -> SQLWalker
Doctrine\ORM\Tools\Cli -> CLI
Doctrine\ORM\Tools\Cli\Tasks\RunDqlTask -> RunDQLTask
Doctrine\ORM\Tools\Export\Driver\PhpExporter -> PHPExporter
Doctrine\ORM\Tools\Export\Driver\XmlExporter -> XMLExporter
Doctrine\ORM\Tools\Export\Driver\YamlExporter -> YAMLExporter

... I think that's it. More than you expected? I did say: "There is more proper-casing than upper-casing."

Comment by Roman S. Borschel [ 25/Jan/10 ]

No, not more than I expected. It's mostly SQL and CLI basically. Thanks for the list!

We should try to go through that list before beta.

Comment by Roman S. Borschel [ 05/Mar/10 ]

Methods should be adjusted accordingly also (even though they're case insensitive). I already started with that. More to come.

Comment by Roman S. Borschel [ 28/Mar/10 ]

Most of the Cli => CLI changes seem to be complete now.

Comment by Roman S. Borschel [ 26/Apr/10 ]

Pushing the rest of the name changes towards beta2.

Comment by Roman S. Borschel [ 19/May/10 ]

More renamings have been done but still more to do. Pushing remaining work to beta3.

Comment by Roman S. Borschel [ 30/Aug/10 ]

Final name changes should be done prior to going into RC1.

Comment by Benjamin Eberlei [ 31/Oct/10 ]

there is much to be done yet, however most of it is also public API class names and might cause quite some BC breaks (i.e. DBAL Platforms and Schema Manager, Mapping Driver Names). I am not sure how to proceed here.

Comment by Roman S. Borschel [ 31/Oct/10 ]

Since PHP is mostly case-insensitive on class and method names it shouldn't be much of an issue.

Comment by Guilherme Blanco [ 16/Apr/14 ]

Scheduled to 3.0 as this may potentially create BC breaks





[DDC-2800] Something wrong with documentation generation Created: 18/Nov/13  Updated: 26/Jun/14

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

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


 Description   

The ArrayCollection has a matching() function, but it does not show in the API docs. http://www.doctrine-project.org/api/common/2.4/class-Doctrine.Common.Collections.ArrayCollection.html



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

Flip The collection API has moved to its own repo anyways now and there currently is no API generation for this, aswell as other subprojects like annotations etc. But the matching() method exists in 2.3 branch, where the repos were not separated, yet.

http://www.doctrine-project.org/api/common/2.3/source-class-Doctrine.Common.Collections.ArrayCollection.html#463-498

Do we need to keep this ticket open?

Comment by Flip [ 02/Apr/14 ]

I think so because no new documentation is generated for subprojects.

Expected: http://www.doctrine-project.org/api/collections/2.4/ (or any other latest version if the subprojects have seperate versioning)





[DDC-2153] [GH-517] Fix for DDC-1765 Created: 17/Nov/12  Updated: 26/Jun/14  Resolved: 25/Nov/12

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 25/Nov/12 ]

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

Comment by Doctrine Bot [ 26/Jun/14 ]

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





[DDC-2693] Attribute/association overrides should be ignored when generating entities Created: 19/Sep/13  Updated: 26/Jun/14

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

Type: Bug Priority: Minor
Reporter: Joris van de Sande Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: command

Issue Links:
Duplicate
is duplicated by DDC-3109 [Doctrine\ORM\Mapping\MappingExceptio... Open

 Description   

The "orm:generate-entities" command fails when doctrine attribute and/or association overrides are used. So from the moment that you use an attribute/association override, it is implossible to use the generate entities command. I think that the solution to this problem is to ignore the overrides when generating entities.

The exception given in case of an attribute override is (this is executed within a Symfony2 project doctrine:generate:entities):

Generating entity "My\AppBundle\Entity\Job"

  [Doctrine\ORM\Mapping\MappingException]
  Invalid field override named 'value' for class 'My\AppBundle\Entity\Job'.

Exception trace:
 () at /path/to/project/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php:89
 Doctrine\ORM\Mapping\MappingException::invalidOverrideFieldName() at /path/to/project/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php:1922
 Doctrine\ORM\Mapping\ClassMetadataInfo->setAttributeOverride() at /path/to/project/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/YamlDriver.php:564
 Doctrine\ORM\Mapping\Driver\YamlDriver->loadMetadataForClass() at /path/to/project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/Driver/MappingDriverChain.php:104
 Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain->loadMetadataForClass() at /path/to/project/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php:113
 Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata() at /path/to/project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:302
 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata() at /path/to/project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:212
 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor() at /path/to/project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:112
 Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getAllMetadata() at /path/to/project/vendor/doctrine/doctrine-bundle/Doctrine/Bundle/DoctrineBundle/Mapping/MetadataFactory.php:196
 Doctrine\Bundle\DoctrineBundle\Mapping\MetadataFactory->getAllMetadata() at /path/to/project/vendor/doctrine/doctrine-bundle/Doctrine/Bundle/DoctrineBundle/Mapping/MetadataFactory.php:176
 Doctrine\Bundle\DoctrineBundle\Mapping\MetadataFactory->getMetadataForClass() at /path/to/project/vendor/doctrine/doctrine-bundle/Doctrine/Bundle/DoctrineBundle/Mapping/MetadataFactory.php:76
 Doctrine\Bundle\DoctrineBundle\Mapping\MetadataFactory->getClassMetadata() at /path/to/project/vendor/doctrine/doctrine-bundle/Doctrine/Bundle/DoctrineBundle/Command/GenerateEntitiesDoctrineCommand.php:106
 Doctrine\Bundle\DoctrineBundle\Command\GenerateEntitiesDoctrineCommand->execute() at /path/to/project/vendor/symfony/symfony/src/Symfony/Component/Console/Command/Command.php:242
 Symfony\Component\Console\Command\Command->run() at /path/to/project/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:200
 Symfony\Component\Console\Application->doRun() at /path/to/project/vendor/symfony/symfony/src/Symfony/Bundle/FrameworkBundle/Console/Application.php:83
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at /path/to/project/vendor/symfony/symfony/src/Symfony/Component/Console/Application.php:106
 Symfony\Component\Console\Application->run() at /path/to/project/app/console:19


 Comments   
Comment by Rein Baarsma [ 27/Feb/14 ]

I have the same issue and it's easy to reproduce with a clean Symfony 2 setup with FOSUserBundle.
Once you add

 * @ORM\AttributeOverrides({
 *      @ORM\AttributeOverride(name="usernameCanonical",
 *          column=@ORM\Column(
 *              name     = "username_canonical",
 *              type     = "string",
 *              length   = 255,
 *              unique   = false
 *          )
 *      )
 * })

It will properly do doc:schema:update --force
But it will fail on doc:gen:entities (YourEntity)





[DDC-3109] [Doctrine\ORM\Mapping\MappingException] Invalid field override named 'xxx' for class 'Entity\xxx' Created: 30/Apr/14  Updated: 26/Jun/14

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

Type: Bug Priority: Major
Reporter: david pichsenmeister Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

kubuntu 14.04, php 5.5.9, MySQL 5.5


Attachments: File Organization.php     File User.php    
Issue Links:
Duplicate
duplicates DDC-2693 Attribute/association overrides shoul... Open

 Description   

Subclass should override association, but on generating entities, error:

[Doctrine\ORM\Mapping\MappingException]
Invalid field override named 'settings' for class 'Entity\Organization'.

is thrown. also, when updating schema, the assocations in the subclass are ignored (means are not present in the database).



 Comments   
Comment by Alexandre PAIXAO [ 23/May/14 ]

I think it is a duplicate of this bug : http://www.doctrine-project.org/jira/browse/DDC-2693





[DDC-2124] [GH-503] added unsigned mapping to SchemaTool options Created: 05/Nov/12  Updated: 26/Jun/14  Resolved: 06/Nov/12

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

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


 Description   

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

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

Message:

Just checking in SchemaTool if unsigned option is set and take this value.



 Comments   
Comment by Benjamin Eberlei [ 06/Nov/12 ]

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

Comment by Fabio B. Silva [ 06/Nov/12 ]

Merged : https://github.com/doctrine/doctrine2/commit/863d14a61a825d0a14f23b19e7c26cc6c01b4a76

Comment by Doctrine Bot [ 09/Jan/14 ]

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

Comment by Doctrine Bot [ 26/Jun/14 ]

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





[DDC-3180] [GH-1065] [DDC-3179] EntityNotFoundException on the postRemove event if the entity is a proxy Created: 20/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/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

Issue Links:
Dependency
depends on DDC-3179 Non initialized Proxy object with pos... Resolved

 Description   

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

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

Message:

This PR tries to fix DDC-3179(http://www.doctrine-project.org/jira/browse/DDC-3179).

I'm not sure if it is the way to go as this PR has a big drawback: it *always* loads proxies which needs to be removed regardless if there is an postRemove event for it. Anyway, there is no way to determine if there is an event for a specific entity in a lifecycle callback context.



 Comments   
Comment by Doctrine Bot [ 26/Jun/14 ]

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

Comment by Marco Pivetta [ 26/Jun/14 ]

Documented as known limitation, merged at https://github.com/doctrine/doctrine2/commit/9e36a95a978ac2cf8297b430368f8473c6ab67fb





[DDC-3179] Non initialized Proxy object with post remove listener Created: 19/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/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: Geoffrey Brier Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: proxy, unitofwork

Issue Links:
Dependency
is required for DDC-3180 [GH-1065] [DDC-3179] EntityNotFoundEx... Resolved

 Description   

Hi,

My use case is as follow:
I have an object "Demand" linked to a "Guarantor" which possesses a few files to delete from the server on the "post remove" doctrine event. The Demand -> Guarantor relation is configured to cascade persist and remove on the ORM side.

We intended to remove a "Demand" object but were getting an "EntityNotFoundException". After debugging a bit with a friend (eric geloen) we realized that when non initialized proxies have a listener on the post remove event, the object cannot loads itself as it does not exist anymore and this throws an exception. In my case, this means that I cannot delete the "Guarantor's" files.

So I was wondering if it was a bug coming from doctrine or a normal behavior. One could consider that it is our responsibility to correctly load an object and its graph yet one could also consider that this is a limitation (not to initialize the proxies beforehand).

While testing we moved the following snippet (that was in the cascadeRemove method) in the "executeDeletions" method right before the delete call and it was working.

if ($entity instanceof Proxy && !$entity->__isInitialized__) {
    $entity->__load();
}

What is your opinion?



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

Geoffrey Brier this may be a bug, but it needs a test case reproducing your exact scenario.

It would also be interesting to look at what you have so far.

Also, lowering priority.

Comment by Marco Pivetta [ 26/Jun/14 ]

Resolution in DDC-3180





[DDC-2353] [GH-616] [DDC-2252] Fix delete many-to-many composite key Created: 16/Mar/13  Updated: 26/Jun/14  Resolved: 06/Apr/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei 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/616

Message:

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



 Comments   
Comment by Doctrine Bot [ 26/Jun/14 ]

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





[DDC-3137] Entity Repository Interface Fatal Error Created: 24/May/14  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Bug Priority: Critical
Reporter: Aleksandr Yulin Assignee: Steve Müller
Resolution: Invalid Votes: 0
Labels: orm
Environment:

ZF2 + Doctrine 2



 Description   

For example:
$em = $this->getServiceLocator()->get('doctrine.entitymanager.orm_default');
$em->getRepository('MyEntity');

Response:
Fatal error: Class Doctrine\ORM\Repository\DefaultRepositoryFactory contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (Doctrine\ORM\Repository\RepositoryFactory::xgetRepository) in /srv/www/casestories.loc/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php on line 77



 Comments   
Comment by Aleksandr Yulin [ 24/May/14 ]

composer update problem, sorry, close issue





[DDC-3191] [GH-1072] Fix attempt of traversing bool in FileLockRegion Created: 26/Jun/14  Updated: 26/Jun/14

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

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


 Description   

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

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

Message:

Minor fix: on some platforms (i.e. ArchLinux) `glob()` returns `false` when nothing matched even though no errors occurred. As docs for `glob` say, such behavior is expected (see ‘Note’ at http://php.net/glob)

This made 1 existing test fail:

./vendor/bin/phpunit 
PHPUnit 4.3-g58f3a0e by Sebastian Bergmann.

Configuration read from /home/alex/git/doctrine2/phpunit.xml.dist

.............................................................   61 / 2495 (  2%)
........S.............E......................................  122 / 2495 (  4%)
.............................................................  183 / 2495 (  7%)
.............................................................  244 / 2495 (  9%)
.............................................................  305 / 2495 ( 12%)
.............................................................  366 / 2495 ( 14%)
.........................S...SSSS.S..........................  427 / 2495 ( 17%)
.............................................................  488 / 2495 ( 19%)
....................................................SS.......  549 / 2495 ( 22%)
.............................................................  610 / 2495 ( 24%)
.............................................................  671 / 2495 ( 26%)
.............................................................  732 / 2495 ( 29%)
.............................................................  793 / 2495 ( 31%)
.......................................................S.SSSS  854 / 2495 ( 34%)
SSSSSSSS.....................................................  915 / 2495 ( 36%)
.........................................SS..................  976 / 2495 ( 39%)
............S...S...........S..............................S. 1037 / 2495 ( 41%)
............................................................. 1098 / 2495 ( 44%)
..................S.......................................... 1159 / 2495 ( 46%)
.................................................SS.......... 1220 / 2495 ( 48%)
.......................S..................................... 1281 / 2495 ( 51%)
............................................................. 1342 / 2495 ( 53%)
............................................................. 1403 / 2495 ( 56%)
............................................................. 1464 / 2495 ( 58%)
............................................................. 1525 / 2495 ( 61%)
............................................................. 1586 / 2495 ( 63%)
.........S.................................................S. 1647 / 2495 ( 66%)
............................................................. 1708 / 2495 ( 68%)
............................................................. 1769 / 2495 ( 70%)
............................................................. 1830 / 2495 ( 73%)
............................................................. 1891 / 2495 ( 75%)
............................................................. 1952 / 2495 ( 78%)
............................................................. 2013 / 2495 ( 80%)
............................................................. 2074 / 2495 ( 83%)
............................................................. 2135 / 2495 ( 85%)
............................................................. 2196 / 2495 ( 88%)
............................................................. 2257 / 2495 ( 90%)
............................................................. 2318 / 2495 ( 92%)
............................................................S 2379 / 2495 ( 95%)
.......S......S.......S.....................S...........S.... 2440 / 2495 ( 97%)
.......................................................

Time: 14.37 seconds, Memory: 164.50Mb

There was 1 error:

1) Doctrine\Tests\ORM\Cache\FileLockRegionTest::testEvictAll
Invalid argument supplied for foreach()

/home/alex/git/doctrine2/lib/Doctrine/ORM/Cache/Region/FileLockRegion.php:204
/home/alex/git/doctrine2/tests/Doctrine/Tests/ORM/Cache/AbstractRegionTest.php:80

Traversing bool is no good and casting to array wouldn't hurt there as far as I can tell.






[DDC-3187] [GH-1070] Export nullable property only if is nullable Created: 24/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/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 Dudytz:

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

Message:



 Comments   
Comment by Doctrine Bot [ 24/Jun/14 ]

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





pager produces wrong results on postgresql (DDC-1958)

[DDC-2593] Same bug occurs in MariaDB 5.5 Created: 06/Aug/13  Updated: 26/Jun/14  Resolved: 26/Jun/14

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

Type: Sub-task Priority: Major
Reporter: Bojidar Hristov Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

//if ($this->platform instanceof PostgreSqlPlatform)

{ //http://www.doctrine-project.org/jira/browse/DDC-1958 $this->getPostgresqlSql($AST, $sqlIdentifier, $innerSql, $sql); //}

That way it works for MariaDB too.



 Comments   
Comment by Bojidar Hristov [ 24/Jun/14 ]

Anything?

Edit: I just saw in GitHub that it's fixed, but the issue is not resolved.

Comment by Marco Pivetta [ 26/Jun/14 ]

Was already handled in master





[DDC-3190] [GH-1071] Setup::createConfiguration breaks Cache interface contract Created: 25/Jun/14  Updated: 26/Jun/14  Resolved: 26/Jun/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 VasekPurchart:

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

Message:

Method `setNamespace` is called in `Setup::createConfiguration`, but at the moment there can be an instance of `Doctrine\Common\Cache\Cache` (when given in the 3rd parameter), which does not define this method. This method is defined in `Doctrine\Common\Cache\CacheProvider` from which are the defaults being instantiated in this method extended.

So there should be an condition or the 3rd parameter should declare a dependency on `CacheProvider` rather than just `Cache` interface. Or maybe the namespace should be set only if the Cache instance is not given by the 3rd parameter (as proposed in this PR now), assuming that when someone is giving a ready instance of Cache, it is configured properly.

If you want to take another approach, I can change this PR.



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

Merged: https://github.com/doctrine/doctrine2/commit/22d71de2c3f9632deb63a77646b11e21d9105cbd





[DDC-1682] EntityManager::clear() not working as expected. Created: 05/Mar/12  Updated: 25/Jun/14  Resolved: 27/May/12

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

Type: Bug Priority: Critical
Reporter: German Caseres Assignee: Benjamin Eberlei
Resolution: Incomplete Votes: 0
Labels: None
Environment:

Ubuntu 11.10
Symfony 2



 Description   

I've been reading Doctrine2 Batch Processing documentation.
I've a simplified the code and made a sample where I'm using a Repository inside the loop:

 
for ($i=1; $i<=10000; ++$i) {
     $user = $this->_em->getRepository('some user class')->find($i);
     $this->_em->clear();

     //Clear variables to ensure garbage collections     
     unset($user);
     $user = null;

}

I expect that this script will consume some constant memory in all iterations, but what happens is that every iteration raises memory consumption (more iterations, more memory).... i think that the clear method has some sort of memory leak.

In my production environment (with complex script), i reach a memory limit exception even with 600MB limit... but if I clear the EntityManager on every iteration, shouldn't memory be freed?

Sorry for my bad english.



 Comments   
Comment by Benjamin Eberlei [ 06/Mar/12 ]

You are probably running symfony2 in debug mode? Is the SQL logger enabled? This is probably not a Doctrine problem but something in your code / Symfony that keeps increasing the memory.

Comment by German Caseres [ 06/Mar/12 ]

I've executed the script in debug and prod mode, but I had the same problem in both modes.
I don't think it's a Symfony problem because I had measured memory consumption only before, after and inside the for loop (no symfony methods involved).
About my code, I'm using simple clases with no business code, only simple Doctrine mappings (and standard repository).
Have you tested a similar code? I don't understand why memory consumption continues raising if I'm "destroying" the objects.
I tried with gc_enable and gc_collect_cycles but no success... every iteration increases memory consumption like if the previous loaded objects weren't destroyed... maybe the repository is instancing other objects in every find call that are not destroyed?

Comment by Benjamin Eberlei [ 06/Mar/12 ]

are you using lifecycle listeners? access global state or something?

Comment by Benjamin Eberlei [ 11/Mar/12 ]

Can you generate an xdebug trace for some of the $i's ? say 100 and 1000 with xdebug_start_trace("/tmp/loop".$i); and xdebug_stop_trace(); and upload them? Maybe you can compare yourself, where in the loop the memory increases and if clear even empties it or not.

Comment by Marco Pivetta [ 01/Apr/12 ]

Any news about this one? There's been more than one case where the Symfony data collector (for debug) caused problems like this one... Imo this is not a ORM issue.

Comment by Benjamin Eberlei [ 27/May/12 ]

No feedback given.

Comment by Miha Vrhovnik [ 28/Aug/12 ]

I've been debugging a similar issue today. And Yes, the culprit is the Symfony's data collector. Running the command with --no-debug worked like a charm.

Comment by mathias dusautoy [ 15/Apr/13 ]

same issue here with 2.2.3, php 5.4 & symfony 2.1
have a symfony command running as deamon with --no-debug and no listeners

while(true)

{ $q = $this->em->createQueryBuilder()->select()...->getQuery(); $results = $q->getResult(AbstractQuery::HYDRATE_ARRAY); // commenting this line resolve the memory leak $this->em->clear(); gc_collect_cycles(); // with or without does not change the issue }

the consecutive traces shows that memory does not reduce after clear()

Comment by Marco Pivetta [ 15/Apr/13 ]

mathias dusautoy please check this in insulation (without Symfony2 if possible)

Comment by Benjamin Eberlei [ 15/Apr/13 ]

this may be array hydrator related, not sure that may not cause problems.

Comment by mathias dusautoy [ 16/Apr/13 ]

without symfony:

<?php

use Doctrine\ORM\Tools\Setup;
use Doctrine\ORM\EntityManager;

$loader = require_once __DIR__.'/../app/autoload.php';
$loader->add('Acme\\CoreBundle', __DIR__.'/../src/Acme/CoreBundle/');

$isDevMode = true;
$config = Setup::createAnnotationMetadataConfiguration(array(__DIR__."/../src/Acme/CoreBundle/Entity"), $isDevMode, null, null, false);

$conn = array(
	'driver' => 'pdo_mysql',
	'host' => 'localhost',
	'dbname' => 'dbname',
	'user' => 'root',
	'password' => ''
);

$em = EntityManager::create($conn, $config);

$d = new \DateTime();

while(true) {
	echo memory_get_usage() . PHP_EOL;
	$qb = $em->createQueryBuilder()
		->select('c')
		->from('Acme\\CoreBundle\\Entity\\Consultation', 'c')
		->where('c.date > :date')->setParameter(':date', $d)
		->orderBy('c.date', 'ASC');

	$q = $qb->getQuery();

	$results = $q->getResult();

	foreach($results as $c) {
		echo $c->getDate()->format('H:i:s') . PHP_EOL;
	}
	
	$q->free();

	$em->clear();

	gc_collect_cycles();
	
	echo memory_get_usage() . PHP_EOL . PHP_EOL;
}

output:

7978568
7978568

7978568
7978568

7978568
11:51:27
11474520

11474520
11473368

11473368
11473368

11473368
11473368

11473368
11473368

Am I missing something?

Comment by Marco Pivetta [ 16/Apr/13 ]

Memory usage here seems quite constant (the change from 7978568 to 11474520 may well be because of metadata and hydrators). The output doesn't seem to be conforming your snippet though.

Comment by mathias dusautoy [ 16/Apr/13 ]

yes sorry the above output is for:

foreach($results as $c) {
    echo $c->getDate()->format('H:i:s') . PHP_EOL;
    $d = $c->getDate();
}

with

foreach($results as $c) {
    echo $c->getDate()->format('H:i:s') . PHP_EOL;
}

the output is:

3489864
12:22:27
13502680

13502680
12:22:27
13515496

13515496
12:22:27
13528328

13528328
12:22:27
13541144

13541144
12:22:27
13553976

....


74513560
12:22:27
74526520

74526520
12:22:27
74539520

74539520
12:22:27
74552560

and goes on

Comment by Christophe Coevoet [ 17/Apr/13 ]

Do you have bidirectional relations in your user entity ? If yes, you will still have some references to the object after clearing the EntityManager (in the related object, itself reference by the user)

Comment by Bruno Lemos [ 25/Jun/14 ]

Fixed it by doing the following:

$this
->_em
->getConnection()
->getConfiguration()
->setSQLLogger(null);





[DDC-3186] [GH-1069] added method to be able to reuse the console application Created: 24/Jun/14  Updated: 24/Jun/14

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

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


 Description   

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

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

Message:

This comes in handy, when you want to do more with the actual application object then just to run it.






[DDC-3185] [GH-1068] Fix typo in documentation Created: 24/Jun/14  Updated: 24/Jun/14  Resolved: 24/Jun/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 jkavalik:

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

Message:



 Comments   
Comment by Doctrine Bot [ 24/Jun/14 ]

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

Comment by Marco Pivetta [ 24/Jun/14 ]

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





[DDC-3184] Invalid hydration of entities using ManyToOne relation via queryBuilder Created: 23/Jun/14  Updated: 23/Jun/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4, 2.4.1, 2.4.2, 2.4.3
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Dmitry Korotovsky Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File DDC3184Test.php    

 Comments   
Comment by Dmitry Korotovsky [ 23/Jun/14 ]

In master branch all works perfect

Comment by Dmitry Korotovsky [ 23/Jun/14 ]

Marco Pivetta, fix in 2.5 branch will be ported to 2.4 stable version?

Comment by Marco Pivetta [ 23/Jun/14 ]

Dmitry Korotovsky first we'll need to check what commit fixed the issue. Could you git bisect with your test?

Comment by Dmitry Korotovsky [ 23/Jun/14 ]

Yes, i found it: https://github.com/doctrine/doctrine2/commit/38b683838648b549aad0e38ce88c70b6393755b3

Comment by Marco Pivetta [ 23/Jun/14 ]

Assigning to Guilherme Blanco, since he is the author of the fix.





[DDC-3183] Add JsonSerializable to Collections Created: 22/Jun/14  Updated: 22/Jun/14

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

Type: New Feature Priority: Major
Reporter: Gabriel Bull Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, orm


 Description   

Implement this:

http://www.php.net/manual/fr/class.jsonserializable.php

Can't really make this claim if Doctrine is not implementing basic interfaces for collections:

> The missing (SPL) Collection/Array/OrderedMap interface.






[DDC-3182] [GH-1066] Added jsonSerialize method to PersistentCollection Created: 22/Jun/14  Updated: 22/Jun/14

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

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


 Description   

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

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

Message:

Added jsonSerialize.

Here is to commit on collections:
https://github.com/doctrine/collections/pull/33



 Comments   
Comment by Doctrine Bot [ 22/Jun/14 ]

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





[DDC-1875] "Call to a member function toArray() on a non-object" in PersistentCollection::takeSnapshot() during LEFT JOIN Created: 15/Jun/12  Updated: 22/Jun/14  Resolved: 06/Oct/12

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

Type: Bug Priority: Major
Reporter: Jelmer Schreuder Assignee: Benjamin Eberlei
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

Windows + latest XAMPP



 Description   

I am getting the fatal error "Call to a member function toArray() on a non-object" which is triggered in Doctrine/ORM/PersistentCollection.php on line 239 by $this->snapshot = $this->coll->toArray();

SELECT i, c FROM Page i
LEFT JOIN i.children c
WHERE i.parent_id IS NULL
	AND i.site = ?1
ORDER BY i.id ASC

The association is self-referential on the column parent_id. Removing "LEFT" from the query makes is run successfully (but ofc not in the way I need it). Making it only select 'i' instead of 'i, c' also solves it. But I don't think it's wrong in it's current form is it?

The Entity (slightly truncated to remove personal/local info) is at http://scrp.at/bvl



 Comments   
Comment by Benjamin Eberlei [ 05/Jul/12 ]

can you paste the full stack trace when the error occurs? Xdebug shows this.

Comment by Benjamin Eberlei [ 06/Oct/12 ]

No feedback given and cannot reproduce.

Comment by Oleg Kolomiets [ 21/Jun/14 ]

( ! ) Fatal error: Call to a member function toArray() on a non-object in /var/www/html/mktl/vendor/doctrine/orm/lib/Doctrine/ORM/PersistentCollection.php on line 245
Call Stack

  1. Time Memory Function Location
    1 0.0001 233752
    Unknown macro: {main}

    ( ) ../index.php:0
    2 0.0003 234472 require_once( '/var/www/html/mktl/public/app.php' ) ../index.php:17
    3 0.0573 3065184 Zend\Mvc\Application->run( ) ../app.php:33
    4 0.0590 3100288 Zend\EventManager\EventManager->trigger( ) ../Application.php:309
    5 0.0590 3100336 Zend\EventManager\EventManager->triggerListeners( ) ../EventManager.php:207
    6 0.0594 3108144 call_user_func:

    Unknown macro: {/var/www/html/mktl/vendor/zendframework/zendframework/library/Zend/EventManager/EventManager.php}

    ( ) ../EventManager.php:468
    7 0.0594 3108712 Zend\Mvc\DispatchListener->onDispatch( ) ../EventManager.php:468
    8 0.0600 3169304 Zend\Mvc\Controller\AbstractController->dispatch( ) ../DispatchListener.php:114
    9 0.0600 3169784 Zend\EventManager\EventManager->trigger( ) ../AbstractController.php:117
    10 0.0600 3169832 Zend\EventManager\EventManager->triggerListeners( ) ../EventManager.php:207
    11 0.0604 3185720 call_user_func:

    Unknown macro: {/var/www/html/mktl/vendor/zendframework/zendframework/library/Zend/EventManager/EventManager.php}

    ( ) ../EventManager.php:468
    12 0.0604 3186312 Admin\AController->onDispatch( ) ../EventManager.php:468
    13 0.0746 4270960 Zend\Mvc\Controller\AbstractActionController->onDispatch( ) ../AController.php:159
    14 0.0747 4271224 Admin\Controller\BrandsController->editAction( ) ../AbstractActionController.php:83
    15 0.0751 4313696 Products\Repositories\BrandRepository->find( ) ../BrandsController.php:70
    16 0.0761 4451448 Doctrine\ORM\AbstractQuery->getResult( ) ../BrandRepository.php:60
    17 0.0761 4451808 Doctrine\ORM\AbstractQuery->execute( ) ../AbstractQuery.php:542
    18 0.0768 4473080 Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll( ) ../AbstractQuery.php:751
    19 0.0769 4477328 Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateAllData( ) ../AbstractHydrator.php:111
    20 0.0781 4673184 Doctrine\ORM\PersistentCollection->takeSnapshot( ) ../ObjectHydrator.php:155

Comment by Marco Pivetta [ 22/Jun/14 ]

Are the mappings passing validation?





[DDC-3177] [GH-1063] singularize variable name on add/remove methods for EntityGenerator Created: 19/Jun/14  Updated: 21/Jun/14  Resolved: 21/Jun/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 FlorianLB:

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

Message:

Not a big change but corrects an error of plural.

Previously :
```php
public function addComment(EntityGeneratorComment $comments)

{ $this->comments[] = $comments; return $this; }

```

With this PR :
```php
public function addComment(EntityGeneratorComment $comment)

{ $this->comments[] = $comment; return $this; }

```



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

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





[DDC-3129] [GH-1032] Add support for optimized contains Created: 17/May/14  Updated: 21/Jun/14  Resolved: 21/Jun/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 bakura10:

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

Message:

Hi,

This continue my work on the LazyCriteria and include a support for optimized contains that does not initialize the full collection when checking if a record exists in a collection.

Please note that I had to modify the exists method signature in EntityInterface. I'm not sure this is a problem because, as @ocramius said in the ManyToMany thread, custom persisters is not supported. However, I added a small note to be sure .



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

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





[DDC-2358] [GH-621] [doc] adding some more doc and examples for lifecycle event listeners and subscribers Created: 19/Mar/13  Updated: 20/Jun/14  Resolved: 06/Apr/13

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

Type: Documentation Priority: Major
Reporter: Benjamin Eberlei Assignee: David Buchmann
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

as requested in https://github.com/symfony/symfony-docs/pull/2301



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

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





[DDC-3181]