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





[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





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-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-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-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-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-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-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-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-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-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-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-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-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-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-3189] blob doctrine2 not inserting file in mysql Created: 24/Jun/14  Updated: 26/Jun/14

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

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

Linux Ubuntu 12.04, Mysql 5


Attachments: PNG File a.png     Zip Archive testedoctrineupload.zip    

 Description   

I have an entity mapped as:

/**
 * @Entity @Table(name="Upload")
**/
class Upload
{
/** @Id @Column(type="integer") @GeneratedValue **/
protected $id;

/** @Column(type="string") **/
protected $nome;

/** @Column(type="blob") **/
protected $arquivo;

When I use this (WORKS)

 $query = "INSERT INTO Upload1 (name, size, type, content ) "."VALUES ('$fileName', '$fileSize', '$fileType', '$content')";

 mysql_query($query)

When I use this doctrine way (NOT WORKING, if you try to get this file from mysql, return a corrupted or empty file)

$upload = new Upload();

$upload-> setContent($content);
$upload-> setName($fileName);
$upload-> setSize($fileSize);
$upload-> setType($fileType);

$entityManager->persist($upload);
$entityManager->flush();

My html file:

<form method="post" enctype="multipart/form-data">
<table width="350" border="0" cellpadding="1" cellspacing="1" class="box">
<tr> 
<td width="246"> 
<input type="hidden" name="MAX_FILE_SIZE" value="2000000">
<input name="userfile" type="file" id="userfile"> 
</td>
<td width="80"><input name="upload" type="submit" class="box" id="upload" value=" Upload    "></td>
</tr>
</table>
</form>


 Comments   
Comment by Gustavo Monti Rocha [ 24/Jun/14 ]

trying to insert this image

Comment by Gustavo Monti Rocha [ 24/Jun/14 ]

Using:
$entityManager->getConnection()>getConfiguration()>setSQLLogger( new Doctrine\DBAL\Logging\EchoSQLLogger());

Getting:
"START TRANSACTION" INSERT INTO Upload (name, type, size, content) VALUES (?, ?, ?, ?) array(4) { [1] => string(5) "a.png" [2] => string(9) "image/png" [3] => int(264547) [4] => string(270342) "‰PNG  \0\0\0 IHDR\0\0@\0\0„\0\0\0v/jõ\0\0\0sBITÛáOà\0\0\0tEXtSoftware\0gnome-screenshotï¿>\0\0 \0IDATxœìw|TÅöÀÏܲ{·$›^I¥“Лҫ€ QPô©`

{êÏγ÷^ŸýYÀ‚ˆ\"¢ô %½m’í햙ߛ,›mÙe¾>š½÷Ι™3gæÎœ;]3ÿR P( …B¡P( …\0\0³X¾Ÿ†X]ŸÞ]ÿÂôP(\0àÜnñ¯N…B¡P( …B¡P(„B\0\0\\.÷ñ’ÊüünݺÇøîÚl¶m;æçfh4\0@BUR)”3®©šR( …B¡P( …ræa2Y+«ëV\0@4……}

Y–<¸§×KEÙ±ãHaaßâ¢#n·\0Ãf¦§ÄÇÇþÅé¦PÎ0¨‹B¡P( …B¡P(g(„ÙttTJ5\"\0< g§æefe¥ú?3rd¿Š £V.W7ì&\0˜âF+‰ø%9uÆF\0HINø«pôx…ZÅuÉL¥“Ô(‘Ù³¯\0ú÷í}ã¶9°A‡Óãr¥Åé¯n"... } array(4)

{ [1] => string(6) "string" [2] => string(6) "string" [3] => string(7) "integer" [4] => string(4) "blob" }

"COMMIT"

Comment by Steve Müller [ 26/Jun/14 ]

This looks more like a DBAL issue. Can you please provide the error/exception message that you receive from the driver/database server? Also do you use PDOMySQL or mysqli driver?

Comment by Gustavo Monti Rocha [ 26/Jun/14 ]

Steve,

I'm not getting any error/expection. Table looks like insert the blob file but when I try to download it is corrupted. You could see at getting .zip file and executing it.

I'm using PDOMysql.

Comment by Marco Pivetta [ 26/Jun/14 ]

This would probably need a data sample to reproduce the issue.

Comment by Gustavo Monti Rocha [ 26/Jun/14 ]

Marco,

you could use project attached and image in order to reproduce.

Comment by Marco Pivetta [ 26/Jun/14 ]

Gustavo Monti Rocha you should actually provide a functional test for this in case, see https://github.com/doctrine/dbal/tree/master/tests/Doctrine/Tests/DBAL

For example, the zip file you uploaded fails on various includes, and doesn't show the failures to me.





[DDC-3188] Call to a member function getValue() on a non-object in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php Created: 24/Jun/14  Updated: 27/Jun/14

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

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

PHP 5.4.11
opensuse
apache2



 Description   

This is the line that causes the fatal error: https://github.com/doctrine/doctrine2/blob/v2.4.2/lib/Doctrine/ORM/UnitOfWork.php#L678

This is the association that is breaking it (i.e. reflFields[ 'user' ] is a non-object):

Tweet.php
/**
 * @ManyToOne(targetEntity="User")
 * @JoinColumn(name="user_id", referencedColumnName="id")
 *
 * @var User
 */
protected $user;

This is the pk of the referenced entity.

User.php
/**
 * @Id
 * @Column(name="id", type="bigint", nullable=false)
 *
 * @var int
 */
protected $id;

If an exception was thrown due to missing metadata information, I could catch it, but fatal errors due to this bug have been crashing our scripts and they've had to be manually restarted.

Let me know what other information is needed.

Full stack trace:

PHP 5. Doctrine\ORM\EntityManager->flush() our_code.php
PHP 6. Doctrine\ORM\UnitOfWork->commit() vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:389
PHP 7. Doctrine\ORM\UnitOfWork->computeChangeSets() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:297
PHP 8. Doctrine\ORM\UnitOfWork->computeScheduleInsertsChangeSets() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:703
PHP 9. Doctrine\ORM\UnitOfWork->computeChangeSet() vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:404
PHP Fatal error: Call to a member function getValue() on a non-object in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 678



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

Did you actually validate your mappings?

Comment by Daniel Imhoff [ 24/Jun/14 ]

I did not validate the mapping. I did not know about the orm:validate-schema until just now. I will fix these errors and resubmit if there is still an issue.

Sorry about that, thanks.

Comment by Daniel Imhoff [ 24/Jun/14 ]

The tweet and user relationship is not in the list of invalid mappings.

Comment by Marco Pivetta [ 26/Jun/14 ]

Are User and Tweet in the same namespace?

Comment by Daniel Imhoff [ 27/Jun/14 ]

Yes, and I've since then used the FQNS. I would get a class not found error when validating schema.
This is something that I know can't really be debugged by you guys, I was just hoping for a little direction. We are using memcache to store our metadata, and we are clearing and regenerating the metadata during every deploy (it is not autogenerated). I'm now using a commit hash as the namespace of the metadata, so we'll see if this fixes the issue.

Comment by Marco Pivetta [ 27/Jun/14 ]

It looks like a typo (CasESensiTIViTy issue) to me.





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





[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-3181] Class Table Inheritance - wrong table order on insert with more than one level of inheritance Created: 20/Jun/14  Updated: 20/Jun/14

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

Type: Bug Priority: Major
Reporter: M. de Lange Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

oracle



 Description   

note: this issue seems the same as DDC-732

When using class table inheritance with multiple levels i.e.:
Object -> SolidObject -> Building -> House
(House inherits from Building, Building from SolidObject, SolidObject from Object)

Object has the discriminator column and mapping. When persisting a new House entity I get a foreign key error because there is no row in the Building table.

I searched in the Code and found the problem. In the class "Doctrine\ORM\Persisters\JoinedSubclassPersister" in function "executeInserts()" around line 146 the array $subTableStmts is first declared and then filled with insert statements. The statement of the House-table is first added, and then the parent-tables (except the root-table "Object", since that one is executed first).

So the order in which the insert statements are executed is:
1 Insert into Object ...
2 Insert into House ... (which causes the error)
3 insert into Building ...
4 Insert into SolidObject

I edited the source to insert into the parent-tables (first SolidObject, then Building) before inserting into the table that belongs to the class that is persisted (House). And this works fine in my case.






[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-3178] [GH-1064] remove on-update from join-column Created: 19/Jun/14  Updated: 19/Jun/14  Resolved: 19/Jun/14

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

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


 Description   

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

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

Message:

to be in line with #79



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

Merged: https://github.com/doctrine/doctrine2/commit/85c02e57b1eb328e68072650616805b9751bef00





[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-3176] Table-inheritance and OneToOne association as entity ID Created: 18/Jun/14  Updated: 18/Jun/14

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

Type: Bug Priority: Major
Reporter: Elioty Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: association, identity, inheritance, orm
Environment:

Ubuntu 14.04, PHP 5.5.9-1ubuntu4, Symfony 2.5



 Description   

The issue is fully described here:
http://stackoverflow.com/questions/24265731/symfony-doctrine-class-table-inheritance-and-foreign-key-as-primary-key






[DDC-3175] Update documentation for QueryBuilder to give example of using "set()" with parameter Created: 17/Jun/14  Updated: 17/Jun/14

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

Type: Documentation Priority: Minor
Reporter: Max Summe Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

PHP 5.3



 Description   

QueryBuilder->set method uses Expr\Comparison object, which tries to cast values as strings.

When trying to set('updated', new \DateTime) in an update statement, this causes an exception as \DateTime has no __toString method.

Not sure what the fix is - the format for the \DateTime there depends on the platform and ( I think) the type of field.



 Comments   
Comment by Christophe Coevoet [ 17/Jun/14 ]

you should not set a value directly in the DQL query. You should use the query parameters instead.

Comment by Max Summe [ 17/Jun/14 ]

So you're saying it should not be used like this.

$qb = $em->createQueryBuilder();
$qb->update('User', 'u')
->set("u.field", "new value")
->where("u.field = :oldvalue")
->setParameter("oldvalue", "old value");

Instead, it should be:

$qb = $em->createQueryBuilder();
$qb->update('User', 'u')
->set("u.field", ":value")
->where("u.field = :oldvalue")
->setParameter("oldvalue", "old value")
->setParameter("value", "new value");

Is that correct?

If yes, it would be helpful to add an example to the documentation in this page: http://docs.doctrine-project.org/en/latest/reference/query-builder.html





[DDC-3174] Query Cache not correct working when using SQLFilter Created: 17/Jun/14  Updated: 17/Jun/14

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

Type: Bug Priority: Major
Reporter: Benno Eggnauer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cache, sqlfilter


 Description   

We have an SQLFilter to filter on entities with a specific Trait implemented. The filter is very easy:

$res = $targetTableAlias . '.agency_id = ' . $this->getCurrentAgencyId();

On our system we have the query cache enabled, this works as long the "AgencyId" doesn't change. When the ID changes, the query cache seems to return the wrong (old cache) query.



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

I'm not sure if this case should be contemplated by the ORM. Filters are low-level and supposed to be stateless (services).

Comment by Benno Eggnauer [ 17/Jun/14 ]

OK, we can disable the query cache for this case. But then should at least the documentation be updated, which explicitly mentions to use filter for locales, which are also not stateless: http://doctrine-orm.readthedocs.org/en/latest/reference/filters.html#example-filter-class

Also in the query cache chapter: http://doctrine-orm.readthedocs.org/en/latest/reference/caching.html#query-cache

It is highly recommended that in a production environment you cache the transformation of a DQL query to its SQL counterpart. It doesn’t make sense to do this parsing multiple times as it doesn’t change unless you alter the DQL query.

Comment by Marco Pivetta [ 17/Jun/14 ]

Benno Eggnauer can you eventually provide a pull request?





[DDC-3173] [GH-1062] Doctrine new config parameter on oracle dbal/mapping: Owner Created: 17/Jun/14  Updated: 17/Jun/14  Resolved: 17/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 cirovargas:

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

Message:

When i can access a database with a user and map other user schema, example:

I connect to the server using USER1 credentials and need to use USER2 schema

Ccctually this is not suported:

Sugestions:

set a new config parameter with owner to put on front query like select * from OWNER.TABLE

and on the mapping update query mappings with these:

swap this:

doctrine\dbal\lib\Doctrine\DBAL\Platforms\OraclePlatform.php
public function getListSequencesSQL($database)
322

{ 323: return "SELECT sequence_name, min_value, increment_by FROM sys.all_sequences ". 324 "WHERE SEQUENCE_OWNER = '".strtoupper($database)."'"; 325 }

...
387 public function getListViewsSQL($database)
388

{ 389: return 'SELECT view_name, text FROM sys.user_views'; 390 }

FOR THIS

public function getListSequencesSQL($database,$owner)

{ return "SELECT sequence_name, min_value, increment_by FROM sys.all_sequences ". "WHERE SEQUENCE_OWNER = '".$owner."'"; }


/**
* {@inheritDoc}
*/
public function getListSequencesSQL($database,$owner)
{ return "SELECT sequence_name, min_value, increment_by FROM sys.all_sequences ". "WHERE SEQUENCE_OWNER = '".$owner."'"; }

Worked fine for me on tests.

Tnks






[DDC-3172] [GH-1061] 2.4 Doctrine dont use custom schemas Created: 17/Jun/14  Updated: 17/Jun/14  Resolved: 17/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 cirovargas:

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

Message:

When i can access a database with a user and map other user schema, example:

I connect to the server using USER1 credentials and need to use USER2 schema

Ccctually this is not suported:

Sugestions:

set a new config parameter with owner to put on front query like select * from OWNER.TABLE

and on the mapping update query mappings with these:

swap this:

doctrine\dbal\lib\Doctrine\DBAL\Platforms\OraclePlatform.php
public function getListSequencesSQL($database)
322

{ 323: return "SELECT sequence_name, min_value, increment_by FROM sys.all_sequences ". 324 "WHERE SEQUENCE_OWNER = '".strtoupper($database)."'"; 325 }

...
387 public function getListViewsSQL($database)
388

{ 389: return 'SELECT view_name, text FROM sys.user_views'; 390 }

FOR THIS

public function getListSequencesSQL($database,$owner)

{ return "SELECT sequence_name, min_value, increment_by FROM sys.all_sequences ". "WHERE SEQUENCE_OWNER = '".$owner."'"; }


/**
* {@inheritDoc}
*/
public function getListSequencesSQL($database,$owner)
{ return "SELECT sequence_name, min_value, increment_by FROM sys.all_sequences ". "WHERE SEQUENCE_OWNER = '".$owner."'"; }

Worked fine for me on tests.

Tnks






[DDC-3171] [GH-1060] [DDC-3170] SimpleObjectHydrator fails to get discriminator column from mapped SQL result Created: 17/Jun/14  Updated: 17/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 ureimers:

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

Message:

This PR fixes DDC-3170(http://www.doctrine-project.org/jira/browse/DDC-3170).

When querying a simple entity which uses single table- or class table inheritance using simple object hydration (``AbstractQuery::HYDRATE_SIMPLEOBJECT``), the mapped discriminator column was not retrieved correctly.

If the column got an alias during result set mapping other than it's actual name (e.g. ``type34`` instead of ``type``) than this alias wasn't correctly resolved when retrieving the discriminator column from the SQL result set.



 Comments   
Comment by Ulf Reimers [ 17/Jun/14 ]

I created DDC-3170 for this and put it into the PR like stated in https://github.com/doctrine/doctrine2/blob/master/CONTRIBUTING.md#doctrinebot-tickets-and-jira.

Unfortunately the BOT still created this issue here which can be removed in my opinion.

Comment by Doctrine Bot [ 17/Jun/14 ]

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





[DDC-3170] SimpleObjectHydrator fails to get discriminator column from mapped SQL result Created: 17/Jun/14  Updated: 17/Jun/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: Ulf Reimers Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: hydrator, inheritance, orm


 Description   

When querying a simple entity which uses single table- or class table inheritance using simple object hydration (AbstractQuery::HYDRATE_SIMPLEOBJECT), the mapped discriminator column is not retrieved correctly.

Example:

/**
 * @Entity
 * @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="type", type="string")
 * @DiscriminatorMap({"product" = "Product"})
 */
abstract class AbstractEntity
{
    /** @Id @Column(type="integer") @GeneratedValue */
    public $id;
}

/**
 * @Entity
 */
class Product extends AbstractEntity
{
}

$manager->createQueryBuilder()
                ->select('p')
                ->from('Product, 'p')
                ->getQuery()
                ->getResult(AbstractQuery::HYDRATE_SIMPLEOBJECT);

// -> Exception: [Doctrine\ORM\Internal\Hydration\HydrationException] The discriminator column "type" is missing for "Product" using the DQL alias "p".

The SQL statement used is equal to:

SELECT r0_.id AS id0, r0_.type AS type1 FROM Product r1_ INNER JOIN AbstractEntity r0_ ON r1_.id = r0_.id

As you can see, the type column is given an alias of type1. This is saved in the ResultSetMapping of the request but not taken into account when actually retrieving the discriminator column back from the SQL result.

The problem is inside SimpleObjectHydrator#hydrateRowData().

When the discriminator column name is fetched via

$discrColumnName = $this->_platform->getSQLResultCasing($this->class->discriminatorColumn['name']);

the result is simply type which is wrong because the alias is type2. This can be fixed by adding

if ($metaMappingDiscrColumnName = array_search($discrColumnName, $this->_rsm->metaMappings)) {
    $discrColumnName = $metaMappingDiscrColumnName;
}

right after the column retrieval, because then the alias of the meta field type is correctly taken into account.

I'll create a PR with a unit test for this fix right after this ticket's creation.

I hope I'm doing everything right, this is my first contribution.



 Comments   
Comment by Ulf Reimers [ 17/Jun/14 ]

PR is https://github.com/doctrine/doctrine2/pull/1060

I though that I first create a ticket, then propose a fix for that with a PR and by adding the Ticket ID in the PR-Title they are linked automatically. But unfortunately it seems I've done something wrong there.

Comment by Doctrine Bot [ 17/Jun/14 ]

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





[DDC-3169] ManyToMany association fails when joining on a single column of a composity key Created: 17/Jun/14  Updated: 17/Jun/14

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

Type: Bug Priority: Major
Reporter: Bram Gerritsen Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: association, composite, orm


 Description   

I have two entities with a ManyToMany association between them. The first entity Campsite has a composite key (campsiteID, year). The second entity Region has a single key (regionID).
I want to create an association between Campsite::campsiteID and Region::regionID. See the entities below.

Campsite
/**
 * @ORM\Table(name="Campsite")
 */
class Campsite
{
    /**
     * @ORM\Id
     * @ORM\Column(name="campsiteID", type="integer", precision=0, nullable=false)
     */
    protected $campsiteID;

    /**
     * @ORM\Id
     * @ORM\Column(name="year", type="smallint", precision=0, nullable=false)
     */
    protected $year;

    /**
     * @ORM\ManyToMany(targetEntity="AcsiGeo\Entity\Region", fetch="EAGER", cascade={"detach"})
     * @ORM\JoinTable(name="CampsiteRegion",
     *   joinColumns={
     *     @ORM\JoinColumn(name="campsiteID", referencedColumnName="campsiteID", nullable=false)
     *   },
     *   inverseJoinColumns={
     *     @ORM\JoinColumn(name="regionID", referencedColumnName="regionID", nullable=false)
     *   }
     * )
     * @var \Doctrine\Common\Collections\ArrayCollection $regions
     */
    protected $regions;
}
Region
/**
 * @ORM\Table(name="Region")
 */
class Region
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     * @ORM\Column(name="regionID", type="integer", precision=0, nullable=false)
     */
    protected $regionID;
}

I run the following code to persist a new one.

$campsite = new Campsite();
$campsite->setCampsiteID(111111);
$campsite->setYear(2014);

$region = new Region();
$region->setRegionID(1);
$campsite->addRegion($region);

$em->persist($region);
$em->persist($campsite);
$em->flush();

This results in a record added to the CampsiteRegion table:

campsiteID : 2014
regionID: 1

This is clearly wrong as the value of the year field is added to the campsiteID column.

While debugging the problem I've found an issue with the method to determine the params in ManyToManyPersister on line 147.
The following code pops the last identifier from the array of identifiers.

$params[] = $isRelationToSource ? array_pop($identifier1) : array_pop($identifier2);

In my case:

array(
    'campsiteID' => 111111,
    'year' => 2014
)

Which picks 2014 as the value to use.
When I change the code to get the actual column from the array everything works as expected.

$params[] = $isRelationToSource ? $identifier1[$joinTableColumn] : $identifier2[$joinTableColumn];

I am not 100% sure if this change will have some side effects / edge case I'm not aware of.

For the time being I have fixed the problem bij just reversing the properties in my class, but this is not a real fix of course.






[DDC-3168] [GH-1059] fix spacing for yaml example Created: 16/Jun/14  Updated: 16/Jun/14  Resolved: 16/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: 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 iampersistent:

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

Message:



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

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

Comment by Marco Pivetta [ 16/Jun/14 ]

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





[DDC-3167] Inherited property ignoral Created: 16/Jun/14  Updated: 17/Jun/14  Resolved: 16/Jun/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: Christian Daguerre Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: orm


 Description   

Hi, This isn't a bug, more a question I originally posted here: https://github.com/doctrine/DoctrineBundle/issues/297

I have the following entity hierarchy, MyProduct being a parent entity mapped through class table inheritance :

SyliusProduct # Mapped superclass containing the 'options' association mapping
– MyProduct # Mapped superclass that should override the association (Head of CTI)
---- MyProduct1 # Ultimate children (entities)
---- MyProduct2
---- MyProduct3
---- MyProduct4

I can't change the mapping of SyliusProduct (it's part of a Symfony vendor).
When generating the schema, doctrine wants to generate sylius_product_options tables for each ultimate child, which throws a 'tables exists' exception.

Is there a way to either:

  • map the association at ultimate child level by creating 4 different tables (and specify different table names)?
  • map it at MyProduct level?
  • Simply ignore the association?

I hope this is the right place and way to ask this question...



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

Hi, sorry, but I have to close the ticket as it is not an issue/feature request. Use http://stackoverflow.com/ for such kind of questions.

Feel free to provide a link to the question in a comment below once you've ported it to SO.

Comment by Christian Daguerre [ 17/Jun/14 ]

OK, so I guess this 'feature' exists?
I asked the question here: http://stackoverflow.com/questions/24271957/doctrine-class-table-inheritance-and-property-ignoral





[DDC-3166] [GH-1058] Drop Unicode character Created: 15/Jun/14  Updated: 15/Jun/14  Resolved: 15/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: 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 DavidPrevot:

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

Message:

It broke the LaTeX build.



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

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

Comment by Marco Pivetta [ 15/Jun/14 ]

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





[DDC-3165] one to zero or one with identity through foreign entity Created: 13/Jun/14  Updated: 13/Jun/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: Andries Seutens Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   
<?php

/**
 * @Entity
 */
class User
{
    /** 
     * @Id @Column(type="integer") 
     * @GeneratedValue 
     */
    private $id;
    
    /**
     * @ORM\OneToOne(targetEntity="Address")
     *
     * @var Address
     */
    private $address;
    
    public function getAddress()
    {
        return $this->address;
    }
}

/**
 * @Entity
 */
class Address
{
    /**
     * @Id @OneToOne(targetEntity="User") 
     */
    private $user;
    
    public function foo()
    {}
}


?>

The relation between user and address is one to zero or one. When a record exists on both sides, everything goes fine. When the right side (address) does not have a relevant record, calling $user->getAddress(); always returns an instance. Calling a method on that instance results in an exception:

Fatal error: Uncaught exception 'Doctrine\ORM\EntityNotFoundException' with message 'Entity of type 'Address' was not found.' in doctrine/orm/lib/Doctrine/ORM/Proxy/ProxyFactory.php on line 176

Expected behaviour:
$user->getAddress() should return NULL when the right side is empty.

NOTES:
Mind that the address is identified through a foreign entity (User)






[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-3163] security.context getToken() return null Created: 11/Jun/14  Updated: 12/Jun/14  Resolved: 12/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: M. C. Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: context, listener, security, service, token
Environment:

Windows 8, WAMP, Symfony 2.5



 Description   

On my entity listener i have this part of code on preUpdate()

L48 : $secuContext = $this->container->get('security.context');
L49 : $actualUser = $secuContext->getToken()->getUser();

container are injected, this code worked on v2.4.2, but after update 2.4.3 when i run doctrine:fixtures:load i got this error on the console :
PHP Fatal error: Call to a member function getUser() on a non-object in C:\wamp
\www\project\src\acme\EntityBundle\Service\AcmeListener.php on line
49



 Comments   
Comment by Christophe Coevoet [ 11/Jun/14 ]

This is not a Doctrine bug at all. It is a bug in your own code, and related to a place using Symfony code, not Doctrine code.

Btw, getToken is documented as returning TokenInterface|null. If you are not behind a firewall, or if you run your logic before the authentication is completed by the security layer, it will be null

Comment by M. C. [ 11/Jun/14 ]

I can understand this, but can you explain why in older version the same code works perfectly ?

2.4.3 change the position of listener inside firewall ? Or how authentication is completed.

Comment by Christophe Coevoet [ 12/Jun/14 ]

Doctrine does not register anything in the firewall. Knowing why a PreUpdate event is triggered depends of hwat your app is doing, not of what Doctrine is using. This is not something controlled by Doctrine, so we cannot help you

Comment by Marco Pivetta [ 12/Jun/14 ]

Not in the scope of the project.





[DDC-3162] [GH-1055] Closed php tag in pagination.rst Created: 11/Jun/14  Updated: 11/Jun/14  Resolved: 11/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: Trivial
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 marnusw:

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

Message:

Netbeans complained about the text below the PHP code section since the code block wasn't closed and the text interpreted as PHP.



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

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





[DDC-3161] [GH-1054] SQLFilters enahancements Created: 10/Jun/14  Updated: 10/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 v3labs:

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

Message:

SQL filters in Doctrine are a bit too limited for my taste.
This pull request makes the current connection available inside sql filter classes.
The connection is needed to quote identifiers or values and generate sql statements for the current database. (sample use-case https://github.com/Atlantic18/DoctrineExtensions/blob/master/lib/Gedmo/SoftDeleteable/Filter/SoftDeleteableFilter.php)
Currently you can access the connection only through reflection which let's face it - is a hack.

I've also made the class depend on EntityManagerInterface instead of EntityManager.

There's a test for the new method.






[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-3159] CONCAT expression for PostGreSql Created: 10/Jun/14  Updated: 10/Jun/14

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

Type: Improvement Priority: Minor
Reporter: Maxime Colin Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: concat, dql, postgresql
Environment:

PostGreSQL



 Description   

For PostGreSQL, the CONCAT DQL function is translated in concatenation with || operator (which is the default behavior in AbstractPlatform class).

Is there a particular reason to not use the CONCAT PostGreSQL function instead like in MySqlPlatform ?

I ask this cause the concatenation with || operator return null if one of the part is null, whereas CONCAT function will simply ignore null values.






[DDC-3158] [GH-1053] Fixed new instance creating for php 5.4+ Created: 07/Jun/14  Updated: 12/Jun/14  Resolved: 12/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


 Description   

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

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

Message:



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

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





[DDC-3157] [GH-1052] [DDC-3087] Add readonly attribute to Field ORM Mapping to avoid generating a setter Created: 07/Jun/14  Updated: 07/Jun/14  Resolved: 07/Jun/14

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

Type: New Feature 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 cstea:

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

Message:

The change allows one to enter a field attribute called "readonly". What this does is when using doctrine:generate:entities, only a getter is generated, setter is omitted.

Example use on a created field that uses Timestampable and should not have a setter:
/**

  • @var /DateTime $createdAt
    *
  • @Gedmo\Timestampable(on="create")
  • @ORM\Column(type="datetime", readonly=true)
    */
    private $createdAt;


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

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





[DDC-3156] [GH-1050] DDC-3120 -- Catch ReflectionException for internal classes in ClassMetad... Created: 06/Jun/14  Updated: 06/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 jbottigliero:

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

Message:

...ataInfo

I���m having an issue in relation to http://www.doctrine-project.org/jira/browse/DDC-3120 ��� When using ReflectionClass#newInstanceWithoutConstructor(); I���m getting a ReflectionException due to the class not being internal��� it���s resolveable by adding a try/catch to use ReflectionClass#newInstance. BUT, I���d like to know if there is something else going on here��� running PHP 5.5.13






[DDC-3155] orm:convert-mapping drops underscores from Doctrine type names specified in DB comments Created: 05/Jun/14  Updated: 05/Jun/14

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

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


 Description   

If you run orm:convert-mapping on a schema with comments like (DC2Type:json_array), the type name does get picked up, but the underscore is removed, so the type that ends up in the generated mapping's @Column annotation is jsonarray, not json_array.

The underscore being removed also seems to be affecting the EntityGenerator's attempt to map to correct PHP types for the @var annotation: that's showing up as just @var jsonarray even though the EntityGenerator should be mapping that to array. So it looks like the underscore is probably getting dropped at an earlier stage.






[DDC-3154] Conditions with Value Objects Created: 05/Jun/14  Updated: 05/Jun/14

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

Type: Improvement Priority: Minor
Reporter: Erik A. Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: value-objects


 Description   

I'm quite enthousiastic about Embeddables being added to Doctrine, but it's a pity that true Value Objects, which are compared by their properties, are not supported yet.

Given a Value Object Address with properties street and house number that you can instantiate with new Address("High Street", 1), and a User class that has an Address as Embeddable.

Then, the following is now supported:
DQL1:

SELECT u FROM User u WHERE (u.address.street = :street AND u.address.nr = :number)
    with { 'street' => 'High Street', 'number' => 1 }

Disadvantage: you should know the internal properties when writing your query. That's not how Value Objects usually are compared.

Instead, I expect to be able to do this:
DQL2:

SELECT u FROM User u WHERE (u.address = :address)
    with { 'address' => new Address("High Street", 1)  }

Internally, DQL2 could simply be transformed to the equivalent DQL1 by replacing the condition with conditions for each internal property. The advantage is that the one writing the query does not have to refer to the internal fields; the transformation is hidden.

A complicating factor is that Value Objects are Embeddables, but not every Embeddable is a Value Object. So there is always the question if objects need to be compared by reference or by their properties.

So, perhaps it's an idea to introduce a special operator ~ for comparing objects by their value to make the distinction explicit? Like so:
DQL3:

SELECT u FROM User u WHERE (u.address ~ :address)
    with { 'address' => new Address("High Street", 1)  }.

I created a pull request that contains an idea how the same concept (the ~ operator) might be applied to criterias on in-memory collections.

Just some thoughts and ideas. I'd love to hear some discussion on this as I think it would make Doctrine really powerful in supporting rich, expressive domain models. It would be great if both in-memory collections and DQL supported this!



 Comments   
Comment by Guilherme Blanco [ 05/Jun/14 ]

It should be the same operator, not a new one.
So this is the intended and desired behavior:

SELECT u FROM User u WHERE (u.address = :address)
    with { 'address' => new Address("High Street", 1)  }
Comment by Christophe Coevoet [ 05/Jun/14 ]

This would require to change the DQL to SQL conversion based on the fact that u.address is the path to an embeddable. It might impact performances
Using a separate operator would at least allow to know that it needs a special handling, without having to do complex changes to all places using the = operator.

A complicating factor is that Value Objects are Embeddables, but not every Embeddable is a Value Object. So there is always the question if objects need to be compared by reference or by their properties.

Embeddables cannot be compared by reference. They don't have an identity in the database. The only thing we have to compare them are their properties.

Comment by Erik A. [ 05/Jun/14 ]

True, if we look at the database level, we can only compare by reference. However, if you look beyond ORM and also to the Collections package, then if you want to do a matching on a collection of entities that have an Embeddable by using a Criteria on that Embeddable, then you do have both options (see my referenced pull request). Then two operators might come in handy, so that the additional operator can be introduced to both ORM as well as Collections.

If we would go for one operator (=), then I think the Criteria in Collection also needs to be changed so that it performs a loose comparison on objects and a strict comparison only on scalars. Perhaps that is already out of the scope of the current issue, but either way it would be preferrable to have a consistent solution.

Comment by Christophe Coevoet [ 05/Jun/14 ]

No, saying that we can only compare by reference is wrong. We *cannot* compare by reference (there is no way to reference them).

And talking about the needs of the criteria here is irrelevant, as this discussion is about building the DQL language, not about building the Criteria API. The criteria API can still have a separate operator to deal with value object even if the DQL uses = to compare embeddables. (btw, changing the Criteria comparison to loose on objects would break the comparison of relations, so it is totally impossible as it would be a BC break)

Comment by Guilherme Blanco [ 05/Jun/14 ]

Christophe Coevoet not a performance impact since DQL => SQL is cached.
Adding a new operator resolution requires bigger efforts and I'm pretty sure it'll be slower than converting u.address to multiple clauses (we do it already with composite identifiers).





[DDC-3153] DoctrineObject Hydrator - handleTypeConversion interfers with date strategies Created: 05/Jun/14  Updated: 06/Jun/14  Resolved: 06/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: Ruud Seberechts Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: hydrator


 Description   

We would like to add a strategy for date properties. (So that we have automatic conversion to a \DateTime object after saving a form.)

The DoctrineObject hydrator tries to do this automatically with the handleTypeConversions method, which converts a string in a date property to a \DateTime object. Problem here is that the input format is not always the expected format for this conversion, so an exception is thrown.

We've made a DateTime strategy that converts the value to a \DateTime object with a defined format.

Problem: The handleTypeConversions method is called before the strategy is invoked, thus we get the datetime conversion exception.

Solution: We have overridden the DoctrineObject hydrator for now, and only execute the handleTypeConversions after the strategy:

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
    protected function hydrateByValue(array $data, $object)
    {
        $tryObject = $this->tryConvertArrayToObject($data, $object);
        $metadata  = $this->metadata;

        if (is_object($tryObject)) {
            $object = $tryObject;
        }

        foreach ($data as $field => $value) {
            $setter = 'set' . ucfirst($field);

            if ($metadata->hasAssociation($field)) {
                $target = $metadata->getAssociationTargetClass($field);

                if ($metadata->isSingleValuedAssociation($field)) {
                    if (! method_exists($object, $setter)) {
                        continue;
                    }

                    $value = $this->toOne($target, $this->hydrateValue($field, $value, $data));

                    if (null === $value
                        && !current($metadata->getReflectionClass()->getMethod($setter)->getParameters())->allowsNull()
                    ) {
                        continue;
                    }
                    $object->$setter($value);
                } elseif ($metadata->isCollectionValuedAssociation($field)) {
                    $this->toMany($object, $field, $target, $value);
                }
            } else {
                if (! method_exists($object, $setter)) {
                    continue;
                }
                $value = $this->hydrateValue($field, $value, $data);
                $value = $this->handleTypeConversions($value, $metadata->getTypeOfField($field));
                $object->$setter($value);
            }
        }

        return $object;
    }

I don't know if this is the best solution, but it works for us, anyway.



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

This bug should be reported at https://github.com/doctrine/DoctrineModule, as it doesn't affect the core ORM

Comment by Ruud Seberechts [ 06/Jun/14 ]

Will do, thanks for pointing me in the right direction!





[DDC-3152] Generating methods does not check for existing methods with different case Created: 04/Jun/14  Updated: 06/Jun/14  Resolved: 06/Jun/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.3.4
Fix Version/s: 2.5

Type: Bug Priority: Minor
Reporter: Jacob Walker Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: orm


 Description   

When I use `orm:generate-entities --generate-methods=true` to add methods to an existing entity (such as when I add new properties) the generator will redeclare methods if my existing entity is using different case. This is a fatal error because PHP method names are treated as case insensitive.

I have not tested this in 2.4.

Here is a minimal example entity before running the generator. Not the case of `getID`

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
/**
 * @ORM\Entity
 */
class Employee
{
    /**
     * @ORM\Column(name="id", type="integer", nullable=false)
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    protected $id;

    public function getID()
    {
        return $this->id;
    }
}

And after running the generator

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
/**
 * @ORM\Entity
 */
class Employee
{
    /**
     * @ORM\Column(name="id", type="integer", nullable=false)
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    protected $id;

    public function getID()
    {
        return $this->id;
    }

    /**
     * Get id
     *
     * @return integer 
     */
    public function getId()
    {
        return $this->id;
    }
}


 Comments   
Comment by Steve Müller [ 05/Jun/14 ]

Hmm yeah it seems the EntityGenerator does not use reflection to determine whether a method/property already exists but instead tokenizes the source file and compares the methods/properties case-sensitive.
I will have a look at it.

Comment by Steve Müller [ 05/Jun/14 ]

Patch supplied in PR: https://github.com/doctrine/doctrine2/pull/1049

Comment by Jacob Walker [ 05/Jun/14 ]

Thanks for looking in to this so quickly, Steve.

Comment by Doctrine Bot [ 06/Jun/14 ]

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

Comment by Marco Pivetta [ 06/Jun/14 ]

Merged @ https://github.com/doctrine/doctrine2/commit/d71159c6c57bce5b83f9a2ddbb16ff5a289c30f1





[DDC-3151] [GH-1048] Fix typo in exception message Created: 04/Jun/14  Updated: 06/Jun/14  Resolved: 06/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: 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 MidnightDesign:

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

Message:



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

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

Comment by Marco Pivetta [ 06/Jun/14 ]

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





[DDC-3150] [GH-1047] Minor grammatical corrections Created: 03/Jun/14  Updated: 03/Jun/14  Resolved: 03/Jun/14

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

Type: Improvement Priority: 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 simonharris:

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

Message:

Minor corrections to the annotations reference, for English and clarity.



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

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





[DDC-3149] [GH-1046] Fix the "Erroneous data format for unserializing" error message Created: 03/Jun/14  Updated: 03/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 peterjmit:

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

Message:

Backport patch from PR #1045 to 2.3 branch.

@ocramius - I'm not sure if this is viable, but based on the comments from people it could be helpful to have this fixed in 5.3? I'm not 100% sure whether PHP or Doctrine is at fault here?



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

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





[DDC-3148] ResultSetMappingBuilder::generateSelectClause ignores quoted column names Created: 02/Jun/14  Updated: 02/Jun/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: Christian Ruhstaller Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If an entity has a quoted column (Magic Words etc.) and you want to use "generateSelectClause" for the specific entity it won't return the quoted name, just the plain name. If the name is a SQL Magic Word the corresponding SQL will fail.

Exp.: "profile.real" (wrong) instead of "profile.`real`".

File: Doctrine/ORM/Query/ResultSetMappingBuilder.php
Function: generateSelectClause

Line 445:
$sql .= " AS " . $columnName;

Example Entity:
...
class Profile

{ /** * @ORM\Column(name="`real`", type="boolean") */ protected $real=false; }




[DDC-3147] [GH-1045] Fix the "Erroneous data format for unserializing" error message Created: 30/May/14  Updated: 30/May/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 marmotz:

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

Message:

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



 Comments   
Comment by Doctrine Bot [ 30/May/14 ]

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





[DDC-3146] Hydrator memory leak when using iterator Created: 30/May/14  Updated: 30/May/14

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

Type: Bug Priority: Major
Reporter: Emiel Nijpels Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: hydrator, leak, memory
Environment:

PHP 5.4.21, OS X 10.9.3



 Description   

When the hydrator iterate() function is invoked, a new event is added to the event manager with a reference to the current hydrator object. This reference is never cleared which causes the hydrator object to never be cleared from memory by the PHP garbage collection.

/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php
$evm = $this->_em->getEventManager();
$evm->addEventListener(array(Events::onClear), $this);

The effects of this bug are best visible when creating multiple iterator objects after each other in a repository:

// Loop through test code 10 times
for ($f = 0; $f < 10; $f++) {
    // Create test query
    $query = $this->createQueryBuilder('p')->getQuery();

    // Create IterableResult object
    $iterableResult = $query->iterate();

    // Loop through the iterator
    foreach ($iterableResult as $row) {}

    // Print out memory usage
    print(memory_get_usage() . PHP_EOL);
}

This results in the following output:

10536552
10549920
10563288
10576664
10590040
10603416
10616792
10630168
10643608
10656984

Notice how the used memory increases by about 13KB after each iteration.
To stop this memory leak the following code can be added to the end of the cleanup() function in the AbstractHydrator class:

$evm = $this->_em->getEventManager();
$evm->removeEventListener(array(Events::onClear), $this);

The output is now:

10537920
10537048
10537048
10537048
10537048
10537048
10537048
10537048
10537048
10537048

The reference to the event manager is now automatically removed in the cleanup function which allows the hydrator object to be cleaned up by the garbage collection function in PHP.






[DDC-3145] [GH-1044] Use of ->andWhere() whithout any ->where() before is valid Created: 29/May/14  Updated: 29/May/14  Resolved: 29/May/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 ronanguilloux:

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

Message:

->andWhere() can be used directly, without any ->where() before: we can just always use only ->andWhere(). This is why ->hasWhere() is useless, cf. #1043.



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

Merged: https://github.com/doctrine/doctrine2/commit/5d1275e938145a37df6d700ac2ec0886805b5b79

Comment by Doctrine Bot [ 29/May/14 ]

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





[DDC-3144] [GH-1042] Fix second level cache doc Created: 28/May/14  Updated: 28/May/14  Resolved: 28/May/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 bakura10:

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

Message:



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

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

Comment by Marco Pivetta [ 28/May/14 ]

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





[DDC-3143] [GH-1041] Allow all EntityManagerInterface implementations Created: 28/May/14  Updated: 28/May/14  Resolved: 28/May/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:
Duplicate
is duplicated by DDC-3142 [GH-1040] Entity manager interface Resolved

 Description   

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

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

Message:

Doctrine\ORM\Tools\Event\GenerateSchemaEventArgs requires that the supplied entity manager is an EntityManager instance.

In order to support Doctrine\ORM\Decorator\EntityManagerDecorator, it should allow all EntityManagerInterface implementations.



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

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

Comment by Marco Pivetta [ 28/May/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/5ee286e7e0e1f2364f21d18f725d735ffa5e1870





[DDC-3142] [GH-1040] Entity manager interface Created: 28/May/14  Updated: 28/May/14  Resolved: 28/May/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

Issue Links:
Duplicate
duplicates DDC-3143 [GH-1041] Allow all EntityManagerInte... Resolved

 Description   

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

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

Message:

Doctrine\ORM\Tools\Event\GenerateSchemaEventArgs requires that the supplied entity manager is an EntityManager instance.

In order to support Doctrine\ORM\Decorator\EntityManagerDecorator, it should allow all EntityManagerInterface implementations.



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

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

Comment by Christian Schmidt [ 28/May/14 ]

Sorry, closed the original pull request (against 2.4 branch) and created a new one (against master). Please delete/close this ticket.





[DDC-3141] Change the type of a column Created: 28/May/14  Updated: 28/May/14  Resolved: 28/May/14

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

Type: Improvement Priority: Minor
Reporter: Mathias STRASSER Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: postgresql
Environment:

All O.S.



 Description   

Is that possible to change the request when we would like to change the type of a column in PostgreSQL via Symfony 2 ?

app/console doctrine:schema:update --force

[Doctrine\DBAL\DBALException]
  An exception occurred while executing 'ALTER TABLE foo ALTER valid TYPE BOOLEAN':  

  SQLSTATE[42804]: Datatype mismatch: 7 ERROR:  column "valid" cannot be cast to type boolean

For resolve this problem I must execute manually this command :

ALTER TABLE foo ALTER valid TYPE BOOLEAN USING valid::BOOLEAN;

I've asked this question to DoctrineBundle, but they redirected to you (https://github.com/doctrine/DoctrineBundle/issues/292)



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

Mathias STRASSER does this happen also when data is not in the table?

To be honest, this exception seems valid to me, as it actually prevents you from applying destructive DDL on your schema.

Comment by Steve Müller [ 28/May/14 ]

I tend to agree with Marco Pivetta. I know of similar issues with other vendors, too and IMO this exception is perfectly valid as you would otherwise risk to loose data integrity. How would you expect a database to do data conversion between non-compatible types? Maybe you can force type conversion for some types but I don't think it is the task of DBAL to handle this. You should handle this manually IMO.

Comment by Mathias STRASSER [ 28/May/14 ]

I understand this prevent but I think if a user asked to apply a schema update, it should be applied or he should get prompted for a confirmation.
It think it's a pity we are forced to manually perform this query if we are sure.

What do you think ?

Comment by Steve Müller [ 28/May/14 ]

Mathias STRASSER I understand your concern. But this is an exception coming from the database server. How would you expect Doctrine to do the data conversion? Maybe in your case when converting to a BOOLEAN column, this could somehow work (even at database level). But how would you for example expect Doctrine to convert a STRING column to INTEGER for example. You just can't do that. Also you have to keep in mind that DBAL is an abstraction layer and thus requires a cross-vendor behaviour that is the same for all. It might be that PostgreSQL can force the conversion of any column type to BOOLEAN but other vendors can't do this natively. You could adopt the scenario to PHP and type casting. It's a similar scenario.

Comment by Marco Pivetta [ 28/May/14 ]

Won't be fixed.

As I've previously noted, this is an engine error that simply avoids a lossy conversion.

The conversion should be forced manually by the person running the schema tool (by manually running the dump command and applying the DDL statements)

Comment by Mathias STRASSER [ 28/May/14 ]

I quite understand.

Thanks for your replies.





[DDC-3140] [GH-1039] Add yml example to single table inheritance Created: 27/May/14  Updated: 27/May/14  Resolved: 27/May/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 iampersistent:

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

Message:



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

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

Comment by Marco Pivetta [ 27/May/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/466808bf487ef2b0e760ca96deba55335ebdac5d





[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-3138] [GH-1037] I can't look at those semicolons, sorry ;-) Created: 27/May/14  Updated: 27/May/14  Resolved: 27/May/14

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

Type: Improvement Priority: 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 spiechu:

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

Message:



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

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

Comment by Marco Pivetta [ 27/May/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/20e47ae52d38d78eadf5539399d480cdb6ed88e0





[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-3136] DQL JOIN association return null Created: 24/May/14  Updated: 24/May/14

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

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

Symfony2



 Description   

Hello,
I observe a strange behavior of a query result done by DQL (only tested DQL in fact). In the last entry of my result, the joined entity are returned to null

My tables are:

Entity1
/**
 * @ORM\Table(name="entity1")
 * @ORM\Entity()
**/
class Entity1
{	
	 /**
     * @ORM\Column(name="entity1_id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
	protected $entity1_Id; 
	
	/**
	* @ORM\Column(name="entity1_text", type="string")
	*/
    protected $entity1_Text;
}
Entity2
/**
 * @ORM\Table(name="entity2")
 * @ORM\Entity()
**/
class Entity2
{	
        /**
	* @ORM\OneToOne(targetEntity="Entity1")
	* @ORM\JoinColumn(name="entity1_id", referencedColumnName="entity1_id")
	* @ORM\Id
	*/
	protected $entity1_id; 
    
	/**
	* @ORM\ManyToOne(targetEntity="Entity3")
	* @ORM\JoinColumn(name="entity3_id", referencedColumnName="entity3_id")
	*/
	protected $entity3; 
}
Entity3
/**
 * @ORM\Table(name="entity3")
 * @ORM\Entity()
**/
class Entity3
{	
	 /**
     * @ORM\Column(name="entity3_id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
	protected $entity3_Id; 
	
	/**
	* @ORM\Column(name="entity3_text", type="string")
	*/
    protected $entity3_Text;
}

So when I do a simple request like this:

DQL Request
SELECT ent2, ent3 FROM f4cIndexBundle:Entity2 ent2 JOIN ent2.entity3 ent3

The result is looks like this

Result NOK
array (size=2)
  0 => 
    object(f4c\IndexBundle\Entity\Entity2)[550]
      protected 'entity1_id' => 
        object(Proxies\__CG__\f4c\IndexBundle\Entity\Entity1)[502]
          ...
      protected 'entity3' => 
        object(f4c\IndexBundle\Entity\Entity3)[497]
          protected 'entity3_Id' => int 2
          protected 'entity3_Text' => string 'TEXT OF ENTITY 3 - SPECIFIC 2' (length=29)
  1 => 
    object(f4c\IndexBundle\Entity\Entity2)[498]
      protected 'entity1_id' => 
        object(Proxies\__CG__\f4c\IndexBundle\Entity\Entity1)[499]
          ...
     protected 'entity3' => null

The entity3 of the last result is never joined and set to null (it's not possible because of the JOIN no ?)
I spent to days on this and I observed that when I add a property in my entity 2 like this

Entity2
/**
 * @ORM\Table(name="entity2")
 * @ORM\Entity()
**/
class Entity2
{	
    ...
    /**
	* @ORM\Column(name="entity2_text", type="string")
	*/
    protected $entity2_Text;
}

The result is ok

Result OK
array (size=2)
  0 => 
    object(f4c\IndexBundle\Entity\Entity2)[550]
      protected 'entity1_id' => 
        object(Proxies\__CG__\f4c\IndexBundle\Entity\Entity1)[498]
         ...
      protected 'entity2_Text' => string 'TEXT2' (length=5)
      protected 'entity3' => 
        object(f4c\IndexBundle\Entity\Entity3)[499]
          protected 'entity3_Id' => int 1
          protected 'entity3_Text' => string 'TEXT OF ENTITY 3 - SPECIFIC 1' (length=29)
  1 => 
    object(f4c\IndexBundle\Entity\Entity2)[494]
      protected 'entity1_id' => 
        object(Proxies\__CG__\f4c\IndexBundle\Entity\Entity1)[495]
          ...
      protected 'entity2_Text' => string 'TEXT1' (length=5)
      protected 'entity3' => 
        object(f4c\IndexBundle\Entity\Entity3)[496]
          protected 'entity3_Id' => int 2
          protected 'entity3_Text' => string 'TEXT OF ENTITY 3 - SPECIFIC 2' (length=29)

Is it normal ? Is this a kwon issue ?

Thanks for your help

Raphael P.






[DDC-3135] Unnecessary SELECT after updating of versioned table Created: 23/May/14  Updated: 23/May/14

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

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

PHP 5.5.9-1ubuntu4 (cli) (built: Apr 9 2014 17:11:57)



 Description   

When I update entity with version doctrine generates 2 SQLs:

INSERT INTO TableA (key, value) VALUES (1, 1);
SELECT version FROM TableA WHERE key = 1;

OR

UPDATE TableA SET value= 2, version = version + 1 WHERE key = 1 AND version = 1;
SELECT version FROM TableA WHERE key = 1;

Not only second query is unnecessary (version value is always 1 after persisting and is always prev version + 1 after successful update) but can also read incorrect value if row is updated between update and select statement. In this case entity manager will have outdated data, but most recent version.






[DDC-3134] Inconsistent defaults for onDelete when defining many-to-many relations Created: 23/May/14  Updated: 23/May/14

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

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

Symfony 2.5.0-BETA2



 Description   

When defining a relation with the following annotation:

/**
 * @ORM\ManyToMany(targetEntity="A\B\C")
 */

The following SQL is generated for the foreign key constraints:

ALTER TABLE the_table ADD CONSTRAINT FK_A63A409AA76ED395 FOREIGN KEY (something1) REFERENCES thing2 (id) ON DELETE CASCADE;
ALTER TABLE the_table ADD CONSTRAINT FK_A63A409AF8BD700D FOREIGN KEY (something2) REFERENCES thing1 (id) ON DELETE CASCADE;

As it can be seen, the default seems to be to include ON DELETE CASCADE. This feels like a dangerous behaviour (and I couldn't find it documented), but fair enough. The inconsistency comes when adding:

/**
 * @ORM\ManyToMany(targetEntity="A\B\C")
 * @ORM\JoinTable(name="the_table",
 *      joinColumns={@ORM\JoinColumn()},
 *      inverseJoinColumns={@ORM\JoinColumn()}
 * )
 */

In this case, even if we are not providing any values for the join and inverse join columns, we get:

ALTER TABLE the_table ADD CONSTRAINT FK_A63A409AA76ED395 FOREIGN KEY (something1) REFERENCES something2 (id);
ALTER TABLE user_unit ADD CONSTRAINT FK_A63A409AF8BD700D FOREIGN KEY (something2) REFERENCES something1 (id);

As it can be seen, the ON DELETE CASCADE is gone.

I understand this is the case because, when giving empty JoinColumn annotations it's not the engine defaults that are processed, but the inferred values for the annotation. Still, this seems to be either a bug or an undocumented behaviour.

Am I doing anything wrong here? Should this be looked into?






[DDC-3133] [GH-1036] Move space addition to implementation. Created: 21/May/14  Updated: 21/May/14  Resolved: 21/May/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: entityGenerator


 Description   

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

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

Message:

Currently when get methods are created, extra trailing whitespace is added due to the variableType variable.



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

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

Comment by Marco Pivetta [ 21/May/14 ]

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





[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-3131] [GH-1034] Update caching.rst Created: 19/May/14  Updated: 19/May/14  Resolved: 19/May/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 hashnz:

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

Message:

Remove documentation referencing delete by regex/prefix.



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

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

Comment by Marco Pivetta [ 19/May/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/7debf736a68e8000a272599294ba9da6e7c690b7





[DDC-3130] [GH-1033] [WIP] Lazy criteria for ManyToMany collection Created: 18/May/14  Updated: 18/May/14

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

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


 Description   

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

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

Message:

This continues my previous work on making Criteria most efficient.

Currently we are wrapping matching calls on repositories and matching calls on EXTRA_LAZY associations around a LazyCriteria. However, ManyToMany are still completely loaded: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/PersistentCollection.php#L874

This is still problematic from a performance point of view because count, contains... cannot be optimized. I think the solution is similar to previous one, hence creating a Lazy collection for that kind of associations.

However, this is really tricky to do because of the whole mess inside the persisters (can't wait for them to be completely refactored, it's getting really hard to maintain this mess ).






[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-3128] Convenience methods for count Created: 16/May/14  Updated: 16/May/14  Resolved: 16/May/14

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

Type: New Feature Priority: Minor
Reporter: Flip Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

Would be nice if the EntityRepository class had methods like: countAll() and countBy(). The countBy() method would accept the same arguments as the findBy() method. Just both method would return the count instead of the values



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

The repository API is already too cluttered.

I'd suggest that for 3.x, we may make repositories compatible with collections instead





[DDC-3127] [GH-1031] Documentation for #991 Created: 16/May/14  Updated: 16/May/14  Resolved: 16/May/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 mnapoli:

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

Message:

My bad, I didn't update the documentation in #991 (I was mostly expecting feedback before doing further changes)



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

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

Comment by Marco Pivetta [ 16/May/14 ]

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





[DDC-3126] Repository Classes without Comment @ORM\Table Annotation Exception Created: 15/May/14  Updated: 15/May/14  Resolved: 15/May/14

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

Type: Bug Priority: Minor
Reporter: Brad Mostert Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None
Environment:

doctrine/annotations v1.1.2
doctrine/common v2.4.1
symfony/symfony 2.4.4



 Description   

After running a composer update, repository classes without a block comment before the class definition result in the following exception being thrown under Symfony 2:

"[Semantical Error] The annotation "@ORM\Table" in class Path\To\Bundle\Repository\FooRepository was never imported. Did you maybe forget to add a "use" statement for this annotation?"

Repository classes with any block comment before the class definition are unaffected. Adding a block comment, with any text, prevents the error. The issue is also resolved by adding 'use Doctrine\ORM\Mapping as ORM;' to the repository class files.

Unchanged repository classes worked fine before the composer update

Tested that issue is not related to Symfony's caching.



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

This is related to your environment, not to a doctrine upgrade.

Also, you are using an old ORM version.





[DDC-3125] Better Exception Descriptions / Undefined index Handling Created: 02/May/14  Updated: 06/Jun/14  Resolved: 14/May/14

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

Type: Improvement Priority: Trivial
Reporter: René Patzer Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: None
Environment:

PHP 5.3.10-1, Zend Engine v2.3.0, Xdebug v2.2.2, Composer



 Description   

Some warnings are not very helpful for beginners if the presented text does not state what the Code is trying to accomplish.

Example:

Notice: Undefined index: test in /vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php on line 1753

And followed by another warning:

Warning: Invalid argument supplied for foreach() in vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php on line 1758

Another example:

Notice: Undefined index: unknownField in vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 2611

-> Resulted from a wrong defition:

@ORM\JoinColumn(referencedColumnName="unknownField")

Possible Fix:

Doctrine\ORM\Persisters\BasicEntityParser::getOneToManyStatement
private function getOneToManyStatement(array $assoc, $sourceEntity, $offset = null, $limit = null)
    {
        $criteria = array();
        if ( ! isset($this->class->associationMappings[$assoc['mappedBy']])) {
          throw new MappingException(
            "No associations/mappings defined for " . $assoc['mappedBy'].
            ". Available: " . implode(', ', array_keys($this->class->associationMappings))
          );
        }
...


 Comments   
Comment by René Patzer [ 02/May/14 ]

Possible fix for the warning in the UnitOfWork-Class (Line 2610)

Doctrine\ORM\UnitOfWork::createEntity
if ($joinColumnValue !== null) {
  if ($targetClass->containsForeignIdentifier) {
    $associatedId[$targetClass->getFieldForColumn($targetColumn)] = $joinColumnValue;
  } else {
+  if ( ! isset($targetClass->fieldNames[$targetColumn])) {
+    throw new Exception("Entity ".$targetClass->getName(). ' has no field named '.$targetColumn);
+  }
   $associatedId[$targetClass->fieldNames[$targetColumn]] = $joinColumnValue;
  }
}
Comment by Marco Pivetta [ 02/May/14 ]

Did you validate your metadata mappings first?

Comment by René Patzer [ 05/May/14 ]

php vendor/bin/doctrine orm:validate-schema
[Mapping] FAIL - The entity-class 'Game' mapping is invalid:

  • The referenced column name 'unknownColumn' has to be a primary key column on the target entity class 'Publisher'.

Ah, found my problem: I was using a different bootstrapping (since i tried XML first then switched over to Annotations) for the cli-configuration (config/cli.php) and the XML-Mappings were still valid.

Maybe the exception-message could simply contain a note stating "please run the schema validator [link to documentation]" to help beginners.

Thank you very much for your time.

Comment by René Patzer [ 14/May/14 ]

Found more:

I removed an already existing Entity and then readded it. Calling EntityManager->flush resulted in the following warnings:

Notice: Undefined index: 000000002881c5e0000000006153a26a in /vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 2860

Call Stack:
0.0003 691360 1. main() /test.php:0
0.6119 11843448 2. Doctrine\ORM\EntityManager->flush() /test.php:68
0.6119 11843528 3. Doctrine\ORM\UnitOfWork->commit() /vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:389
0.6499 12226904 4. Doctrine\ORM\Persisters\AbstractCollectionPersister->update() /vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:356
0.6499 12226904 5. Doctrine\ORM\Persisters\AbstractCollectionPersister->deleteRows() /vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/AbstractCollectionPersister.php:131
0.6501 12227544 6. Doctrine\ORM\Persisters\ManyToManyPersister->getDeleteRowSQLParameters() /vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/AbstractCollectionPersister.php:148
0.6501 12227544 7. Doctrine\ORM\Persisters\ManyToManyPersister->collectJoinTableColumnParameters() /vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:69
0.6502 12227936 8. Doctrine\ORM\UnitOfWork->getEntityIdentifier() /vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:136

Warning: array_pop() expects parameter 1 to be array, null given in /vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php on line 147

Call Stack:
0.0003 691360 1. main() /test.php:0
0.6119 11843448 2. Doctrine\ORM\EntityManager->flush() /test.php:68
0.6119 11843528 3. Doctrine\ORM\UnitOfWork->commit() /vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php:389
0.6499 12226904 4. Doctrine\ORM\Persisters\AbstractCollectionPersister->update() /vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:356
0.6499 12226904 5. Doctrine\ORM\Persisters\AbstractCollectionPersister->deleteRows() /vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/AbstractCollectionPersister.php:131
0.6501 12227544 6. Doctrine\ORM\Persisters\ManyToManyPersister->getDeleteRowSQLParameters() /vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/AbstractCollectionPersister.php:148
0.6501 12227544 7. Doctrine\ORM\Persisters\ManyToManyPersister->collectJoinTableColumnParameters() /vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:69
0.6504 12228744 8. array_pop() /vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:147

try {
  $deleteMe= $entityManager->find('de\gamepay\db\Game', 'test_game');
  if ($deleteMe) {
    $entityManager->remove($deleteMe);
    $entityManager->flush();
  }
} catch (Exception $ex) {}

$newGame= new de\gamepay\db\Game();
$newGame->setGameId('test_game');
$newGame->setPublisher($existingPublisher);
$entityManager->persist($newGame);
// The following line results in the warnings. 
$entityManager->flush();
// Still works and surpresses the warnings: @$entityManager->flush();

The game gets added, but i don't know why there are warnings.

Comment by Marco Pivetta [ 14/May/14 ]

These are all validation-related errors.

Doctrine can't register a php error listener (for notices/warnings), as that would affect the global environment, so this cannot be fixed without introducing checks in all the locations where valid metadata was expected.

Comment by René Patzer [ 15/May/14 ]

For the sake of completeness:
orm:validate-schema
[Mapping] OK - The mapping files are correct.

Furthermore the index in the message "Notice: Undefined index: 000000002881c5e0000000006153a26a in /vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 2860" is changing on every run.

All this ticket was about to either suppress these warnings the user can't fix or do checks to prevent the warnings when accessing not existing indexes.
IMHO code that throws warnings at the user he can't really work around is not optimal, particular for beginners like me.

Comment by Marco Pivetta [ 15/May/14 ]

Yes, but we can't build checks into the persisters/hydrators because of performance issues.

As of your failure, the operation you are executing in your example is invalid, as you are trying to register another entity (same identifier) in the same UoW.

Comment by Steve Müller [ 16/May/14 ]

TBH I'm with Marco Pivetta opinion. UoW is a very performance sensitive component and we should not try to catch every edge case just because of invalid usage. Maybe we just need to improve the documentation on this (for your use cases).

Comment by Marco Pivetta [ 16/May/14 ]

Not sure where it is documented (can't find it atm), but I thought it is clear that the UoW works under the assumption that there is only one object per identifier per type in the UoW at any time.

Comment by René Patzer [ 05/Jun/14 ]

Found another one when writing Repository-Classes:

PHP Notice: Undefined index: publisher in [...]/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php on line 415
PHP Stack trace:
{...]
PHP 4. Doctrine\ORM\AbstractQuery->execute() [...]/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php:574
PHP 5. Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll() [...]/vendor/doctrine/orm/lib/Doctrine/ORM/AbstractQuery.php:804
PHP 6. Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateAllData() [...]/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php:140
PHP 7. Doctrine\ORM\Internal\Hydration\ObjectHydrator->hydrateRowData() [...]/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php:179

Schema validation says (since the problem is in the Repository-class):

[Mapping] OK - The mapping files are correct.

I have a many-to-one and a one-to-many relation like in this example:
http://codemonkeys.be/2013/02/example-of-a-doctrine-2-x-many-to-many-association-class/

Thx in advance

Comment by Marco Pivetta [ 06/Jun/14 ]

René Patzer there is no publisher field in the linked example

Comment by René Patzer [ 06/Jun/14 ]

Here is an example:
http://pastebin.com/SN1s2xU8

Testdata is in the class-comment, see the Repository-Class on how to provoke the warning ("Undefined index: id in DoctrineTest/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 2487").

Just to make my point clear and point out why the warning is puzzling for beginners:
I asked myself "why is there an index 'id' missing?" - after debugging around in the code to see what's what i remembered Doctrine is using "id" as the identifier as default if no other name is given (in this example: "p_publisher_id" was missing in the resultset) and it seems to miss a value.

The warning should have contained why it was trying to access that "id"-field (e.g. "tried to get value p_publisher_id or id - neither was found - check your resultset").

hth
Kind regards





[DDC-3124] [GH-1030] DDC-3123 extra updates cleanup Created: 14/May/14  Updated: 14/May/14  Resolved: 14/May/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: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-3123 Extra updates are not cleaned after e... Resolved

 Description   

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

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

Message:

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

Extra updates in the UoW should be cleared immediately.



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

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

Comment by Marco Pivetta [ 14/May/14 ]

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





[DDC-3123] Extra updates are not cleaned after execution Created: 14/May/14  Updated: 14/May/14  Resolved: 14/May/14

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

Type: Bug Priority: Major
Reporter: Yevhen Shyshkin Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-3124 [GH-1030] DDC-3123 extra updates cleanup Resolved

 Description   

Data in UnitOfWork::$extraUpdates are not cleaned after execution of extra updates.

If causes troubles when postFlush event listener does flush, so these extra updates executed two times instead of one.



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

Provided a patch, see DDC-3124 ( https://github.com/doctrine/doctrine2/pull/1030 )

Comment by Doctrine Bot [ 14/May/14 ]

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

Comment by Steve Müller [ 14/May/14 ]

Fixed in commit: https://github.com/doctrine/doctrine2/commit/c16de21172d96c1a42756951b5a8790dd13ca4d1





[DDC-3122] Querying entities with ResolveTargetEntity Created: 14/May/14  Updated: 15/May/14

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

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


 Description   

Hello

The problem refers to a following situation:
You have 2 classes that use a quite simple inheritance and an interface:

interface CInterface { /* ... */ }
class AClass implements CInterface { /* ... */ }
class BClass extends class AClass { /* ... */ }

When we configure the ResolveTargetEntityListener the following way:

array(
  'CInterface' => 'BClass'
)

when using the entity manager to find an entity:

$entityManager->find('BClass', $id);

we'll get a following Doctrine\DBAL\DBALException:

An exception occurred while executing 'SELECT t1.id AS id2 FROM bclass_table_name t1 WHERE t0.id = ?' with params [1]:

SQLSTATE[42S22]: Column not found: 1054 Unknown column 't0.id' in 'where clause'

As you can see the column names are generated properly but the WHERE clause has an invalid refference to t0 table (should be t1).

Similar problem:

http://stackoverflow.com/questions/17588682/doctrine-inheritance-replacement



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

Is AClass a mapped superclass or the root of the inheritance?

Comment by Heo [ 15/May/14 ]

AClass is the root of the inheritance. I would like to add that the only problem is the "find" method. Database relations are created properly (with the SchemaTool), all keys refer to proper columns.

Comment by Marco Pivetta [ 15/May/14 ]

Heo can you abstract a test case for this?





[DDC-3121] I resolved issue on date format with some exotics MSSQL server Created: 12/May/14  Updated: 12/May/14  Resolved: 12/May/14

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

Type: Improvement Priority: Major
Reporter: Gasc Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: dql, orm


 Description   

A good way to resolve date issue on mssql is to use "SET DATEFORMAT" before each query. So I have done a quick and simple fix in our doctrine-dbal>Connection.php to get rid of the issue:

    private function patch_date( &$query ) {
        $driver = print_r($this->getDriver(), true);
        //SI EN MSSQL
        if ( stripos($driver, 'Sqlsrv') > 0 ) {
            $query = 'SET DATEFORMAT ymd;'.$query;
        }
    }

    public function prepare( $statement ) {
        $this->connect();
        $this->patch_date($statement);
        return new Statement($statement, $this);
    }

    public function executeUpdate( $query, array $params = array(), array $types = array() ) {
        $this->connect();
        $this->patch_date($query);

Simple and no need to manage it anymore.
As I work on several MSSQL date formated server: it's very usefull.



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

This should be implemented as a listener like https://github.com/doctrine/dbal/blob/9d6300fd862478f58a526fbcad0a8f630daa60aa/lib/Doctrine/DBAL/Event/Listeners/OracleSessionInit.php

Comment by Steve Müller [ 12/May/14 ]

What exact date issue are you refering to here?

Comment by Gasc [ 12/May/14 ]

Thank you for the listener.
We have usually no issue on MySQL and MSSQL 2008R2, but date setting were different on one 2008R2 of our customer server.
Here is the error message we got:

SQLSTATE[22007]: [Microsoft][SQL Server Native Client 10.0][SQL Server]La conversion d'un type de données nvarchar en type de données datetime a créé une valeur hors limites.

Just to know: We use Symfony for the project (with doctrine "2.1.0"), and without time to rewrite services, so this tiny little patch saved us full of time.

Comment by Marco Pivetta [ 12/May/14 ]

Yep, this is a non-issue for us, as it is a custom environment, as it seems.

That should be solved with a post-connect listener as I've linked above.

Closing as invalid.





[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-3119] [GH-1029] Override joins Created: 07/May/14  Updated: 08/May/14  Resolved: 08/May/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 dskora:

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

Message:

It will eliminate error: INNER JOIN': Error: ... is already defined during creating a sql query.

Scenario:
We have a sorting feature on the page which allows users to order by a most reviewed/customer rating, on the same time we might have a filter by an average rating.



 Comments   
Comment by Doctrine Bot [ 08/May/14 ]

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





[DDC-3118] [GH-1028] Add method getAssociationsByType to ClassMetadata Created: 07/May/14  Updated: 15/May/14  Resolved: 15/May/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: Won't Fix 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/1028

Message:

I propose to add a method which can be used to retrieve the associations of a specific type (OneToOne, ...)



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

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

Comment by Guilherme Blanco [ 15/May/14 ]

Can easily be achieved outside of core





[DDC-3117] [GH-1027] Support for Partial Indexes for PostgreSql and Sqlite Created: 07/May/14  Updated: 16/May/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, postgresql, sqlite

Issue Links:
Dependency
depends on DBAL-900 [GH-600] Support for Partial Indexes ... Open

 Description   

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

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

Message:

Support for Partial Indexes was available in Doctrine 1 following
http://www.doctrine-project.org/jira/browse/DC-82. This commit
reintroduce support for Doctrine 2. We use the same syntax with an
optionnal "where" attribute for Index and UniqueConstraint.

It is unit-tests covered and documented in manual. This Pull Request depends on https://github.com/doctrine/dbal/pull/600. So they should both be merged or rejected together.

Thanks for your time !



 Comments   
Comment by Adrien Crivelli [ 07/May/14 ]

This patch depends on DBAL-900. So they should both be merged or rejected together.

Comment by Doctrine Bot [ 16/May/14 ]

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





[DDC-3115] UnitOfWok can't access proxies protected property Created: 04/May/14  Updated: 04/May/14

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

Type: Bug Priority: Major
Reporter: Machete Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

php5.5.11-1~dotdeb.1
debian 7.5 64bit
apache2
doctrine-orm-module 0.8.0


Attachments: PNG File doctrine-error.PNG    

 Description   

Running the code on different environments for a while now, I have never had any problems. Recently I installed the code onto a different server and I've been experiencing the following issue:

> Fatal error: Cannot access protected property DoctrineORMModule\Proxy_CG_\Page\Entity\PageRevision::$date in src/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 2596

I am absolutely clueless, why this happens. It seems to be affecting only specific data rows, as you might reproduce here: http://de.serlo.org/pages

The field is defined as followed:

    /**
     * @ORM\Column(type="datetime", options={"default"="CURRENT_TIMESTAMP"})
     */
    protected $date;

However, the exact same database snapshot works fine here: http://ptr.serlo.org/pages

Attached you will find a screenshot of the datarows. The yellow ones mark each one working and one not working row.

I have no idea what the problem is here.



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

Discussed this on IRC - very tricky, seems like one of the servers has the reflection property not set to "accessible"

Comment by Machete [ 04/May/14 ]

Adding `$class->reflFields[$field]->setAccessible(true)` before line 2596 resolved this issue. Even after removing it, everything worked fine.

note to self:
> [18:23] <@ocramius> machete_: can you find out where that particular property is instantiated?
> [18:23] <@ocramius> should be in `ClassMetadataInfo::wakeUpReflection()` or such
> [18:25] <@ocramius> if you find that again, consider looking at locations in the code where `new ReflectionClass()` is instantiated





[DDC-3114] [GH-1026] Remove some redundant clauses Created: 02/May/14  Updated: 02/May/14  Resolved: 02/May/14

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

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


 Description   

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

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

Message:

The objectmanager insertion logic was identical in the if and else clauses, so I replaced both occurences with one directly after the else block closes. It is semantically identical but a little more readable, especially since the method has more than 250 lines (and a cyclomatic complexity of 100 or so ) as it is.



 Comments   
Comment by Doctrine Bot [ 02/May/14 ]

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

Comment by Marco Pivetta [ 02/May/14 ]

Merged: https://github.com/doctrine/doctrine2/commit/94837a0105eec91f572ef18dc140779586f931a6





[DDC-3113] Associated entity with "cascade" persist that is eagerly loaded doesn't get saved when its parent is flushed Created: 01/May/14  Updated: 01/May/14

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

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


 Description   

Address entity definition within User class
/**

  • Address
    *
  • @ORM\OneToOne(targetEntity="Address", fetch="EAGER", cascade="persist")
  • @var \Application\Entity\Address
    */
    protected $address;

When User gets loaded via Doctrine, the resulting Address object within the User is not a proxy object but the concrete class specified in targetEntity. When trying to persist the User:

$entityManager->persist($user);
$entityManager->flush($user);

User object gets saved and another associated entity that is lazy loaded does get saved. What doesn't get saved into the database is the Address object. No exceptions are thrown, the Address object is simply ignored.






[DDC-3112] Class Table Inheritance Created: 01/May/14  Updated: 01/May/14

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

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

mysql-5.6.13-winx64, SQL Server 2012, PHP-5.5.4, Windows 7 64 bits professional



 Description   

The documentation on Class Table Inheritance could use some improvements.

1. It's not very clear which classes can have an IDENTITY (auto increment). Consider the example parent: Person, child: Employee. Then add another child: Employer. (this scenario assumes of course that an Employer can never be an Employee). When entering 4 Persons the information in the tables could look like this:
`Parent: (1, Employee), (2, Employee), (3, Employer), (4, Employee) Child Employee: 1,2,4 Child: Employer: 3`
So that means a child can not have an IDENTITY.

Suggestion: specify in docs parent can have IDENTITY, children must not have IDENTITY

2. The parent MUST have an "identifier/primary key" (notice that identifier is not the same as IDENTITY/auto increment). This is not shown in the docs and will throw this:
`Fatal error: Uncaught exception 'Doctrine\ORM\Mapping\MappingException' with message 'No identifier/primary key specified for Entity "MyProject\Model\Person". Every Entity must have an identifier/primary key.'`

Suggestion: specify parent must have identifier/primary key, children primary key will be taken from parent class and must not be specified again in child entity.

3. Is it possible to let a child have it's own identity? And reference the child in the parent table not but the parent's primary key but by a Foreign Key. This blog post here http://blog.liip.ch/archive/2012/03/27/table-inheritance-with-doctrine.html leads me to belief this was once the case (because parent has id and related_id) but perhaps was taken out in later doctrine versions?

Suggestion: specify pros and cons from implementation with FK and without FK (and/or why this changed in history)

4. Show Generated SQL to help understanding. For MySQL:
CREATE TABLE Person (id INT NOT NULL, discr VARCHAR(255) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB
CREATE TABLE Employee (id INT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB
ALTER TABLE Employee ADD CONSTRAINT FK_A4E917F7BF396750 FOREIGN KEY (id) REFERENCES Person (id) ON DELETE CASCADE

For SQL Server:
CREATE TABLE Person (id INT NOT NULL, discr NVARCHAR(255) NOT NULL, PRIMARY KEY (id))
CREATE TABLE Employee (id INT NOT NULL, PRIMARY KEY (id))
ALTER TABLE Employee ADD CONSTRAINT FK_A4E917F7BF396750 FOREIGN KEY (id) REFERENCES Person (id) ON DELETE CASCADE

5. Since the parent forces the identity of the child (through a constraint), a child can not manage it's own identity. Which is important to know if you want to merge already existing data. With the constraint on the primary key the database follows very closely the conceptual model in the PHP classes, but looses flexibility on the database schema implementation level. While this could be resolved with a Foreign Key where then you loose strictness of the database and the responsibility shifts back to the application.






[DDC-3111] [GH-1025] Removed duplicate entry in documentation TOC. Created: 01/May/14  Updated: 01/May/14  Resolved: 01/May/14

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

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


 Description   

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

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

Message:



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

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

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

Fixed in commit: https://github.com/doctrine/doctrine2/commit/7fffba80c304c73b3209cf933803c25dcddf702f





[DDC-3110] paginator doesn't respect order by clause when using the fetchJoinCollection flag Created: 30/Apr/14  Updated: 30/Apr/14

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

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

MariaDB 5.5



 Description   

I have a DQL query with a ORDER BY clause.
When I paginate the result with new Paginator($query, $fetchJoinCollection = true); the orderind isn't correct.
The order is lost in the second request (Perform a Limit Subquery with DISTINCT to find all ids of the entity in from on the current page)

It creates a SQL query like that :
SELECT
DISTINCT id0
FROM
(
SELECT
d0_.id AS id0,
d0_.name AS name1,
d0_.note AS note2,
FROM
data d0_
ORDER BY
d0_.note DESC
) dctrn_result
LIMIT
20 OFFSET 0

The external SELECT don't keep the order so it just fetch the 20 first elements from the whole table.






[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-3108] Criteria cannot reference a joined tables' fields when used with an ORM QueryBuilder Created: 30/Apr/14  Updated: 30/Apr/14

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

Type: Bug Priority: Major
Reporter: Chris Rog Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: criteria, dql, orm, querybuilder


 Description   

This regression was introduced in 2.4.2 with the addition of the "rootAlias" stuff. Basically, the hard-coded addition of the rootAlias + "." prevents any Criteria object from referencing any field that isn't on the first table selected.

Example:
// Assume $repo is a valid EntityRepository and $value is some scalar value.
$qb = $repo->createQueryBuilder('T1')->join('T1.field', 'T2');

$criteria = new Comparison('T2.field2', Comparison::EQ, $value);

$qb->addCriteria($criteria);
$dql = $qb->getDQL();

$dql is now (roughly) equal to:
SELECT T1 FROM <entityclass> T1 JOIN T1.field T2 WHERE T1.T2.field2 = <value>

Evaluating this causes QueryExceptions to be thrown; usually something along the lines of "Expected Doctrine\ORM\Query\Lexer::<token>, got '.'"

There's a similar issue involving ordering by a related field for the same reason.






[DDC-3107] [GH-1024] [Persister] Remove the insertSql cache Created: 30/Apr/14  Updated: 15/May/14  Resolved: 15/May/14

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

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


 Description   

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

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

Message:

Here is a piece of code which leads to an exception if we keep it :
https://gist.github.com/tyx/353de6d6aaf367abd6e6

Sure it is an edge case with tricks but I'm sure Doctrine does not need this kind of optimization.

My 2 cent



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

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

Comment by Guilherme Blanco [ 15/May/14 ]

User is modifying entity metadata to apply non-expected behavior.
Issue marked as invalid.





[DDC-3106] [GH-1023] [DDC-3027] Avoid duplicated mapping using Embedded in MappedSuperclass Created: 30/Apr/14  Updated: 15/May/14  Resolved: 15/May/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: Trivial
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 15/May/14 ]

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





[DDC-3105] Doctrine Console Error (ORMPurger) Created: 29/Apr/14  Updated: 29/Apr/14

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

Type: Bug Priority: Major
Reporter: Carlos Mendoza Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: Cli, schematool


 Description   

In symfony2 the command doctrine:fixtures:load Fails One-To-Many, Self-referencing using Doctrine\Common\DataFixtures\Purger\ORMPurger in example:

class DescriptionArea

{ //.. /** * @ORM\OneToMany(targetEntity="DescriptionArea", mappedBy="parent") */ protected $descriptionAreas; /** * @ORM\ManyToOne(targetEntity="DescriptionArea", inversedBy="descriptionAreas") */ protected $parent; //.. }

Throw error:
[Doctrine\DBAL\DBALException]

An exception occurred while executing 'DELETE FROM prefix_DescriptionArea':

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (sigtec_dev.prefix_DescriptionArea,

CONSTRAINT FK_7265873E727ACA70 FOREIGN KEY (parent_id) REFERENCES prefix_DescriptionArea (id))

Before running the query should delete the index when the table has self-reference.






[DDC-3104] Invalid count on EXTRA LAZY collection of SINGLE TABLE entities Created: 28/Apr/14  Updated: 20/May/14

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

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

Issue Links:
Reference
relates to DDC-1595 Wrong count in relation with inheritance Resolved

 Description   
  • This issue relates to http://www.doctrine-project.org/jira/browse/DDC-1595
  • With the following entities
    • EntityPromotionAbstract entity:
      * @ORM\Entity
       * @ORM\InheritanceType("SINGLE_TABLE")
       * @ORM\Table(name="entity_promotion")
       * @ORM\DiscriminatorColumn(name="type", type="string")
       * @ORM\DiscriminatorMap({
       *     "brand"           = "BrandPromotion",
       *     "category"        = "CategoryPromotion",
       * })
       */
      abstract class EntityPromotionAbstract
      
    • CategoryPromotion entity:
       * @ORM\Entity
       */
      class CategoryPromotion extends EntityPromotionAbstract
      {
          /**
           * Category
           *
           * @var Category
           * @ORM\ManyToOne(targetEntity="Category", inversedBy="CategoryPromotions")
           * @ORM\JoinColumn(name="instance_id", referencedColumnName="category_id")
           */
          protected $Category;
      ...
      }
      
    • BrandPromotion entity:
       * @ORM\Entity
       */
      class BrandPromotion extends EntityPromotionAbstract
      {
          /**
           * Brand
           *
           * @var Brand
           * @ORM\ManyToOne(targetEntity="Brand", inversedBy="BrandPromotions")
           * @ORM\JoinColumn(name="instance_id", referencedColumnName="brand_id")
           */
          protected $Brand;
      }
      
    • Brand entity:
          /**
           * Associated BrandPromotions
           *
           * @var \Doctrine\Common\Collections\Collection
           *
           * @ORM\OneToMany(targetEntity="BrandPromotion", mappedBy="Brand", fetch="EXTRA_LAZY")
           */
          protected $BrandPromotions;
      
    • Category entity:
          /**
           * Associated CategoryPromotions
           *
           * @var \Doctrine\Common\Collections\ArrayCollection|\Doctrine\ORM\PersistentCollection
           *
           * @ORM\OneToMany(targetEntity="CategoryPromotion", mappedBy="Category", fetch="EXTRA_LAZY")
           */
          protected $CategoryPromotions;
      
  • When Brand::BrandPromotions collection is not initialized, calling count on it will return a count of BrandPromotion and CategoryPromotion elements, but calling isEmpty will return a count of BrandPromotion entities only.
  • \Doctrine\ORM\Persisters\OneToManyPersister::count does not take into account a discriminator value of 'brand':
            foreach ($targetClass->associationMappings[$mapping['mappedBy']]['joinColumns'] as $joinColumn) {
                $whereClauses[] = $joinColumn['name'] . ' = ?';
    
                $params[] = ($targetClass->containsForeignIdentifier)
                    ? $id[$sourceClass->getFieldForColumn($joinColumn['referencedColumnName'])]
                    : $id[$sourceClass->fieldNames[$joinColumn['referencedColumnName']]];
            }
    
    
  • This results in a query:
    SELECT count(*) FROM entity_promotion t WHERE instance_id = ?
    
  • The query should include a type condition:
    SELECT count(*) FROM entity_promotion t WHERE instance_id = ? AND (t.type in 'brand')