[DDC-2505] [GH-697] Fix phpDoc syntax in ClassMetadataInfo.php Created: 14/Jun/13  Updated: 19/Oct/14  Resolved: 25/Jun/13

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

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

Message:



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3268] [GH-1118] Use the new Docker queue on Travis Created: 22/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: ci, docker, travis


 Description   

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

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

Message:

faster better stronger

let's see how it copes with this test suite



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

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





[DDC-3234] Empty properties when filtering collections Created: 30/Jul/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Diogo Domanski de Souza Assignee: Marco Pivetta
Resolution: Cannot Reproduce Votes: 0
Labels: Collection, Criteria, orm
Environment:

PHP 5.5.9, Nginx 1.4.6, PHP FPM, Zend Framework 2.3.1, Linux Ubuntu 14.04



 Description   

I'm facing some troubles when filtering an entity association (ArrayCollection) by using Criteria.

The scenario is the following: I have 3 entities:

User.php
<?php

namespace Entity;

use Doctrine\ORM\Mapping as ORM;
use \Doctrine\Common\Collections\Criteria;
use Zend\Stdlib\Hydrator;

/**
 * User
 *
 * @ORM\Table(name="user")
 * @ORM\Entity(repositoryClass="Entity\UserRepository")
 * @ORM\HasLifecycleCallbacks
 * @author domanski
 */
class User implements \Serializable {
	/**
	 *
	 * @ORM\Id
	 * @ORM\Column(name="id", type="integer", nullable=false)
	 * @ORM\GeneratedValue(strategy="AUTO")
	 * @var integer
	 */
	private $id;

	/**
	 * @ORM\Column(name="delete_date", type="datetime")
	 * @var \DateTime
	 */
	private $deleteDate;
	
	public function __construct(array $options = array()) {
		if (!empty($options))
			$this->hydrate($options);
	}

	public function hydrate(array $options = array(), \Doctrine\ORM\EntityManager $em = null) {
		$hydrator = new Hydrator\ClassMethods();
		$hydrator->hydrate($options, $this);
	}

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

	/**
	 * 
	 * @param int $id
	 * @return \Entity\User
	 */
	public function setId($id) {
		$this->id = $id;
		return $this;
	}

	/**
	 * 
	 * @return \DateTime
	 */
	public function getDeleteDate() {
		return $this->deleteDate;
	}

	/**
	 * @param \DateTime|null $deleteDate
	 * @return \Entity\User
	 */
	public function setDeleteDate($deleteDate = null) {
		$this->deleteDate = $deleteDate;
		return $this;
	}

	/**
	 * 
	 * @return array
	 */
	public function toArray() {
		$result = array(
			'id' => $this->getId(),
			'delete_date' => $this->getDeleteDate()
		);

		return $result;
	}

}
FieldWorker.php
<?php

namespace Entity;

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

use Zend\Stdlib\Hydrator;

/**
 * Description of FieldWorker
 *
 * @ORM\Entity(repositoryClass="Entity\FieldWorkerRepository")
 * @ORM\Table(name="field_worker")
 * @ORM\HasLifecycleCallbacks
 * @author domanski
 */
class FieldWorker {
	
	/**
	 * This attribute must exist so the inverse join with any other entity can work
	 * 
	 * @ORM\Id
	 * @ORM\Column(type="integer", name="user_id")
	 * @var string
	 */
	protected $id;
	
	/**
	 * 
	 * @ORM\OneToOne(targetEntity="Entity\User")
	 * @ORM\JoinColumn(name="user_id", referencedColumnName="id")
	 * @var \Entity\User
	 */
	protected $user;
	
	public function __construct($options = array()) {		
		if(!empty($options))
			$this->hydrate($options);
	}
	
	public function hydrate(array $options = array(), \Doctrine\ORM\EntityManager $em = null) {
		if(!empty($em)) {
			// user
			if(isset($options['user']))
				$options['user'] = $em->getReference('Entity\User', $options['user']);
			else if(isset($options['user_id']))
				$options['user'] = $em->getReference('Entity\User', $options['user_id']);
						
		}
		
		$hydrator = new Hydrator\ClassMethods();
		$hydrator->hydrate($options, $this);
	}

	/**
	 * 
	 * @return \Entity\User
	 */
	public function getUser() {
		return $this->user;
	}

	/**
	 * 
	 * @param \Entity\User $user
	 * @return \Entity\FieldWorker
	 */
	public function setUser(\Entity\User $user) {
		$this->user = $user;
		$this->id = $user->getId();
		return $this;
	}
	
	/**
	 * 
	 * @return array
	 */
	public function toArray() {
		return $this->getUser()->toArray();
	}
}
Stage.php
<?php

namespace Obra\Entity;

use Doctrine\ORM\Mapping as ORM;
use Zend\Stdlib\Hydrator;
use Doctrine\Common\Collections\Criteria;

/**
 * Description of Stage
 *
 * @ORM\Table(name="stage")
 * @ORM\Entity(repositoryClass="Entity\StageRepository")
 * @ORM\HasLifecycleCallbacks
 * @author domanski
 */
class Stage {

	/**
	 *
	 * @ORM\Id
	 * @ORM\Column(name="id", type="integer", nullable=false)
	 * @ORM\GeneratedValue(strategy="AUTO")
	 * @var integer
	 */
	private $id;

	/**
	 * @ORM\ManyToMany(targetEntity="Entity\FieldWorker")
	 * @ORM\JoinTable(name="stage_field_worker",
	 * 		joinColumns={@ORM\JoinColumn(name="stage_id", referencedColumnName="id")},
	 * 		inverseJoinColumns={@ORM\JoinColumn(name="field_worker_id", referencedColumnName="user_id")}
	 * 	)
	 * @var \Doctrine\Common\Collections\ArrayCollection
	 */
	private $fieldWorkers;

	public function __construct(array $options = array()) {
		$this->fieldWorkers = new \Doctrine\Common\Collections\ArrayCollection();

		if (!empty($options))
			$this->hydrate($options);
	}

	public function hydrate(array $options = array(), \Doctrine\ORM\EntityManager $em = null) {
		$hydrator = new Hydrator\ClassMethods();
		$hydrator->hydrate($options, $this);
	}

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

	/**
	 * 
	 * @param int $id
	 * @return \Entity\Stage
	 */
	public function setId($id) {
		$this->id = $id;
		return $this;
	}

	/**
	 * 
	 * @return \Doctrine\Common\Collections\ArrayCollection
	 */
	public function getFieldWorkers() {
		$criteria = Criteria::create()
				->where(Criteria::expr()->isNull("user.deleteDate"))
				->orderBy(array("user.name" => Criteria::ASC));

		return $this->fieldWorkers->matching($criteria);
	}

	/**
	 * 
	 * @return \Entity\Stage
	 */
	public function clearFieldWorkers() {
		$this->fieldWorkers->clear();
		return $this;
	}

	/**
	 * 
	 * @param \Entity\FieldWorker $fieldWorker
	 * @return \Entity\Stage
	 */
	public function addFiscal(\Entity\FieldWorker $fieldWorker) {
		$this->fieldWorkers->add($fieldWorker);
		return $this;
	}

	/**
	 * 
	 * @return array
	 */
	public function toArray() {
		$result = array(
			"id" => $this->getId(),
			"field_workers" => array()
		);

		foreach ($this->getFieldWorkers() as $fieldWorker) {
			$result['field_workers'][] = $fieldWorker->toArray();
		}

		return $result;
	}
}

The problem is that whenever the Stage::getFieldWorkers() method is invoked, the list of associated field workers is returned correctly, however if I try to retrieve the respective user of any field worker, it is NULL.

For example:

$stageEntity = $em->getRerefence('Entity\Stage', 1);
$fieldWorkers = $stageEntity->getFieldWorkers();

foreach($fieldWorkers as $fieldWorker) {
   $userId = $fieldWorker->getUser()->getId(); // This throws an error message saying that the result of getUser() is NULL
}

Another example would be if I try to call $stageEntity->toArray() (because it does the same thing as show above).

The database tables are as following:

Database tables creation
CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `delete_date` datetime DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

CREATE TABLE `field_worker` (
  `user_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`user_id`),
  CONSTRAINT `fk_field_worker_user1` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE `stage` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


CREATE TABLE `stage_field_worker` (
  `stage_id` int(10) unsigned NOT NULL,
  `field_worker_id` int(10) unsigned NOT NULL,
  PRIMARY KEY (`stage_id`,`field_worker_id`),
  KEY `fk_stage_field_worker_stage_idx` (`stage_id`),
  KEY `fk_stage_field_worker_field_worker_idx` (`field_worker_id`),
  CONSTRAINT `fk_stage_field_worker_field_worker` FOREIGN KEY (`field_worker_id`) REFERENCES `field_worker` (`user_id`) ON DELETE CASCADE ON UPDATE CASCADE,
  CONSTRAINT `fk_stage_field_worker_stage` FOREIGN KEY (`stage_id`) REFERENCES `stage` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `user` SET `id` = 1;
INSERT INTO `field_worker` SET `user_id` = 1;
INSERT INTO `stage` SET `id` = 1;
INSERT INTO `stage_field_worker` SET `stage_id` = 1, `field_worker_id` = 1;

After hours trying to understand what was wrong, I decided to make a test and modify the Stage::getFieldWorkers() method by removing the filtering Criteria:

public function getFieldWorkers() {
    return $this->fieldWorkers;
}

By simply doing that, the getUser() method started to return an entity of type User (as expected).

I am not a Doctrine ORM expert, but there seems to be something wrong with ArrayCollection filtering (matching() method)



 Comments   
Comment by Diogo Domanski de Souza [ 30/Jul/14 ]

The same problem occurs with QueryBuilder. For example:

StageRepository.php
<?php

namespace Entity;

use Doctrine\ORM\EntityRepository;

/**
 * Description of StageRepository
 *
 * @author domanski
 */
class StageRepository extends EntityRepository 
{

	public function findByFieldWorkerId($fieldWorkerId) {
		$qb = $this->getEntityManager()->createQueryBuilder()
			->select('s')
			->from('Entity\Stage', 's')
			->innerJoin('s.fieldWorkers', 'f')
			->innerJoin('f.user', 'u', \Doctrine\ORM\Query\Expr\Join::WITH, "u.deleteDate IS NULL AND u.id = :field_worker_id")
				->setParameter('field_worker_id', $fieldWorkerId);

		return $qb->getQuery()->getResult();
	 }
}

If I try to iterate over the result of StageRepository::findByFieldWorkerId() and call toArray() of any element, I get the same error. I've even tried to remove the inner join with User entity from query:

	public function findByFieldWorkerId($fieldWorkerId) {
		$qb = $this->getEntityManager()->createQueryBuilder()
			->select('s')
			->from('Entity\Stage', 's')
			->innerJoin('s.fieldWorkers', 'f');

		return $qb->getQuery()->getResult();
	 }
Comment by Marco Pivetta [ 30/Jul/14 ]

I suspect that something is wrong in your mappings then...

Comment by Diogo Domanski de Souza [ 31/Jul/14 ]

Hi Marco,

The mappings are shown above. The only thing I did was to omit some entities/tables properties/columns that don't have to see with the associations - except the field worker (table and Entity) and stage_field_worker table, that are fully presented.

Maybe is important to notice that the field_worker table has only one column (user_id) that is primary key and foreign key (referencing user.id).

Thanks for you support

Comment by Marco Pivetta [ 31/Jul/14 ]

Diogo Domanski de Souza we can't debug this as it is. We'd need a functional test case to be added to https://github.com/doctrine/doctrine2/tree/0650bb954f5e8d05776f99abd04c81948413299f/tests/Doctrine/Tests/ORM/Functional/Ticket first, in order to see the failure

Comment by Diogo Domanski de Souza [ 31/Jul/14 ]

Marco Pivetta is there any documentation (tutorial, instructions, guide, etc) that I can use to learn how to write the functional test cases that I need?

Comment by Marco Pivetta [ 31/Jul/14 ]

Diogo Domanski de Souza you need to look at the existing ones.

For running the test suite:

git clone git@github.com:doctrine/doctrine2.git
cd doctrine2 
curl -s https://getcomposer.org/installer | php --
./composer.phar install
./vendor/bin/phpunit
Comment by Diogo Domanski de Souza [ 20/Aug/14 ]

I solved the problem by removing the property $id from FieldWorker entity and add annotation @ORM\Id to $user property (in this same entity).

I didn't understand why the previous definition of FieldWorker entity was not working. I have another similar relationship scenario, between 3 different entities, and the error does not occur.

Thanks to all for the support





[DDC-2277] [GH-570] Deprecation of PEAR/GIT/TAR autoloading Created: 04/Feb/13  Updated: 19/Oct/14  Resolved: 14/Feb/13

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

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


 Description   

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

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

Message:

Updates the test suite to use composer based autoloading



 Comments   
Comment by Benjamin Eberlei [ 14/Feb/13 ]

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

Comment by Marco Pivetta [ 14/Feb/13 ]

Merged

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2701] Collections in originalEntityData gets over written Created: 23/Sep/13  Updated: 19/Oct/14  Resolved: 19/Oct/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: Thomas Klein Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

I was trying to use the UnitOfWork::getOriginalEntityData method and i noticed that if there is a collection in that object, it changes in the uow original datas when i change it on my original object

In my case the collection is ManyToMany unidirectional

I think this happens because both the uow and the object work with the same reference to the collection
maybe adding a clone of the collection instead of the real one, i don't know if it is possible

Thank you for taking a look and for Doctrine!

Tom



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

This issue needs a test case in order to be reproduced.

Comment by Thomas Klein [ 20/Aug/14 ]

Here is how i get to this bug:

2 entities with a many to many unidirectional relation:

class Conversation
{
    // ...........

    /**
     * @ORM\ManyToMany(targetEntity="User")
     * @ORM\JoinTable(name="Conversations_To_Users",
     *      joinColumns={@ORM\JoinColumn(name="conversation_id", referencedColumnName="id")},
     *      inverseJoinColumns={@ORM\JoinColumn(name="user_id", referencedColumnName="id")}
     * )
     *
     * @var ArrayCollection
     */
    private $users;

    public function getUsers()
    {
        return $this->users();
    }

    // .....
}

class User
{
    // .....
}

Load the Conversation entity joined with the associated users: you get a Conversation entity with the users property filled with a PersistentCollection initialized. You can find this object in the originalEntityData property of the unit of work.

Then do:

$users = $conversation->getUsers();
$users->remove(0);

In the conversation object, the first user of the collection has been removed. In the unit of work, find the corresponding object in the originalEntityData array and you'll see that the first user has been removed from the collection too. It is then not possible to use the originalEntityData on joined collection to check for changes

Comment by Marco Pivetta [ 20/Aug/14 ]

Thomas Klein still not sure what the problem is:

$user         = new User();
$conversation = new Conversation();

$conversation->addUser($user);

$em->persist($user);
$em->persist($conversation);
$em->flush();
$em->clear();

$conversation1   = $em->find('Conversation', $conversation->id);
$usersCollection = $conversation->getUsers();

$usersCollection->remove(0);

var_dump($em->getUnitOfWork()->getOriginalEntityData($conversation1));

// what is failing after this point?

This is also how a test case should look like when thrown at the ORM functional test suite: https://github.com/doctrine/doctrine2/tree/v2.4.4/tests/Doctrine/Tests/ORM/Functional/Ticket

Comment by Thomas Klein [ 20/Aug/14 ]

Sorry i'll try to write a real test case asap ...

What is failing after this point ?

$origConversationData = $em->getUnitOfWork()->getOriginalEntityData($conversation1);
var_dump(count($origConversationData['users'])); // should be equal to 1, i get 0 ...

The only diff i can see with your example is that i'm not using find but a query with the relation fetched-joined in it so the collection is initialized

Comment by Marco Pivetta [ 20/Aug/14 ]

Collections are not tracked within entity data, but separately in the UoW

Comment by Thomas Klein [ 20/Aug/14 ]

Ok so i guess we can close this ticket if this is an expected behavior ...

In your last comment, did you mean:
Collections are not tracked within entity data, but each element of the collection is tracked separately in the UoW ?

Anyway thanks for your help

Comment by Marco Pivetta [ 19/Oct/14 ]

I mean that collections are tracked by specific properties/states in the UoW: https://github.com/doctrine/doctrine2/blob/9bf8f6ed4cc6590def5b5e8ba739ecdfa62fb717/lib/Doctrine/ORM/UnitOfWork.php#L180-L192

Yes, collection items are still single entities tracked in the UoW





[DDC-3263] setFetchmode for ClassMetaData temorarily instead of Query Created: 21/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Andreas Dyballa Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

SetFetchmode is now woriking in AbstractQuery.

Why dont implement setFetchMode and perhaps further temporarily changes in an ClassMetadata-managing Object. Perhaps to work with a temporarily copy to allow a reset after some action.



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

Contextual changes in the entire UoW can lead to hard to predict situation that we don't want nor need to implement, as they represent additional complexity.





[DDC-3261] Bad link in 34.3 Advanced Configuration - Connection Options Created: 20/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Documentation Priority: Minor
Reporter: Matthew Turland Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: documentation, orm


 Description   

The link to the DBAL section from 34.3 Advanced Configuration - Connection Options results in a 404 HTTP response. This line appears to be responsible.

Link URL as it appears in the current documentation:
http://docs.doctrine-project.org/dbal/2.0/docs/reference/configuration/en






[DDC-3264] setFetchMode Signature and Documentation Created: 21/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Andreas Dyballa Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

The signature in AbstractQuery should be boolean for fetchmode and the documentation on
http://docs.doctrine-project.org/en/2.1/reference/dql-doctrine-query-language.html
setFetchMode(...,"EAGER"); is not according to the signature.
This is confusing.



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

2.2 is a very old version of the ORM which we don't support anymore. The new documentation is at http://docs.doctrine-project.org/en/latest/reference/dql-doctrine-query-language.html





[DDC-2445] [GH-665] oo Add Null in ScalarExpression Created: 12/May/13  Updated: 19/Oct/14  Resolved: 26/May/13

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

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


 Description   

This issue is created automatically through a Github pull request on behalf of vahid-sohrabloo:

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

Message:



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

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

Comment by Doctrine Bot [ 11/Sep/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2356] [GH-619] [DDC-2090] Fix MultiTableUpdateExecutor with query cache Created: 17/Mar/13  Updated: 19/Oct/14  Resolved: 17/Mar/13

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

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


 Description   

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

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

Message:

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



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

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

Comment by Fabio B. Silva [ 17/Mar/13 ]

Merged : https://github.com/doctrine/doctrine2/commit/60b8bc63a1a4819cf112cfbbc7cca06b5792aba6

Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2446] [GH-666] [DDC-2429] Fix xsd definition Created: 13/May/13  Updated: 19/Oct/14  Resolved: 26/May/13

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

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


 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 21/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3304] [EntityGenerator] Embeddables properties and methods are broken Created: 11/Sep/14  Updated: 19/Oct/14  Resolved: 12/Sep/14

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

Type: Improvement Priority: Major
Reporter: Phansys Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: embeddables, entityGenerator, generation, mapping, orm

Issue Links:
Dependency
depends on DDC-3307 [GH-1135] [DDC-3304] Add support for ... Resolved

 Description   

EntityGenerator creates broken properties for embeddables. Given the example classes exposed in http://docs.doctrine-project.org/en/latest/tutorials/embeddables.html (User, Address), EntityGenerator creates wrong associations in User entity. Instead of this:

```php
/**

  • Address
    *
  • @var Address
    */
    private $address;
    ```

I get this:
```php
/**

  • Address.street
    *
  • @var string
    */
    private $address.street;
    /**
  • Address.postalCode
    *
  • @var string
    */
    private $address.postalCode;
    /**
  • Address.city
    *
  • @var string
    */
    private $address.city;
    /**
  • Address.country
    *
  • @var string
    */
    private $address.country;
    ```

And the same for its getters and setters.
I'll try to do a PR when I found a way to solve this.



 Comments   
Comment by Steve Müller [ 11/Sep/14 ]

Phansys which version of ORM are you using? If you are using latest master, this might be related to PR: https://github.com/doctrine/doctrine2/pull/1105
It looks like it broke the EntityGenerator. Can you confirm?

Comment by Phansys [ 11/Sep/14 ]

Confirmed @deeky666, on rev d9b43dc6492b163fc46f40c0555e2a7015ef5b68 (https://github.com/doctrine/doctrine2/tree/d9b43dc6492b163fc46f40c0555e2a7015ef5b68).
Thank you!

Comment by Phansys [ 11/Sep/14 ]

I've tried with rev 8a3def097f9ebd773ee298f5611ce8bf7007fa7e (previous to PR#1105) and the result is the same broken structure.

Comment by Steve Müller [ 11/Sep/14 ]

Phansys thanks for your feedback. I will see if I have time tomorrow to look into this issue.

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

Had a quick look into the issue and recognized that embeddables are not taken into account at all at the moment. Working on a solution...

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

Patch provided in PR: https://github.com/doctrine/doctrine2/pull/1135

Comment by Doctrine Bot [ 12/Sep/14 ]

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

Comment by Doctrine Bot [ 12/Sep/14 ]

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

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

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

Comment by Phansys [ 13/Sep/14 ]

Thanks Steve Müller.

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3249] [GH-1105] Add support for nesting embeddables Created: 11/Aug/14  Updated: 19/Oct/14  Resolved: 22/Aug/14

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

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


 Description   

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

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

Message:

This is a possible approach towards adding support for nesting embeddables (embeddables inside embeddables). I'm not sure whether this implementation is the best solution but I think it is something to start with. It seems to work flawlessly so far but I'm not sure if I missed something, so any feedback is welcome



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

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

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

Fixed in commit: https://github.com/doctrine/doctrine2/commit/400acad53355f24137e18d5cd55ccf6ff828cfbe

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3357] [GH-1165] [DDC-3205] #1120 - metadata info command Created: 19/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/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: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-3269 [GH-1120] [DDC-3205] Metadata info Open
duplicates DDC-3205 [DX] Interactive Management Command Open

 Description   

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

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

Message:

Supersedes #1120 - see DDC-3205 (http://www.doctrine-project.org/jira/browse/DDC-3205)



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3269] [GH-1120] [DDC-3205] Metadata info Created: 23/Aug/14  Updated: 19/Oct/14

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

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

Issue Links:
Duplicate
is duplicated by DDC-3357 [GH-1165] [DDC-3205] #1120 - metadata... Resolved

 Description   

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

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

Message:

This PR adds support for showing the metadata for a single entity to the `orm:info` command.

  • The output is formatted using the `TableHelper` if it is available (Symfony 2.4+). If the TableHelper is not available
    it will format simply with `field: value`.
  • Partial regex matches are accepted, e.g. `mapping:info Attraction`, `mapping:info Attraction.*`

E.g.:

````bash
$ php app/console doctrine:mapping:info "Sulu\Bundle\ContactBundle\Entity\Count"
----------------------------------------------------------------------------------------------------------------------------+

Field Value

----------------------------------------------------------------------------------------------------------------------------+

Name Sulu\Bundle\TagBundle\Entity\Tag
Root entity name Sulu\Bundle\TagBundle\Entity\Tag
Custom generator definition None
Custom repository class Sulu\Bundle\TagBundle\Entity\TagRepository
Mapped super class? Empty
Embedded class? Empty
Parent classes Empty
Sub classes Empty
Embedded classes Empty
Named queries Empty
Named native queries Empty
SQL result set mappings Empty
Identifier ["id"]
Inheritance type 1
Discriminator column None
Discriminator value None
Discriminator map Empty
Generator type 4
Table {"name":"ta_tags"}
Composite identifier? Empty
Foreign identifier? Empty
Sequence generator definition None
Table generator definition None
Change tracking policy 1
Versioned? None
Version field None
Read only? Empty
Entity listeners Empty
Association mappings:  
creator  
fieldName creator
targetEntity Sulu\Bundle\SecurityBundle\Entity\User
joinColumns [{"name":"idUsersCreator","referencedColumnName":"id","nullable":true,"onDelete":"SET NULL"}]
type 2
mappedBy Null
inversedBy Null
isOwningSide 1
sourceEntity Sulu\Bundle\TagBundle\Entity\Tag
fetch 2
cascade Empty
isCascadeRemove Empty
isCascadePersist Empty
isCascadeRefresh Empty
isCascadeMerge Empty
isCascadeDetach Empty
sourceToTargetKeyColumns {"idUsersCreator":"id"}
joinColumnFieldNames {"idUsersCreator":"idUsersCreator"}
targetToSourceKeyColumns {"id":"idUsersCreator"}
orphanRemoval Empty
Field mappings:  
name  
fieldName name
type string
columnName name
unique 1
created  
fieldName created
type datetime
columnName created

----------------------------------------------------------------------------------------------------------------------------+



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3205] [DX] Interactive Management Command Created: 05/Jul/14  Updated: 19/Oct/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

Issue Links:
Duplicate
is duplicated by DDC-3357 [GH-1165] [DDC-3205] #1120 - metadata... Resolved

 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-2279] [GH-571] Update lib/Doctrine/ORM/EntityRepository.php Created: 05/Feb/13  Updated: 19/Oct/14  Resolved: 12/Mar/13

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

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

Issue Links:
Reference
relates to DBAL-947 [GH-634] Transaction object definition Open

 Description   

This issue is created automatically through a Github pull request on behalf of flo-ITN:

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

Message:

Add "indexby" missing parameter that permit an "index by" easily.

Ex :��
#Acme\AcmeBundle\Repository
#Before
public function findAllIndexById()

{ �� �� $qb = $this->_em->createQueryBuilder() �� �� �� �� �� �� �� �� �� �� ->select('root') �� �� �� �� �� �� �� �� �� �� ->from('Acme', 'root', 'root.id'); �� �� /*...*/ }

#After
public function findAllIndexById()

{ �� �� $qb = $this->createQueryBuilder('root','root.id'); �� ����/*...*/ }

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

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





[DDC-3270] abstract class database entity generation Created: 23/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Minor
Reporter: Yan Ni Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: mysql, orm
Environment:

WAMP symfony2



 Description   

I create an abstract class A using @ORM annotations, then create class B which is a subclass of class A. When I use these to update the mysql database, however, a table for class A was also generated, which shouldn't have happened(because class A is an abstract class).



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

abstract types in the ORM are called MappedSuperclass}}es. The fact that a class is {{abstract doesn't mean that it has no concrete table representing it.





[DDC-3273] EntityGenerator writes @ORM\Table annotation for mapped superclass Created: 26/Aug/14  Updated: 19/Oct/14

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

Type: Bug Priority: Minor
Reporter: Jakab Adam Balazs Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: generation, orm, tools
Environment:

not relevant



 Description   

file /doctrine/orm/lib/Doctrine/ORM/Tools/EntityGenerator.php method: generateTableAnnotation returns @ORM\Table annotation even for mapped superclass entities. Since classes with annotation @ORM\MappedSuperclass are only to be extended and will NOT have a database table associated to them they should not have '@ORM\Table' annotation at all.
It would be enough to wrap the method body with `if ($metadata->isMappedSuperclass)

{ ... }

`.






[DDC-3283] [GH-1125] Update improving-performance.rst Created: 29/Aug/14  Updated: 19/Oct/14  Resolved: 30/Aug/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 kcassam:

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

Message:

Add change tracking policies chapter



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2352] [GH-615] Update SqlWalker.php Created: 15/Mar/13  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: aliases, escaping, postgresql, query


 Description   

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

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

Message:

Always be sure that only a-z characters are used for table alias, otherwise use generic "t" for "table"



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2362] [GH-624] Fix getSQLTableAlias for postgre camelized table name Created: 22/Mar/13  Updated: 19/Oct/14  Resolved: 01/May/13

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

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


 Description   

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

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

Message:

In postgreSQL with old databases we can have camelized model names to query on we need to add quote around the table name like :

```

  • @ORM\Table(name="""someThing""")
    ```

But when query is built the alias taken will be `"` this fix will find the good alias to use enabling to query camelized tables



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

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

Comment by Benjamin Eberlei [ 01/May/13 ]

PR was fixed in favor of Doctrine ORM GH-615

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3271] Impossible to set-up Two relations one-to-one which share the same target Created: 25/Aug/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Grégoire Pineau Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

I reproduced my issue in a SF2 standard edition.

https://github.com/lyrixx/symfony-standard/blob/doctrine-many/test.php

So basically:

I have a "dude" table, with 2 FK: "delivery_address" and "billing_address".
But I'm not able to set-up doctrine to make it work, because when I set-up
the "Address" Entity, doctrine add a "unique" constraint on this table.
So I can insert one of the two addresses, but not two addresses.



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

This is actually how one-to-one works: you are probably looking for a different association type here.





[DDC-2456] [GH-669] Fixed generating column names for self referencing entity. Created: 17/May/13  Updated: 19/Oct/14  Resolved: 26/May/13

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

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


 Description   

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

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

Message:



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3350] [GH-1160] #1159 - multiple entity managers per repository factory should be supported Created: 13/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
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


 Description   

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

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

Message:



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

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

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

Fixed as of https://github.com/doctrine/doctrine2/commit/06b5c847287ab4dec7c8a758be0f683cbbe3946d





[DDC-2458] [GH-671] [DDC-2435] Fix column name with numbers and non alphanumeric characters. Created: 17/May/13  Updated: 19/Oct/14  Resolved: 17/May/13

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

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


 Description   

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

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

Message:

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



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

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

Comment by Fabio B. Silva [ 17/May/13 ]

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

Comment by Doctrine Bot [ 29/Aug/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3323] Add user managed parameters bag to UnitOfWork Created: 24/Sep/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Improvement Priority: Trivial
Reporter: Krzysztof Lechowski Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

User Story:
1. User has Article:Tags entities.
2. There is sort order attribute of a tag.
3. after any tag is removed, sort orders should be recalculated.

The intuitive place for it is postRemove, but technically we don't want to do any flushes in LifeCycle event. Below suggested solution is pass the handling of sort orders update to postFlush. For this sake postFlush needs to receive information from postRemove.

No global state is good idea I have 2 candidates:
1. Passet around event args
2. Unit of Work.

I'd prefer UnitOfWork because it's of more general use and more logical. This kind of information is unit-of-work context related. I'd like to call $unitOfWork->setParam('param_name', $value); and $unitOfWork->getParam('param_name');

Another person who stumbled upon the same situation, not sure how he handled it:

http://stackoverflow.com/questions/13095083/symfony2-doctrine2-throwing-index-error-when-flushing-the-entity-manager#answer-16701360



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

This doesn't seem to be the responsibility of the UoW: Won't be implemented.





[DDC-3325] No exception thrown when passing invalid option to mapXToY() in ClassMetadataInfo Created: 25/Sep/14  Updated: 19/Oct/14

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

Type: Bug Priority: Minor
Reporter: Thomas Konrad Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm
Environment:

Symfony2, Windows 7, PHP 5.4



 Description   

I recently ran into the problem that I wrongly specified the `joinColumn` option passed to the method `mapManyToOne` in the `ClassMetadataInfo` class:

    $metadata->mapManyToOne(array(
        // ...
        'joinColumn'   => array(
            'name' => 'column_id',
        )
    ));

This would be the intuitive way to define that mapping, as with Annotations it is also called `JoinColumn` (but yeah I know, there could possibly be multiple `JoinColumn` definitions). The right way to do it is:

    $metadata->mapManyToOne(array(
        // ...
        'joinColumns'   => array(array(
            'name' => 'column_id',
        ))
    ));

The actual bad experience that I had as a developer here is that no exception was through even though I had definitely passed a wrong configuration option to the mapping function. In fact, nothing happended, the `joinColumn` option was just ignored. It would be great in this case if an exception would be thrown so that it is clear to the developer that there is something wrong.

Thanks!






[DDC-3326] [GH-1148] [DWEB-118] Fixed small typo in documentation about extra lazy associations Created: 26/Sep/14  Updated: 19/Oct/14  Resolved: 19/Oct/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: Steve Müller
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Fixed small documentation issue http://www.doctrine-project.org/jira/browse/DWEB-118



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3329] Comment on clumn is passed when creating self-reference association Created: 28/Sep/14  Updated: 19/Oct/14

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

Type: Bug Priority: Minor
Reporter: Steve Todorov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

PostgreSQL 9.1, possibly other databases as well.



 Description   

The example below will pass the comment from the column group_id to parent_id. Unfortunately that is not what I would like because the comment would confuse that parent_id has the same purpose as group_id which is not the case.

Group.php
class Group {

    /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\Column(name="group_id", type="integer", options={"comment" = "This column is a relation to atable.z, btable.y, rtable.k, or whatever long comment we have here."})
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    private $id;

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

    /**
     * @var integer
     *
     * @ORM\JoinColumn(name="parent_id", referencedColumnName="group_id", nullable=true)
     * @ORM\ManyToOne(targetEntity="Acme\MyBundle\Entity\Group")
     */
    private $parent;

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

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

    /**
     * Set name
     *
     * @param string $name
     *
     * @return Group
     */
    public function setName( $name ) {
        $this->name = $name;

        return $this;
    }

    /**
     * Get parent
     *
     * @return Group
     */
    public function getParent() {
        return $this->parent;
    }

    /**
     * Set parent
     *
     * @param Group $parent
     *
     * @return Group
     */
    public function setParent( Group $parent ) {
        $this->parent = $parent;

        return $this;
    }
}


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

Steve Todorov can you rephrase the issue? What's the DDL for that table? And What exactly is broken about it?





[DDC-3331] DQL parsing fail when using COUNT with "Simple Derived Identity" primary key Created: 29/Sep/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Mickael Zhu Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: bidirectional, count, onetoone, parser
Environment:

Mac osx Maverick
PHP 5.5.13
Nginx 1.6.0
Mysql 5.6.19



 Description   
Member.php

namespace DoctrineOrmTest\Assets\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="member")
 */
class Member
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer");
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

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

    /**
     * @var Student
     *
     * @ORM\OneToOne(targetEntity="DoctrineOrmTest\Assets\Entity\Student", mappedBy="member")
     */
    protected $student;

}

Student.php

namespace DoctrineOrmTest\Assets\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="student")
 */
class Student
{
    /**
     * @var Member
     *
     * @ORM\Id
     * @ORM\OneToOne(targetEntity="DoctrineOrmTest\Assets\Entity\Member")
     * @ORM\JoinColumn(name="id", referencedColumnName="id", nullable=false)
     */
    private $member;
}

When I use a oneToOne relation as primary key, the following dql request fail :

SELECT COUNT(a) FROM DoctrineOrmTest\Assets\Entity\Student a

I have the following message :

[Semantical Error] line 0, col 13 near 'a) FROM DoctrineOrmTest\Assets\Entity\Student': Error: Invalid PathExpression. Must be a StateFieldPathExpression

I can fix it with this workaround

SELECT COUNT(a.member) FROM DoctrineOrmTest\Assets\Entity\Student a

But it mess with one of my auto-generation script.



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

You can just COUNT(a.id) here. I don't really see what the problem is.

If you look at the EBNF at http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#ebnf, your current DQL is indeed invalid.

Comment by Marco Pivetta [ 19/Oct/14 ]

To clarify:

AggregateExpression ::= ("AVG" | "MAX" | "MIN" | "SUM" | "COUNT") "(" ["DISTINCT"] SimpleArithmeticExpression ")"

A SimpleArithmeticExpression boils down to a set of ArithmeticPrimary, which is:

ArithmeticPrimary          ::= SingleValuedPathExpression | Literal | "(" SimpleArithmeticExpression ")"

And therefore does not support an entity alias, but only either a Literal (constant value, like a number or a string) or a SingleValuedPathExpression, which is indeed a field of your entity.





[DDC-2726] EventSubscriber PreUpdate Error Bug? Created: 06/Oct/13  Updated: 19/Oct/14  Resolved: 19/Oct/14

Status: Resolved
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: Nelson Ford Assignee: Marco Pivetta
Resolution: Incomplete Votes: 1
Labels: orm

Attachments: PNG File caca.png    

 Description   

Should this:

public function preUpdate(PreUpdateEventArgs $eventArgs)
{
    $entity = $eventArgs->getEntity();
    $em = $eventArgs->getEntityManager();
    $uow = $em->getUnitOfWork();

    if ($entity instanceof User) {
        if ($eventArgs->hasChangedField('finalStatus')) {
            $entity->setFinalStatusDate(new \DateTime('now'));
            $uow->recomputeSingleEntityChangeSet(
                $em->getClassMetadata("MyAdminBundle:User"),
                $entity
            );
        }
        if ($eventArgs->hasChangedField('membershipCode')) {
            $entity->setMembershipCodeDate(new \DateTime('now'));
            $uow->recomputeSingleEntityChangeSet(
                $em->getClassMetadata("MyAdminBundle:User"),
                $entity
            );
        }
    }
}

...result in this?

Catchable Fatal Error: Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be an array, null given, called in /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 995 and defined in /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

I'm just setting a time stamp for two updated values. Dumping the 3rd argument in PreUpdateEventArgs.php on line 47 reveals an array of changes. I'm not sure if this is a bug or if I'm performing this simple operation incorrectly.



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

Can you write an integration test around it? Looks like the changeset is removed in a particular edge case, but it's hard to figure it out without a test.

Comment by Florin [ 29/Sep/14 ]

here, solve it

Comment by Marco Pivetta [ 19/Oct/14 ]

Missing test case





[DDC-3320] [GH-1144] [DDC-3287] Change parent classes of some Events Created: 23/Sep/14  Updated: 19/Oct/14

Status: Awaiting Feedback
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 zebba:

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

Message:

Following my <a href="http://doctrine-project.org/jira/browse/DDC-3287">issue report</a> in Jira find attached the necessary changes.



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

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





[DDC-3287] PreUpdateEventArgs need to extend Doctrine\Common\PreUpdateEventArgs Created: 29/Aug/14  Updated: 19/Oct/14

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

Type: Improvement Priority: Trivial
Reporter: Sebastian Kuhlmann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: inheritance, orm


 Description   

Currently the inheritance tree of the EventArgs don't allow for creating event listeners that fit both ORM- and MongoDB-driven applications.

Doctrine\Common defines base classes for Lifecycle event arguments. Doctrine\ORM uses the common library and extends it's classes. So does MongoDB. If you wanted to write something that suits both ORM and MongoDB you should be able to rely on the Common-implementations.

The provided classes to extend:

  • Doctrine\Common\Persistence\Event\LifecycleEventArgs
  • Doctrine\Common\Persistence\Event\LoadClassMetadataEventArgs
  • Doctrine\Common\Persistence\Event\ManagerEventArgs
  • Doctrine\Common\Persistence\Event\OnClearEventArgs
  • Doctrine\Common\Persistence\Event\PreUpdateEventArgs

Checking the Github repository there is no common ground for the inheritance mechanism.

  • Doctrine\ORM\Event\LifecycleEventArgs extends Doctrine\Common\Persistence\Event\LifecycleEventArgs
  • Doctrine\ORM\Event\PreUpdateEventArgs extends Doctrine\ORM\Event\LifecycleEventArgs
  • Doctrine\ORM\Event\PreFlushEventArgs extends Doctrine\Common\EventArgs
  • Doctrine\ORM\Event\PostFlushEventArgs extends Doctrine\Common\EventArgs
  • Doctrine\ORM\Event\OnFlushEventArgs extends Doctrine\Common\EventArgs
  • Doctrine\ORM\Event\OnClearEventArgs extends Doctrine\Common\EventArgs

This needs to change and ORM\PreUpdateEventArgs as well as ORM\OnClearEventArgs need to extend the respective events from Doctrine\Common.



 Comments   
Comment by Sebastian Kuhlmann [ 23/Sep/14 ]

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

Comment by Christophe Coevoet [ 04/Oct/14 ]

All flush event args should be updated to extend ManagerEventArgs (and marking their getEntityManager method as deprecated too)

Comment by Christophe Coevoet [ 04/Oct/14 ]

to be clear, the change on PreUpdateEventArgs cannot be done until 3.0 because of BC

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3328] [GH-1150] Improve Comparison::CONTAINS: allow to use custom position for % and _ wildcard characters Created: 28/Sep/14  Updated: 19/Oct/14

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

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


 Description   

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

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

Message:

This pull prevent forced wrapping of the value in to `%`
and allow to use the custom position for `%` and `_` wildcard characters in case `Comparison::CONTAINS`

Allow to build the `contains` expressions like:
```php
Criteria::expr()->contains('myField', 'some string%');
Criteria::expr()->contains('myField', '%some string');
Criteria::expr()->contains('myField', '10%');
Criteria::expr()->contains('myField', 's_m_ string');
```



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

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





[DDC-3005] Events::postLoad fires without filled associations Created: 02/Mar/14  Updated: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Artur Eshenbrener Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Dependency
depends on DDC-3070 [GH-1001] [DDC-3005] Defer invoking o... Open

 Description   

When we load entities throw one dql query like this:

SELECT e, joined_link FROM Entity LEFT JOIN e.link joined_link

In event subscriber, subscribed to postLoad event for instances of Entity property "link" of entity does not contains fetched in same query joined entity, and does not contains proxy object.

Tell me if failing test case needed.



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

The postLoad event is fired without warranty that association entities/proxies will be set:

http://docs.doctrine-project.org/en/latest/reference/events.html#lifecycle-events

Comment by Artur Eshenbrener [ 03/Mar/14 ]

But why? This shounds like involuntary restriction, and I think it can be fixed. Will my PR with fix accepted, or collaborators don't want to change this behaviour?

Comment by Marco Pivetta [ 03/Mar/14 ]

Artur Eshenbrener triggering `postLoad` in the correct moment in time (when all dependencies are loaded) requires a lot of additional complexity to be inserted in various locations of the ORM.

Since `postLoad` is supposed to be used like `__wakeup` and in general for simple tasks, this kind of refactoring/rewrite would be an overkill.

Comment by Artur Eshenbrener [ 04/Mar/14 ]

> requires a lot of additional complexity to be inserted in various locations of the ORM.
Sounds like "It is very hard to implement, and no one want to do this"

> and in general for simple tasks, this kind of refactoring/rewrite would be an overkill.
Disagree with this. Why only simple? I need to deal with associations in this event. Without this I should inject whole EntityManager to my entity, but I dont want to do this.

And I forced to repeat the question: will PR with fix accepted or not?

Comment by Marco Pivetta [ 04/Mar/14 ]

Sounds like "It is very hard to implement, and no one want to do this"

Not really, the main problem here is performance, since hydration would have to be completely redesigned.
Yes, "too hard" is a good reason for something that is an edge case.

And I forced to repeat the question: will PR with fix accepted or not?

Sure thing! Just needs to avoid a massive rewrite though.

Comment by Marco Pivetta [ 04/Mar/14 ]

To give you some hints, Doctrine\ORM\Events::postLoad is triggered in https://github.com/doctrine/doctrine2/blob/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328/lib/Doctrine/ORM/UnitOfWork.php#L2788, and Doctrine\ORM\UnitOfWork#createEntity() is used by all the various hydrators internally.

To ensure that Doctrine\ORM\Events::postLoad is triggered after an entity is fully loaded, the various hydrators must trigger the events after being sure that all data has been set, and that the entity is "ready" for use. That's some copy-paste work :\

Comment by Artur Eshenbrener [ 04/Mar/14 ]

I think the entry point is here: https://github.com/doctrine/doctrine2/blob/15432fc55f83c2d6ce8d9b86fd3139dd2a4fc328/lib/Doctrine/ORM/Internal/Hydration/AbstractHydrator.php#L140,
so, copy-paste work is not needed )

Comment by Artur Eshenbrener [ 05/Apr/14 ]

PR is ready: https://github.com/doctrine/doctrine2/pull/1001

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3070] [GH-1001] [DDC-3005] Defer invoking of postLoad event to the end of hydration cycle. Created: 04/Apr/14  Updated: 19/Oct/14

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

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

Issue Links:
Dependency
is required for DDC-3005 Events::postLoad fires without filled... Reopened

 Description   

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

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

Message:

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



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-1873] [GH-373] Grammar fix for composer.json file Created: 12/Jun/12  Updated: 19/Oct/14  Resolved: 22/Jun/12

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 13/Jun/12 ]

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

Comment by Guilherme Blanco [ 22/Jun/12 ]

PR was merged.

Comment by Doctrine Bot [ 13/Dec/13 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3338] [GH-1153] Add max. This is just example. Created: 06/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/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 upirna:

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

Message:



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

Won't be fixed, as this issue requires major changes in collection interfaces (not yet scheduled)





[DDC-3344] Flush on a specific entity is not correctly cascaded to associated entities Created: 10/Oct/14  Updated: 19/Oct/14

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

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


 Description   

In a setup with a simple entity associated entity, the cascade is not performed when flushing the parent entity. This violates contract specified by EntityManager#flush($entity) PHPDoc:

If an entity is explicitly passed to this method only this entity and the cascade-persist semantics + scheduled inserts/removals are synchronized.

It seems that the reason behind this is UnitOfWork#computeAssociationChanges, which expects that a #computeChangeSets is called elswehere (which it is not when flushing a specific entity):

MANAGED associated entities are already taken into account during changeset calculation anyway, since they are in the identity map.

This makes flushing and cascading very confusing. Also I believe this might be a cause of other issues, like DDC-3113.



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

Doctrine\ORM\EntityManager#flush() is not supposed to be called with a specific entity when there are cascade operations involved.

The optional argument has to be only used for performance reasons, but can indeed break things.

Comment by Pavel Horal [ 10/Oct/14 ]

Thank you for the reply. I am probably (and possibly other people) misinterpretting the PHPDoc. Can you explain what is meant by "and the cascade-persist semantics"?

Comment by Marco Pivetta [ 19/Oct/14 ]

Pavel Horal I don't really understand that bit myself, but git blame states that the comment was introduced in https://github.com/doctrine/doctrine2/commit/5d3298e706b1457ca8be02469b00ef219afe84e6 by Benjamin Eberlei.

Maybe it just needs a docblock rewrite

Comment by Pavel Horal [ 19/Oct/14 ]

Commit is linked with DDC-720 . Again, that gives me an impression that events should be cascaded:

In a nutshell, this change would mean that flush() can optionally accept an entity as an argument. When that happens, the resulting changeset will be limited to that entity and any entity reachable from it.

Comment by Marco Pivetta [ 19/Oct/14 ]

Again, that gives me an impression that events should be cascaded

No, the entire flush($entity) functionality is just to limit the entire Doctrine\ORM\UnitOfWork operations over the single object: it's expected behavior.

In general, you should use flush($entity) only if you have very high priority performance optimizations, as it was never meant to be reliable API when using listeners.

I'd even suggest deprecating it for removal in the next major release, as it has only caused issues so far.





[DDC-3318] [GH-1143] Fixed a bug so that a versioned entity with a oneToOne id can be created Created: 23/Sep/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: hydration, hydrator, onetoone, unitofwork, versioned


 Description   

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

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

Message:

  • Fixed the basic entity persister so that versioned OneToOne entities can be created
  • Created an IdentifierConverter utility class
  • Moved the logic for the flatten identifier method into the new utility class
  • Replaced calls for private flattenIdentifier to use new utility
  • Added appropriate unit tests


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

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





[DDC-1858] LIKE and IS NULL operators not supported in HAVING clause Created: 07/Jun/12  Updated: 19/Oct/14  Resolved: 08/Sep/13

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

Type: Improvement Priority: Major
Reporter: PETIT Yoann Assignee: Guilherme Blanco
Resolution: Fixed Votes: 4
Labels: None
Environment:

Win7, Mysql



 Description   

The LIKE and IS NULL operators are not supported in HAVING clause.

Work:
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu in (3,6)
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu = 3
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu >= 3
...

Don't work:
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu LIKE 3
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu IS NULL
SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu IS NOT NULL



 Comments   
Comment by Marco Pivetta [ 08/Jun/12 ]

I think this has already been fixed in latest master and 2.1.7. Could you just give it a try and eventually confirm?

Comment by PETIT Yoann [ 08/Jun/12 ]

Already try with 2.17, 2.20 and 2.2.2. This hasn't been fixed.

Comment by Bdiang [ 04/Jul/12 ]

I'm also having this issue (2.2.2). Is there any workaround for this?

Column aliases also are not supported in HAVING clause:

$qb->select('p', 'COUNT(p.field) as FieldCount')
            ->from('Entity', 'p')
            ->groupBy('p.id')
   ->having('FieldCount IS NULL')

Above code causes error "FieldCount is not pointing to class" and IS NULL causes "Expected =, <, <=, <>, >, >=, !=, got 'IS'"

Comment by Benjamin Eberlei [ 29/Aug/12 ]

Its not a bug as the EBNF says that this is not possible.

Guilherme Blanco Is this something we should support or not?

Comment by Christophe Coevoet [ 29/Aug/12 ]

Another place where it is not supported is in the CASE clause.

I would vote +1 for supporting it

Comment by Benoit Jacquemont [ 10/Jun/13 ]

@Benjamin Eberlei
The EBNF seems to indicate that any search condition is valid on the HAVING clause:
http://savage.net.au/SQL/sql-99.bnf.html#having%20clause

If you look at the Search condition ( http://savage.net.au/SQL/sql-99.bnf.html#search%20condition ), the NULL predictate ( http://savage.net.au/SQL/sql-99.bnf.html#null%20predicate ) seems to be a part of it.

Maybe I'm misinterpreting the BNF ?

And if not, any idea of a targeted release for the fix ?

Comment by Guilherme Blanco [ 11/Jun/13 ]

Benjamin Eberlei it seems to be SQL-92 compatible. The improvement is valid.
We should support it. I'll take a look into this. =)

Cheers,

Comment by Guilherme Blanco [ 11/Jun/13 ]

Functionality is already implemented in master as per coverage added in here:

https://github.com/doctrine/doctrine2/commit/4e99c5c127c810bf63c9a371f87f0ff5c82e3e79

Closing the ticket.

Comment by Litz Ouille [ 14/Aug/13 ]

At the moment, only the `HAVING field IS [NOT] NULL` is working.

The `HAVING field LIKE` as in
(SELECT _a.id, count(_photos) as uuuu FROM Acme\CoreBundle\Entity\Member _a LEFT JOIN _a.photos _photos GROUP BY _a HAVING uuuu LIKE 3)
still does not work.

Comment by Guilherme Blanco [ 19/Aug/13 ]

I implemented support for ResultVariable in LikeExpression as of https://github.com/doctrine/doctrine2/commit/43fc8bafa766b4e924b05c74825dd30393a17f06

Comment by Litz Ouille [ 19/Aug/13 ]

It works. Thanks !

Comment by Benjamin Eberlei [ 08/Sep/13 ]

Assigned fix version

Comment by Nikolay Baklicharov [ 06/Oct/14 ]

Guilherme Blanco Please backport to released version. This is very serious issue, especially when you make search queries.

Comment by Marco Pivetta [ 06/Oct/14 ]

Nikolay Baklicharov this is an improvement, not a bug fix, therefore there will be no backporting.

Comment by Nikolay Baklicharov [ 07/Oct/14 ]

Marco Pivetta Then what workaround I can use? Lets say I do leftJoin on table and do AVG(object.value) > 3 OR object IS NULL. I.e. I want all results that have avg value higher than 3 and also results that do not have object at all?

Comment by Marco Pivetta [ 07/Oct/14 ]

The current workaround is bumping the ORM version, which may or may not be a problem depending on your stability policies and how much you need this feature.

Otherwise, NativeSQL until the functionality is available in a stable release.

Comment by Nikolay Baklicharov [ 07/Oct/14 ]

Marco Pivetta Not an option for the project. However I found workaround that I will share here in case someone come here from google search like me.

$queryBuilder->addSelect( 'COALESCE(AVG(ra.value), 0) AS HIDDEN averageRating' );
$queryBuilder->leftJoin( 'c.ratings', 'ra' );
$queryBuilder->andHaving( 'averageRating >= :avgRating' );
$queryBuilder->orHaving( 'averageRating = 0' );
$queryBuilder->setParameter( ':avgRating', $ratingFilter );




[DDC-3342] Join with child tables Created: 09/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

Type: New Feature Priority: Major
Reporter: Thomas Lallement Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DDC-16 DQL Ignores properties of subclasses Closed

 Description   

Hi,

It could help a lot if we could simply join parent table with childs when the inheritance type is JOINED.

For example if you need to add clauses on child properties. For the moment we need to create sub queries to add clauses in it.



 Comments   
Comment by Thomas Lallement [ 09/Oct/14 ]

It would also be possible and useful to be able to sort on the DiscriminatorColumn





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

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

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

Issue Links:
Duplicate
is duplicated by DDC-1377 Doctrine doesn't understand associati... Closed
is duplicated by DDC-3342 Join with child tables Resolved

 Description   

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

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



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

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

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

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

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

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

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

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

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

Comment by Menno Holtkamp [ 18/Jul/11 ]

+1 for this request.

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

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

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

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

Comment by Avi Block [ 18/Jul/11 ]

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

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

Comment by Glen Ainscow [ 19/Jul/11 ]

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

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

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

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

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

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

Possible solution:

SELECT p FROM CAST(Person AS User) p

Or:

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

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

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

Comment by Benjamin Eberlei [ 16/Sep/11 ]

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

Comment by Glen Ainscow [ 16/Sep/11 ]

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

Comment by Jaka Jancar [ 18/Feb/12 ]

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

I'm trying to do:

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

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

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

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

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

(+1 for Guilherme Blanco possible solution)

Comment by Wladimir Coka [ 04/Apr/12 ]

I was trying a workaround:

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

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

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

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

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

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

Comment by Marco Pivetta [ 24/Feb/13 ]

I am closing this one.

The requirement of this issue is basically violating OO principles.

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

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

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

Comment by Bogdan Yurov [ 17/Jul/14 ]

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

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

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

Comment by Marco Pivetta [ 17/Jul/14 ]

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

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

There are usecases, when we have nothing to do.

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

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

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

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

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

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

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

Comment by Bogdan Yurov [ 17/Jul/14 ]

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

Comment by Marco Pivetta [ 17/Jul/14 ]

Bogdan Yurov we already tried looking into this multiple times.

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

Comment by Bogdan Yurov [ 17/Jul/14 ]

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

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

Comment by Marco Pivetta [ 22/Jul/14 ]

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





[DDC-3349] Possibility to override order of fields of composite ID produced by Mapping Created: 13/Oct/14  Updated: 19/Oct/14

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

Type: New Feature Priority: Major
Reporter: tiger-seo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping

Issue Links:
Reference
relates to DDC-3352 [GH-1162] DDC-3349: Possibility to ov... Open

 Description   

So, the problem is when the one needs to use association key in composite identifier; they are added in the end of the identifier array, which is clearly not always suitable in regards to performance.
For example, following mapping:

Acme\DemoBundle\Entity\PageLocalFans:
    type: entity
    id:
        date:
            type: date
        page:
            associationKey: true
        countryCode:
            type: string
            length: 2
    fields:
        fans:
            type: integer
    manyToOne:
        page:
            targetEntity: Page
            joinColumn:
                name: page_id
                referencedColumnName: id
                onDelete: CASCADE

will turn into sql as:

CREATE TABLE page_local_fans (
  date         DATE       NOT NULL,
  country_code VARCHAR(2) NOT NULL,
  page_id      INT        NOT NULL,
  fans         INT        NOT NULL,
  INDEX IDX_7391EB36C4663E4 (page_id),
  PRIMARY KEY (date, country_code, page_id)
) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

and there is no way to change the order of the primary from

PRIMARY KEY (date, country_code, page_id)

to

PRIMARY KEY (date, page_id, country_code)


 Comments   
Comment by tiger-seo [ 14/Oct/14 ]

i've done the PR for this, pls see https://github.com/doctrine/doctrine2/pull/1162

Comment by Doctrine Bot [ 17/Oct/14 ]

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





[DDC-3352] [GH-1162] DDC-3349: Possibility to override order of fields of composite ID produc... Created: 14/Oct/14  Updated: 19/Oct/14

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

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

Issue Links:
Reference
is referenced by DDC-3349 Possibility to override order of fiel... Open

 Description   

This issue is created automatically through a Github pull request on behalf of tiger-seo:

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

Message:

DDC-3349: Possibility to override order of fields of composite ID produced by Mapping



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

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





[DDC-3354] Replacing indexed item on association with indexBy cannot comply with unicity constraint Created: 17/Oct/14  Updated: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: Charles Bouchard-Légaré Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, mapping, orm


 Description   

Using a bidirectional one-to-many relation having an 'indexBy' clause on the owning side and a unique constraint over the indexed field and the 'mappedBy' field of the inverse side, replaced indexed fields being inserted before removed violated the unique constraint.

As stated in the code examples below, if done without the unique constraint, when replacing an indexed field, the row is replaced in the database (new one created, old one deleted).

Here is an example:

Yaml Mapping for Person and Email
Person:
    type: entity
    id:
        id:
            type: integer
            generator:
                strategy: AUTO
    oneToMany:
        emailAddresses:
            targetEntity: Email
            indexBy: name
            mappedBy: owner
            cascade: [ all ]
            orphanRemoval: true

Email:
    type: entity
    id:
        id:
            type: integer
            generator:
                strategy: AUTO
    fields:
        name:
            type: string
            nullable: false
        address:
            type: string
            nullable: false
    uniqueConstraints:
        unique_named_person_email:
            columns: [ owner_id, name ]
    manyToOne:
        owner:
            targetEntity: Person
            inversedBy:   emailAddresses
            joinColumn:
                name: owner_id
                referencedColumnName: id
PHP definitions for Person and Email
class Person {
    protected $id;
    /**
     * @var Collection|Email[] $emailAddresses
     */
    protected $emailAddresses;

    /**
     * I would expect this to work.
     */
    public function setEmailAddress_expected($name, $emailAddress)
    {
        /**
         * Expected to work but throws UniqueConstraintViolationException
         * If done without the 'unique_named_person_email' constraint', it 
         * works properly creating a new Email and deleting the old one.
         */
        $this->emailAddresses->set(
            (string) $name,
            new Email($this, (string) $name, (string) $emailAddress)
        );
    }
    
    /**
     * I would expect this to work.
     */
    public function setEmailAddress_expected_too($name, $emailAddress)
    {
        /**
         * Expected to work but throws UniqueConstraintViolationException
         * If done without the 'unique_named_person_email' constraint, it 
         * works properly creating a new Email and deleting the old one.
         */
        $this->emailAddresses->remove((string) $name);
        $this->emailAddresses->set(
            (string) $name,
            new Email($this, (string) $name, (string) $emailAddress)
        );
    }

    /**
     * Works
     */
    public function setEmailAddress_works($name, $emailAddress)
    {
        $existing = $this->emailAddresses->get((string) $name);
        if ($existing) {
            $existing->setAddress((string) $emailAddress);
        } else {
            $this->emailAddresses->set(
                (string) $name,
                new Email($this, (string) $name, (string) $emailAddress)
            );
        }
    }
}

class Email {
    protected $id;
    protected $owner;
    protected $name;
    protected $address;
    public function __construct($owner, $name, $address)
    {
        $this->owner = $owner;
        $this->name = $name;
        $this->address = $address;
    }

    /**
     * I am forced to create this method.
     */
    public function setAddress($address)
    {
        $this->address = $address;
    }
}

IMO, Using 'indexBy' on a one-to-many relation should automatically generate a unique constraint for the combination of the indexed field and the 'mappedBy' field.

Documentation states that

Fields that are used for the index by feature HAVE to be unique in the database. The behavior for multiple entities with the same index-by field value is undefined.

which is unclear (especially the use of the word 'database'). I wonder why indexes used for association should be unique for a whole table.



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

I wonder why indexes used for association should be unique for a whole table.

That's because we can't ensure that indexes aren't overwritten when hydrating a collection: that is what the behavior "undefined" stands for.

As for replacing values in the collection, that's how the ORM works in any case, as it inserts data before removing any data to avoid removes from causing FK constraint failures (see https://github.com/doctrine/doctrine2/blob/d361ed904e5d56711304b755b5b2a8484d9a35b6/lib/Doctrine/ORM/UnitOfWork.php#L347-L379)





[DDC-2504] [GH-696] extra lazy joined test Created: 14/Jun/13  Updated: 19/Oct/14

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

Type: Bug Priority: Major
Reporter: 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 Padam87:

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

Message:

Hi,

This is just a bug report, not an actual PR, you don't have to merge.

When you have a JOINED inheritance, and you have another class, which is related to the parent class of the inheritance, and you only have an association for one of the child classes, EXTRA_LAZY fetch mode creates a fatal error, because it is not joining the parent table to the count query.

There are many ways around this fortunately, but I thought I should report it anyway.



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-3355] [GH-1164] [QueryBuilder] Remove unused method parameters to run on HHVM/PHP7 Created: 17/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/14

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

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


 Description   

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

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

Message:

PHP5 treats the left part of an assignment to a method parameter as an independent local variable, while HHVM/PHP7 treats it as a reference to the method parameter. This leads to the value of the parameter being changed, which, in turn, causes func_get_args() to return not what is expected.

This commit is a part of the effort to make Symfony run flawlessly on HHVM. This issue causes a bunch of Symfony tests to fail on HHVM.

The master is currently broken, so the best thing I could do was to make sure the number of test failures remained the same after the change.

If possible, please merge this to version 2.2 used by Symfony 2.4.



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

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





[DDC-3356] Event/Entity Listener onFlush() works but not preFlush() Created: 18/Oct/14  Updated: 19/Oct/14  Resolved: 19/Oct/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: Max Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: entity, event, flush, listener


 Description   

preFlush() example below don't do anything at all although it is 99% exactly the same as onFlush() which works as expected. Can anyone tell me what I am missing or what the reason is and the solution?

DEBUGGING TEST:

public function preFlush(PreFlushEventArgs $args)
{
    $em = $args->getEntityManager();
    $uow = $em->getUnitOfWork();
    echo '1';
    foreach ($uow->getScheduledEntityUpdates() as $entity) {
        echo '2';
        if ($entity instanceof User) {
            echo '3';
        }
    }
    exit;
}

DEBUGGING RESULT:

1 so $uow->getScheduledEntityUpdates() is an empty array!

services.yml
services:
    entity.event_listener.user:
        class:  Site\FrontBundle\EventListener\Entity\UserListener
        tags:
            - { name: doctrine.event_listener, event: preFlush }
            - { name: doctrine.event_listener, event: onFlush }

DOESN'T WORK - preFlush():

class UserListener
{
    public function preFlush(PreFlushEventArgs $args)
    {
        $em = $args->getEntityManager();
        $uow = $em->getUnitOfWork();

        foreach ($uow->getScheduledEntityUpdates() as $entity) {
            if ($entity instanceof User) {
                $userLog = new UserLog();
                $userLog->setDescription($entity->getId() . ' being updated.');

                $em->persist($userLog);
                $userLogMetadata = $em->getClassMetadata(get_class($userLog));
                $uow->computeChangeSet($userLogMetadata, $userLog);
            }
        }
    }
}

WORKS - onFlush():

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

        foreach ($uow->getScheduledEntityUpdates() as $entity) {
            if ($entity instanceof User) {
                $userLog = new UserLog();
                $userLog->setDescription($entity->getId() . ' being updated.');

                $em->persist($userLog);
                $userLogMetadata = $em->getClassMetadata(get_class($userLog));
                $uow->computeChangeSet($userLogMetadata, $userLog);
            }
        }
    }
}


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

The preFlush event is triggered BEFORE any entity changes were computed, therefore the "DOESN'T WORK" example case is invalid.





[DDC-2503] [GH-695] Implemented support for RepositoryFactory. Created: 14/Jun/13  Updated: 19/Oct/14  Resolved: 18/Jun/13

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

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


 Description   

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

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

Message:

This allows anyone to override the default behavior to load Repositories.



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

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

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

Merged : https://github.com/doctrine/doctrine2/commit/7903a2b5139e51b5dd7ed5ae164f7e0f3685dea7

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2500] [GH-692] Query\Parser: support for functions in ORDER BY clause Created: 12/Jun/13  Updated: 19/Oct/14  Resolved: 12/Jun/13

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

Type: Bug Priority: Major
Reporter: 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 Slamdunk:

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

Message:



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

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

Comment by Marco Pivetta [ 12/Jun/13 ]
ORDER BY SOME_FUNC()

is not portable across all vendors

Comment by Mr [ 31/Jul/13 ]

What about user defined functions?
It would be great to be able to include UDFs in the order by clause.

I have a sorting function that only needs to run on one column.

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2491] [GH-687] Fixed rendering Created: 06/Jun/13  Updated: 19/Oct/14  Resolved: 06/Jun/13

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

Type: Documentation Priority: Major
Reporter: 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/687

Message:

Fixed some broken rendering on http://docs.doctrine-project.org/en/latest/reference/yaml-mapping.html



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

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

Comment by Marco Pivetta [ 06/Jun/13 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2466] [GH-676] Update UnitOfWork.php Created: 22/May/13  Updated: 19/Oct/14  Resolved: 22/May/13

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

Type: Bug Priority: Major
Reporter: 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 Kynareth62:

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

Message:

Here, if a field (type date or datetime) is defined as id, I have an error because it's an object and not a string...

Can you please fix this bug ? Thank you.



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

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

Comment by Marco Pivetta [ 22/May/13 ]

Related: DDC-1209, DDC-1780

Comment by Doctrine Bot [ 19/Oct/14 ]

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





[DDC-2501] [GH-693] Adding failing test for DDC-2214 Created: 12/Jun/13  Updated: 16/Oct/14  Resolved: 12/Jun/13

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

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


 Description   

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

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

Message:

Parameters being bound to an SQL query should have the same type as
the identifier of the objects being bound to the placeholders of a
DQL query - this is currently broken with proxies, as this test
demonstrates.

This is a demonstration of DDC-2214(http://www.doctrine-project.org/jira/browse/DDC-2214)



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

Duplicate of DDC-2214

Comment by Doctrine Bot [ 12/Jun/13 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DDC-3353] [GH-1163] Update xml-mapping.rst Created: 16/Oct/14  Updated: 16/Oct/14  Resolved: 16/Oct/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 taavit:

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

Message:

Fixed closing entity tag.



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

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





[DDC-2477] [GH-681] Sequence generator fix Created: 29/May/13  Updated: 16/Oct/14

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

Type: Bug Priority: Major
Reporter: 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 lighthart:

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

Message:

$this->_sequenceName=$em->getClassMetadata(get_class($entity))->sequenceGeneratorDefinition['sequenceName'];

The sequence generator does not read the class metadata, so if there is table remapping via event listeners, any new entity won't have the appropriate changes in table names.

This pull request adds a remap the Sequence Generator to read the class metadata to determine the sequence name if there is an entity passed to the generate function.

Tests: 1854, Assertions: 6224, Skipped: 96.



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

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





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

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

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


 Description   

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

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

Message:

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



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

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

Comment by Marco Pivetta [ 12/Jun/13 ]

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

Comment by Doctrine Bot [ 14/Jul/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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

Comment by Doctrine Bot [ 16/Oct/14 ]

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





[DDC-2424] Removing an inherited entity via a delete cascade constraint does not remove the parent row Created: 02/May/13  Updated: 15/Oct/14

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

Type: Bug Priority: Major
Reporter: Bruno Jacquet Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 3
Labels: inheritance, postgresql
Environment:

Mysql 5.1.66 / Symfony 2.2.1



 Description   

For a parent class:

/**
 * @ORM\Entity
 * @ORM\Table(name="Base")
 * @ORM\InheritanceType("JOINED")
 * @ORM\DiscriminatorColumn(name="discr", type="string")
 * @ORM\DiscriminatorMap({"child1" = "Child1", "child2" = "Child2"})
 */

and simple Child1 & Child2 entities.

With another entity (let's call it ExternalEntity) having a bidirectional OneToOne relation owned by Child1:

class Child1 extends Base
{
  /**
   * @ORM\OneToOne(targetEntity="ExternalEntity", inversedBy="xxx")
   * @ORM\JoinColumn(onDelete="CASCADE", nullable=false)
   */
   private theForeignKey;
}

Enough for the context.
The symptoms:

$em->remove(instanceOfExternalEntity);

removes the ExternalEntity row and the Child1 row. But a dangling row in the Base table is still there for the now inexistent Child1 instance.

Though, a manual delete of either the associated Child1 OR Base row and then the ExternalEntity works.

The problem with the cascading deletion of the parent seems to be only present when deleting through a MYSQL cascading delete from another row which has a foreign key on a child. (Not tested with a foreign key on the parent though)



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

Can you show the CREATE TABLE and FOREIGN KEY statements of all the tables involved? It seems the cascade of the foreign keys is not propagated between multiple tables?

Comment by Bruno Jacquet [ 06/May/13 ]

CREATE TABLE Base (id INT AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;
CREATE TABLE Child1 (id INT NOT NULL, foreignKey INT NOT NULL, UNIQUE INDEX UNIQ_179B6E88E992F5A (foreignKey), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB;

ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E88E992F5A FOREIGN KEY (foreignKey) REFERENCES ExternalEntity (id) ON DELETE CASCADE;
ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E8BF396750 FOREIGN KEY (id) REFERENCES Base (id) ON DELETE CASCADE;

Comment by Bruno Jacquet [ 06/May/13 ]

The problem is that, the SQL model never explicitely tells the DB to delete the corresponding Base when Child1 gets removed. It looks like it is handled by the doctrine entity manager layer and not the actual DB engine (Base has no on delete cascade nor foreign key to its children).
So only doctrine can add the logic here because it knows the entity schema. But in this case, when it is deleted from another table, it looks like the special treatment is not triggered.

Comment by Bruno Jacquet [ 06/May/13 ]

Maybe using

cascade={"remove"}

, instead of

onDelete="CASCADE"

to force the cascading process to be handled by doctrine would workaround the bug... But I prefer to have my DB do the logic work as much as possible.

Comment by J [ 25/Apr/14 ]

I've got a similar problem but I have InheritanceType("SINGLE_TABLE") instead of JOINED.
Any updates on when this is getting fixed?





[DDC-624] Partial object query that leaves out an association to avoid loading it fetches the association anyway. Created: 03/Jun/10  Updated: 14/Oct/14

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

Type: Bug Priority: Major
Reporter: Roman S. Borschel Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 2
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1465 Fetching partial objects doesn't work... Open

 Description   

Assuming:

Customer <onetoone> Cart

where Cart is the owning side.

Since the association from Customer to Cart can not be lazy, it would make sense to leave out the association in a query to avoid loading the carts like this:

select partial c.{id,name, ... anything except cart} from Customer c"

But this is ignored and the carts of all customers are fetched anyway. Query::HINT_FORCE_PARTIAL_LOAD is an alternative solution, however it has the disadvantage that it disables lazy-loading for all queried objects. If partial querying would honor associations this would allow more fine-grained control.



 Comments   
Comment by Roman S. Borschel [ 26/Aug/10 ]

Might need to be pushed back to a 2.0.x / 2.x.x bugfix release. Not clear yet.





[DDC-612] Query\Expr::substring() third parameter should be optional Created: 25/May/10  Updated: 14/Oct/14  Resolved: 14/Oct/14

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

Type: Improvement Priority: Major
Reporter: David Abdemoulaie Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

I'm not aware of a platform that requires all 3 arguments to SUBSTRING().

This seems to only affect queries from the QueryBuilder

The following DQL works fine:

UPDATE Common\Model\Location e SET e.path = CONCAT('00010002', SUBSTRING(e.path, 9)) WHERE e.path LIKE '00010001%'

Yet the following QueryBuilder expression:

$substr = $expr->substring('e.' . $this->getPathFieldName(), strlen($oldPath)+1);

results in:

Missing argument 3 for Doctrine\ORM\Query\Expr::substring()

If I make that argument optional, default null I get the following generated DQL and error:

"UPDATE Common\Model\Location e SET e.path = CONCAT('00010002', SUBSTRING(e.path, 9, )) WHERE e.path LIKE '00010001%'
Doctrine\ORM\Query\QueryException: [Syntax Error] line 0, col 84: Error: Expected Literal, got ')'


 Comments   
Comment by David Abdemoulaie [ 25/May/10 ]

Fixed in http://github.com/doctrine/doctrine2/commit/ece0e3ad881fae4b0cb434aaa6257cdc5da6f5fc





[DDC-2358] [GH-621] [doc] adding some more doc and examples for lifecycle event listeners and subscribers Created: 19/Mar/13  Updated: 14/Oct/14  Resolved: 06/Apr/13

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

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


 Description   

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

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

Message:

as requested in https://github.com/symfony/symfony-docs/pull/2301



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

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





[DDC-2485] [GH-685] Functional ticket for DDC-2484 Created: 03/Jun/13  Updated: 14/Oct/14  Resolved: 10/Aug/13

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

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


 Description   

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

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

Message:

This shows how the postLoad can change an entity but associations are not passed through postLoad



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

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

Comment by Doctrine Bot [ 06/Oct/14 ]

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

Comment by Doctrine Bot [ 14/Oct/14 ]

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





[DDC-2995] Joined Inheritance Mapping and Filters Created: 22/Feb/14  Updated: 14/Oct/14

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

Type: Bug Priority: Major
Reporter: Bojidar Hristov Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Is there any reason why Inheritance Mapping IS LEFT JOINED not INNER JOINED?

When there is a filter and it's left joined it happens a record might not have parent table record. For example

Class B extends Class A.
Class A have column is_active | and filter activated with is_active = 1 condition.

Final query: LEFT JOIN parent_table s1_ ON p2_.id = s1_.id AND (s1_.is_active = '1')

Record 1 have is_active = false, so result set looks like this:

table_b | table_a
id | id is_active discriminatorColumn
1 | null null null

and occurs exception: The discriminator column ... is missing for ....



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

JTI MUST be left-joined, since not every subclass of the root of the inheritance causes inserts on all of the inheritance tables.

What is the DQL query that is causing the problem?

Comment by Bojidar Hristov [ 22/Feb/14 ]

Hello Marco, I don't query from parent table, but from child. No sense to be LEFT JOINED.

DQL is something like that:

SELECT class1, class2 FROM Class1 class1 JOIN class1.class2 class2;

(Class2 extends Class3)
Class3 have is_active column.

And following filter:

public function addFilterConstraint(ClassMetadata $targetEntity, $targetTableAlias) {
if (!$targetEntity->reflClass->implementsInterface('ActivateableInterface'))

{ return ""; }

return $targetTableAlias . '.is_active = ' . $this->getParameter('isActive');
}

Filter condition is added in LEFT JOINED parent_table. Full example SQL:
SELECT ....
FROM class1 c1
INNER JOIN class2 c2 ON c1.c2_id = c2.id
LEFT JOIN table3 c3 ON c2.id = c3.id AND (c3.is_active = '1')

Comment by Marco Pivetta [ 26/Feb/14 ]

There are two possible solutions here:

  • verify if the selected entity is a leaf of a JTI, and use INNER JOIN on that if possible (probably not optimal, since the selection may be part of a LEFT JOIN itself)
  • add filtering on the discriminator column

Bojidar Hristov can you provide a failing test case to make it easier to work on this?

Comment by Bojidar Hristov [ 26/Feb/14 ]

Yes. Here is it sample failing test.

http://pastebin.com/xi8uUNX5 - Parent Class
http://pastebin.com/XRZLbyGX - Child Class
http://pastebin.com/HuPFb98u - Assoc Class
http://pastebin.com/hGqRk74e - TestCase

Here it should found 0 records because ot JOIN and is_active = true filter.

Comment by Benjamin Eberlei [ 23/Mar/14 ]

Since filters are only available on the root, i guess inner join is really necessary here.

Comment by Bojidar Hristov [ 14/Oct/14 ]

Do you need something more? The bug is status Feedback?





[DDC-3351] [GH-1161] Fixing error with from() parameters in example Created: 14/Oct/14  Updated: 14/Oct/14  Resolved: 14/Oct/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 gammamatrix:

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

Message:

The from method requires $from and the $alias to be separate parameters.

public function from($from, $alias, $indexBy = null);

The examples show: from('User u')



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

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

Comment by Doctrine Bot [ 14/Oct/14 ]

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





[DDC-3345] Error generating entities using docblock (with php) the EntityGenerator is not generating the class properties Created: 10/Oct/14  Updated: 13/Oct/14

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

Type: Bug Priority: Minor
Reporter: André Antônio Lemos de Moraes Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: generation

Attachments: JPEG File doctrine.jpg     JPEG File doctrine1.jpg    

 Description   

I have my files docblock (php) inside a folder named "Script" in the project root and Generated entities are in a folder called "src" inside the root of the project too, when I send generate the entities generating the EntityGenerator Entities within the "src" however without the properties.

On line 852 of EntityGenerator.php there is a validation class_exists and how I'm using docblock with php files, the class does exist and this is causing this block of code ie which existed then taking this class and the properties of it.

In doctrine.jpg image shows my directory structure.
In doctrine1.jpg image shows the block of code that is returning true, but it should return false.

I think if you change "||" to "&&" solve the problem momentarily, but think there are other cases to consider






[DDC-3343] `PersistentCollection::removeElement` schedules an entity for deletion when relationship is EXTRA_LAZY, with `orphanRemoval` false. Created: 09/Oct/14  Updated: 13/Oct/14

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

Type: Bug Priority: Critical
Reporter: Andrea Sprega Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm


 Description   

Given the following entity for which I only report the relevant association:

class Group
{
    /**
     * @ORM\OneToMany(targetEntity="User", mappedBy="group", fetch="EXTRA_LAZY")
     */
    protected $users;
    //...
}

and its inverse

class User
{
    /**
     * @ORM\ManyToOne(targetEntity="Group", inversedBy="users")
     * @ORM\JoinColumn(name="group_id", onDelete="SET NULL")
     */
    protected $group;
    //...
}

I experience a weird issue when, inside Group, I call $this->users->removeElement($user): Doctrine schedules the $user entity for deletion, no matter what (it doesn't check for the orphanRemoval attribute). Also, even re-adding the entity to a new Group before the flush() occurs doesn't prevent it from being deleted.

I believe this is a bug, since I do not see any special mention of this behavior in the documentation for extra lazy associations:
http://doctrine-orm.readthedocs.org/en/latest/tutorials/extra-lazy-associations.html.

The workaround for me has been to remove fetch="EXTRA_LAZY" from the relationship.

After digging a little bit into the source code, this seems to be the commit (and the line) that introduced this behavior:

https://github.com/doctrine/doctrine2/commit/356f5874bf81ca4e37681c233e24cc84d16e7a39#diff-108586f774fc8acb02163ed709e05e86R403

I also found this on Google:

https://groups.google.com/forum/#!topic/doctrine-user/cx_yBuoqiAE

which basically didn't help much, except for suggesting that it should be a feature when there is an orphanRemoval and/or a cascade operation in place (and that makes perfectly sense).

I set this to "critical" since (as it occurred to me) it can lead to irrecoverable data loss.

Is this effectively a bug?






[DDC-3336] Undefined property: Doctrine\ORM\Query\AST\SimpleArithmeticExpression::$field Created: 04/Oct/14  Updated: 13/Oct/14

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

Type: Bug Priority: Critical
Reporter: Glen Ainscow Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DDC-1958 pager produces wrong results on postg... Resolved

 Description   

I upgraded from 2.4.1 to 2.4.4, and now I'm seeing this notice here & there: Undefined property: Doctrine\ORM\Query\AST\SimpleArithmeticExpression::$field in /*/vendor/doctrine/orm/lib/Doctrine/ORM/Tools/Pagination/LimitSubqueryOutputWalker.php on line 200

This seems to be in a method with the description "Generates new SQL for Postgresql or Oracle if necessary." ... but we're on MySQL (Percona).



 Comments   
Comment by Glen Ainscow [ 05/Oct/14 ]

Changed this to critical. It's also screwing up ordering, for example:

SELECT tp, p, CASE WHEN tp.memberTo IS NULL THEN 1 ELSE 0 END AS HIDDEN ord FROM Tournaments_Model_TeamPlayer tp INNER JOIN tp.player p LEFT JOIN p.user u WHERE tp.team = ?1 ORDER BY ord DESC, tp.memberFrom ASC

The paginator doesn't order the data correctly unless I remove the 2nd order by (tp.memberFrom ASC). The generated SQL from the QB/DQL is correct, so the paginator must be messing something up.

See: http://www.doctrine-project.org/jira/browse/DDC-1958?focusedCommentId=24010&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24010

Comment by Marco Pivetta [ 13/Oct/14 ]

Need a test case in order to verify the issue





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

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

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


 Description   

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

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

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

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

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



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

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





[DDC-3340] __wakeup not called in UoW::createEntity when loading uninitialized proxy Created: 07/Oct/14  Updated: 13/Oct/14

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

Type: Bug Priority: Major
Reporter: Uwe Jäger Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I'm using __wakeup to initialize a property with an empty ArrayCollection for a transient property. But when I try to "find" the entity and the uninitialized Proxy is already in the entity map, the proxy is simply set to "initialized" but my code to init the collection is never call (see https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L2552). So neither the constructor of my entity nor the proxies' _load method are called.
Where should I initialize that collection?



 Comments   
Comment by Uwe Jäger [ 07/Oct/14 ]

I just added a postLoad event listener that seems to do the trick in this case, so I have three things to do
1. implement __wakeup to make proxies' load work
2. implement a constructor
and
3. add a postLoad Listener.

Lot's of code for a simple $this->collection = new ArrayCollection();

Comment by Marco Pivetta [ 07/Oct/14 ]

Can you code this as a failing test case? Fixing it should be trivial afterwards.

Also, which version is affected?

Comment by Christophe Coevoet [ 13/Oct/14 ]

__wakeup is not a way to hook in the loading of the entity for Doctrine. The way to hook into the loading of the entity is to use the postLoad lifecycle callback.

Calling __wakeUp when initializing the proxy would be abusing this method, as it has a different purpose in PHP.

Comment by Marco Pivetta [ 13/Oct/14 ]

Christophe Coevoet we currently use __wakeup for transient properties wakeup on proxy initialization...

Comment by Marco Pivetta [ 13/Oct/14 ]

As an example:

class Foo
{
    /** @Id @Column */
    private $bar;
    private $transientField;

    public function __construct()
    {
        $this->transientField = new SomeUtil();
    }

    public function __wakeup()
    {
        $this->transientField = new SomeUtil();
    }
}

This is expected __wakeup usage. Is this broken for you, Uwe Jäger?

Comment by Uwe Jäger [ 13/Oct/14 ]

This is broken when the entity was loaded before via a relation and the proxy is not initialized. Doing a find in the same request finds the proxy in UoWs identityMap but __wakeup is not called then, so the property is not initialized.

Comment by Marco Pivetta [ 13/Oct/14 ]

Uwe Jäger is it actually a proxy? Or just an entity? Proxy initialization happens if __wakeup is defined as of https://github.com/doctrine/doctrine2/blob/3ca0dae6062f13b448f9b5f154cf9690d24a1913/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L138

Comment by Uwe Jäger [ 13/Oct/14 ]

It is a proxy, please check https://github.com/doctrine/doctrine2/blob/3ca0dae6062f13b448f9b5f154cf9690d24a1913/lib/Doctrine/ORM/UnitOfWork.php#L2552, there __wakeup is not called.

Comment by Marco Pivetta [ 13/Oct/14 ]

Uwe Jäger that is indeed a bug. Checking reflection there seems to be a bit too performance-heavy.

A test for that would be (pseudo):

class Foo
{
    /** @Id @Column */
    public $id;
    public $transientField;

    public function __construct()
    {
        $this->transientField = 123;
    }

    public function __wakeup()
    {
        $this->transientField = 123;
    }
}
$foo = new Foo();

$em->persist($entity);
$em->flush();
$em->clear();

$entity = $em->getReference('Foo', $foo->id);
$em->createQuery('SELECT f FROM Foo f')->setHint(AbstractQuery::HINT_REFRESH, true)->getResult();

$this->assertInstanceOf('...Proxy', $entity);
$this->assertTrue($entity->__isInitialized());
$this->assertSame(123, $entity->transientField);




[DDC-2089] Modify OneToMany to allow unidirectional associations without the need of a JoinTable Created: 19/Oct/12  Updated: 13/Oct/14

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

Type: Improvement Priority: Major
Reporter: Enea Bette Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: onetomany, persister, unidirectional
Environment:

Debian Wheezy, Mysql 5.1, Apache2, PHP 5.4



 Description   

As I sayd in the title, it would be nice if the ORM layer could permit to map a 1:n association in the db as an unidirectional OneToMany in the classes, without using a JoinTable in the database.
This would permit us to get rid of the unnecessary database JoinTable, which creates disorder and decreases performance for no valuable reason.

Is it possible?



 Comments   
Comment by Enea Bette [ 16/Dec/12 ]

A little up... for inspiration from JPA

http://en.wikibooks.org/wiki/Java_Persistence/OneToMany#Undirectional_OneToMany.2C_No_Inverse_ManyToOne.2C_No_Join_Table_.28JPA_2.0_ONLY.29

Comment by Daniel Pitts [ 07/Oct/14 ]

This is also a big issue for Symfony2 forms. It's very difficult to make a form type for a collection of "things", where the "things" are fully owned by the parent object.





[DDC-3347] [GH-1157] Fixing calls of schema-update tools Created: 12/Oct/14  Updated: 13/Oct/14  Resolved: 13/Oct/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 gennadiylitvinyuk:

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

Message:

composer-generated binaries should be called without php interpreter.

Added reminder to update schema.






[DDC-3348] [GH-1158] Update QueryBuilder reference documentation. Created: 12/Oct/14  Updated: 13/Oct/14  Resolved: 13/Oct/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 josemalonsom:

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

Message:

  • Updated the signature of methods "from", "innerJoin" and "leftJoin"
    since it does not match the actual implementation.
  • Added reference to the "join" method.


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

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

Comment by Doctrine Bot [ 13/Oct/14 ]

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





[DDC-717] Do not use files when using proxy autogeneration Created: 22/Jul/10  Updated: 13/Oct/14  Resolved: 20/Aug/13

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

Type: Improvement Priority: Major
Reporter: Jaka Jancar Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 2
Labels: None

Issue Links:
Reference
is referenced by DDC-2210 PHP warning in ProxyFactory when rena... Resolved

 Description   

Proxy classes are generated in less than 1ms for me. I prefer to not have a "build" step to reducing loading time by a milisecond, so I use autogenerate.

For users like me, wouldn't it be nicer if we wouldn't even have to configure a proxy dir and those files were never written (since they're not read more than once anyway)?



 Comments   
Comment by Jaka Jancar [ 22/Jul/10 ]

This very minimal patch removes the use of these temporary files:

--- library/Doctrine/ORM/Proxy/ProxyFactory.php	(revision 2)
+++ library/Doctrine/ORM/Proxy/ProxyFactory.php	(working copy)
@@ -78,9 +78,8 @@
         $fqn = $this->_proxyNamespace . '\\' . $proxyClassName;
 
         if ($this->_autoGenerate && ! class_exists($fqn, false)) {
-            $fileName = $this->_proxyDir . DIRECTORY_SEPARATOR . $proxyClassName . '.php';
-            $this->_generateProxyClass($this->_em->getClassMetadata($className), $proxyClassName, $fileName, self::$_proxyClassTemplate);
-            require $fileName;
+            $file = $this->_generateProxyClass($this->_em->getClassMetadata($className), $proxyClassName, null, self::$_proxyClassTemplate);
+            eval('?>'.$file);
         }
 
         if ( ! $this->_em->getMetadataFactory()->hasMetadataFor($fqn)) {
@@ -144,6 +143,9 @@
 
         $file = str_replace($placeholders, $replacements, $file);
 
+        if ($fileName === null)
+            return $file;
+
         file_put_contents($fileName, $file);
     }
 
Comment by Benjamin Eberlei [ 23/Jul/10 ]

The proxy dir is used for the "doctrine orm:generate-proxies" command in the case of "autogenerate= false", so you need to define it anyways.

You have to use proxies, the option is not for Proxy yes/no. If you have autogenerate=false and doctrine requires a proxy for a use case but can't find it you will get a fatal error.

Comment by Benjamin Eberlei [ 23/Jul/10 ]

I just saw the eval() keyword, ieeks It could maybe be a convenience option for those that don't want to use proxy direcotiries, however i am not sure.

Comment by Jaka Jancar [ 23/Jul/10 ]

eval() is no different than writing code to a file and using require().

When using runtime-generated proxies, there are no benefits (that I know of) from writing them to a file. The disadvantages are:

  • slower because of write disk access
  • has problems with high concurrency, unless special care is taken (DDC-716)
  • potentially has permission problems if code is executed by different users (e.g. nobody for a daemon and www-data for http)
  • requires setup of a writable directory

This is a nicer patch, which makes _generateProxyClass() return a string, just like other _generate* methods:

--- library/Doctrine/ORM/Proxy/ProxyFactory.php	(revision 2)
+++ library/Doctrine/ORM/Proxy/ProxyFactory.php	(working copy)
@@ -78,9 +78,8 @@
         $fqn = $this->_proxyNamespace . '\\' . $proxyClassName;
 
         if ($this->_autoGenerate && ! class_exists($fqn, false)) {
-            $fileName = $this->_proxyDir . DIRECTORY_SEPARATOR . $proxyClassName . '.php';
-            $this->_generateProxyClass($this->_em->getClassMetadata($className), $proxyClassName, $fileName, self::$_proxyClassTemplate);
-            require $fileName;
+            $code = $this->_generateProxyClass($this->_em->getClassMetadata($className), $proxyClassName);
+            eval($code);
         }
 
         if ( ! $this->_em->getMetadataFactory()->hasMetadataFor($fqn)) {
@@ -107,19 +106,19 @@
         foreach ($classes as $class) {
             $proxyClassName = str_replace('\\', '', $class->name) . 'Proxy';
             $proxyFileName = $proxyDir . $proxyClassName . '.php';
-            $this->_generateProxyClass($class, $proxyClassName, $proxyFileName, self::$_proxyClassTemplate);
+            $code = $this->_generateProxyClass($class, $proxyClassName);
+            file_put_contents($proxyFileName, "<?php\n" . $code);
         }
     }
 
     /**
      * Generates a proxy class file.
      *
-     * @param $class
-     * @param $originalClassName
+     * @param ClassMetadata $class
      * @param $proxyClassName
-     * @param $file The path of the file to write to.
+     * @return string The code of the generated methods.
      */
-    private function _generateProxyClass($class, $proxyClassName, $fileName, $file)
+    private function _generateProxyClass(ClassMetadata $class, $proxyClassName)
     {
         $methods = $this->_generateMethods($class);
         $sleepImpl = $this->_generateSleep($class);
@@ -142,9 +141,9 @@
             $methods, $sleepImpl
         );
 
-        $file = str_replace($placeholders, $replacements, $file);
+        $file = str_replace($placeholders, $replacements, self::$_proxyClassTemplate);
 
-        file_put_contents($fileName, $file);
+        return $file;
     }
 
     /**
@@ -244,8 +243,7 @@
 
     /** Proxy class code template */
     private static $_proxyClassTemplate =
-'<?php
-
+'
 namespace <namespace>;
 
 /**
Comment by Benjamin Eberlei [ 24/Jul/10 ]

Scheduled usage of eval() for 2.1, if the following conditions exist:

1. Autogenerate is set to TRUE
2. No Proxy Directory is configured.

Comment by Jaka Jancar [ 24/Jul/10 ]

Great, this is even better. This way you can have 1) autogenerated in ram-only, 2) autogenerated in files and 3) pregenerated.

And the minimal amount of config needed to get up and running is reduced, which is always nice.

Comment by Benjamin Eberlei [ 24/Jul/10 ]

you should know though, eval is dead slow. It generates the necessary proxies on EACH request and that cannot be cached in APC.

Comment by Jaka Jancar [ 24/Jul/10 ]

It's no slower than current autogeneration (file_put_contents+require). TBH, I don't know why anyone would want to use that over eval(), but I don't mind it being there.

Pre-generation is, of course, a different thing. Seems like a valid tradeoff to offer: build/a bit of config/better perfomance vs. no build/no config/potentially slower.

Comment by Benjamin Eberlei [ 24/Jul/10 ]

Yes, that is because file_put_contents + require is a development only strategy. The manual clearly states that autogenerate has to be false in production.

Comment by Roman S. Borschel [ 12/Aug/10 ]

Using eval() instead of producing and requiring the file in the case of enabled auto-generation of proxy classes sounds like a good improvement for 2.1 to make proxies more transparent during deveopment and for anyone for whom performance is no issue.

I'm increasing the priority as I think it is easy to implement for 2.1 and a good enhancement.

Comment by Karsten Dambekalns [ 09/Feb/11 ]

A note on why having the proxies written to a file can be useful even with autogenerate being on: it makes it really easy to check the proxy code being generated. I use that a lot currently.

The solution suggested, giving three possibilities is cool, though.





[DDC-2210] PHP warning in ProxyFactory when renaming proxy file Created: 20/Dec/12  Updated: 13/Oct/14  Resolved: 13/Oct/14

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

Type: Improvement Priority: Major
Reporter: Matthieu Napoli Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows


Issue Links:
Reference
relates to DCOM-186 [GH-269] ProxyGenerator eval() proxy ... Resolved
relates to DCOM-209 [GH-291] [DDC-717] Add eval() and FIL... Resolved
relates to DDC-717 Do not use files when using proxy aut... Resolved

 Description   

Getting a PHP Warning:

rename(**/models/Proxies_CGAF_Model_Component_Group.php.50d2dd2c079bb9.35271255,**/models/Proxies__CG_AF_Model_Component_Group.php):

in ProxyFactory line 194.

I haven't more information in the warning.

This is the moment when the ProxyFactory writes the proxy to a temporary file and then tries to rename the temp file to the correct file.

This warning appears randomly, but mostly on pages with lots of concurrent AJAX requests. I guess this happens because several requests try to write the proxy file at the same time. I get this warning but the app works fine.

This happens in dev environment, on a Windows machine.

I don't know why rename generates a warning, it should just return false... The doc doesn't say anything about warnings (except for long file names, but I checked even with the full path this is around 135 characters, not 255).



 Comments   
Comment by Benjamin Eberlei [ 22/Dec/12 ]

Thats why you shouldn't generate proxies at runtime. The problem happens on windows, because the atomic rename operation doesn't work as perfectly there as on linux.

We cannot fix this in Doctrine.

Comment by Matthieu Napoli [ 24/Dec/12 ]

Benjamin Eberlei What do you mean "you shouldn't generate proxies at runtime"? I'm not in production, this is in dev. And I'm using the default configuration.

What I don't understand is why will Doctrine regenerate proxies on every request? The warning is reproductible, and even when no PHP entity has been touched.

Comment by Matthieu Napoli [ 27/Dec/12 ]

Benjamin Eberlei To simplify my previous message (I don't want to bury you under questions) I'll sum it up like that:

What can I do?

Thanks!

Comment by Matthieu Napoli [ 28/Feb/13 ]

Benjamin Eberlei ping: what can be done?

Can we suppress the error with @rename($tmpFileName, $fileName); ?

https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Proxy/ProxyGenerator.php#L287

I can make a PR if you think that's a valid solution.

Comment by Marco Pivetta [ 28/Feb/13 ]

Matthieu Napoli no, if you have warnings, please disable them via ini setting. With error suppression there, we may have further problems identifying more serious issues.

About proxy generation: that happens EVERY time in dev environments. Generate them once and disable it afterwards.

Comment by Matthieu Napoli [ 28/Feb/13 ]

Marco Pivetta OK I can disable the auto generation then (I'll have to remember to regenerate them when I edit the model).

Thanks for the feedback

Is that possible to make those proxies generate only if the entity file has been modified since the last generation? (only asking if can and should be done, I can look for implementing it myself if that's the case)

Comment by Marco Pivetta [ 28/Feb/13 ]

Matthieu Napoli that would be very obnoxious when changing entities often. I wouldn't do that (generating only if not already available)

Comment by Matthieu Napoli [ 28/Feb/13 ]

Marco Pivetta Yes but for now they are regenerated at every request when in dev mode (at least with the default configuration http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/configuration.html#obtaining-an-entitymanager)

Which one is worse: generating every proxy class at every request, or generate only those which changed (in dev environment of course, not prod)?

If neither of these options are good (i.e. auto generation should be disabled), I don't understand why the docs say to enable auto generation when in dev environment.

Comment by Marco Pivetta [ 28/Feb/13 ]

Matthieu Napoli that's because in dev environments you shouldn't care about that one exception (usually happens when you got concurrent requests).

It is worse to generate only on changes: that's a lot of additional checks, variables to keep in memory and additional logic that is not needed.

Let's keep it as it is (generating at each request) for dev environments: works fine

Another (eventual) solution for dev environments would be not to write the proxy file, but to eval it.

Comment by Matthieu Napoli [ 28/Feb/13 ]

eval it would be a good solution IMO, no more "woops the directory is not writable" and it's more neutral for the user filesystem (but not as easy to debug). But OK, I see what you mean, it works let's keep it that way.

Actually the problem on my setup is that PHP errors are turned into exceptions, so on an (poorly designed) AJAX treeview (lots of nodes to load => lots of requests), I end up with some nodes not loaded because of the exception. And it feels weird to either silently log all PHP warnings or silently ignore the specific warning for the rename.

Comment by Marco Pivetta [ 28/Feb/13 ]

Matthieu Napoli I'd go with `eval` then. Needs refactoring of the abstract proxy factory and of the proxy generator (proxy generator should no longer write files).

Comment by Marco Pivetta [ 28/Feb/13 ]

Re-opening: the proxy factory could directly `eval()` the produced proxy code. The ProxyGenerator should no longer write the generated files to disk automatically.

Comment by Matthieu Napoli [ 28/Mar/13 ]

I've opened a PR: https://github.com/doctrine/common/pull/269

Comment by Oleg Namaka [ 16/Aug/13 ]

Thats why you shouldn't generate proxies at runtime. The problem happens on windows, because the atomic rename operation doesn't work as perfectly there as on linux.

  • In my case that is observed on a Linux machine (see http://www.doctrine-project.org/jira/browse/DDC-2613). If the rename operation is atomic then why it still happens? As I indicated in the description it's because of the way uniqid function works.
  • Is there a plan to merge the PR in this ticket? The fix in it would eliminate my issue whatsoever.
Comment by Doctrine Bot [ 20/Aug/13 ]

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

Comment by Marco Pivetta [ 13/Oct/14 ]

This issue does not need a resolution anymore, as we allow using eval() as proxy generation strategy in 2.5.





[DDC-3341] SessionValidator gives an error message on orderBy association, but it is no error. Created: 07/Oct/14  Updated: 13/Oct/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: Tobias Feijten Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orderBy, orm


 Description   

For @OrderBy annotations, the \Doctrine\ORM\Tools\SchemaValidator only checks if a field with the designated name exists at the designated Entity.
In the case of ordering on an association, defined in the target Entity, this is of course not the case, rendering an error like "The association Idb\TicketBundle\Entity\Ticket#ticketReservations is ordered by a foreign field ticketreservationtype_id that is not a field on the target entity Idb\TicketBundle\Entity\TicketReservation"
However, the \Doctrine\ORM\Persisters\BasicEntityPersister\getOrderBySQL function perfectly supports associations to order on.
Therefore, the error message should not be given when using an association existing at the designated Entity, as it's working and no mistake.
Could this be fixed?



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

Tobias Feijten provide a failing test case to demonstrate the problem first

Comment by Tobias Feijten [ 07/Oct/14 ]

Idb\TicketBundle\Entity\Ticket

namespace Idb\TicketBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

class Ticket {

  /**
   * @ORM\OneToMany(targetEntity="Idb\TicketBundle\Entity\TicketReservation", mappedBy="ticket", cascade={"persist","remove"})
   * @ORM\OrderBy({"ticketReservationType" = "ASC", "amount" = "DESC"})
   */
  private $ticketReservations;

}

Idb\TicketBundle\Entity\TicketReservation

namespace Idb\TicketBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

class TicketReservation {

  /**
   * @ORM\ManyToOne(targetEntity="Idb\TicketBundle\Entity\TicketReservationType")
   * @ORM\JoinColumn(name="ticketreservationtype_id", referencedColumnName="id")
   */
  private $ticketReservationType;

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

}

The orderBy on amount gives no error when validating the schema, the orderBy on ticketReservationType does (* The association Idb\TicketBundle\Entity\Ticket#ticketReservations is ordered by a foreign field ticketReservationType that is not a field on the target entity Idb\TicketBundle\Entity\TicketReservation).
However, the orderBy statement is not wrong as it is carried out perfectly when using the code.
The only problem is when validating.

Comment by Tobias Feijten [ 13/Oct/14 ]

Marco Pivetta Any progress on this one yet? Or do you need more information?

Comment by Marco Pivetta [ 13/Oct/14 ]

Any progress on this one yet?

No, no progress so far, and I can't allocate time for D2 over the next few weeks.
As for the information amount, it seems sufficient to me: we are probably just using field mappings without checking association mappings when looking for order fields. There is still a problem about what to do with composite identifiers or derived identifiers, but it should be covered by tests first.





[DDC-1927] Pagination of a SELECT of specific fields results in a RuntimeException Created: 16/Jul/12  Updated: 12/Oct/14  Resolved: 25/Nov/12

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: Zacharias Luiten Assignee: Benjamin Eberlei
Resolution: Can't Fix Votes: 0
Labels: paginator


 Description   

When paginating a DQL string which selects specific fields it results in the following error: PHP Fatal error: Uncaught exception 'RuntimeException' with message 'Not all identifier properties can be found in the ResultSetMapping: id'

NOT working: 'SELECT c.id, c.number FROM Application\Entity\Course c'
WORKING: 'SELECT c FROM Application\Entity\Course c'
WORKING: 'SELECT c, c.id, c.number FROM Application\Entity\Course c'

Setting hydration mode to scalar results makes no difference.

Gist to example code and stack trace: https://gist.github.com/d5cd6d0b0ac28e722dd7



 Comments   
Comment by Benjamin Eberlei [ 29/Jul/12 ]

First results: This is very complicated to support, the pagination was designed for entity results. I have to check this when I have more time.

Comment by dquintard [ 08/Aug/12 ]

Hi Benjamin,
I can change my code to select entity results (even for hundreds/thousands results).
But for now Pagination is not usable with ResultSetMapping::addScalarResult

Comment by Matt Pinkston [ 13/Nov/12 ]

The reason this error occurs is because the Paginator creates its own ResultSetMapping and relies on the SqlWalker to configure it (see Doctrine\ORM\Query\SqlWalker::walkSelectExpression).

Doctrine will interpret each field in the first example (SELECT c.id, c.number...) as a PathExpression and add it to the result set mapping as a scalar result. This makes it impossible for the paginator to reliably know which field can be considered an identifier.

A quick fix might be to re-write the query to use PartialObjectExpression: SELECT partial c.

{id, number}

...

(edited after a re-read and realization that a custom ResultSetMapping wouldn't cut it)

Comment by Benjamin Eberlei [ 25/Nov/12 ]

Allowing generic+complex pagination on scalar results is impossible for us, closing as can't fix.

Just use LIMITs yourself here or as suggested partial objects.

Comment by Stefano [ 18/Apr/13 ]

imho this pagination feature is quite useless if we are forced to fetch the complete Entity. Take for example a big table with a lot of data: extracting all the infos will take a lot of time... There should be a way to support the first query type

Comment by Busta Rhymes [ 10/Sep/13 ]

Did i miss something about Doctrine 2 ? What is the point if we can't use pagination? Selecting only several/needed fields is as standard practice as brushing your teeth every day. And pagination doesn't work when i select only specific fields (it throws 'Not all identifier properties can be found in the ResultSetMapping: id' error). I also thought that `$query->setFirstResult(20);` and `$query->setMaxResults(100);` works fine with joins but it turns out it doesn't work. It looks too complicated to integrate such common tool as pagination (I'm switching from CakePHP based ORM which works just fine with any kind of joins etc, no problems with pagination so far, but we are switching to Symfony 2 which goes with Doctrine 2 and actually i was recommended to use Doctrine 2, but i clearly see solid problems atm :/)

Comment by Zacharias Luiten [ 10/Sep/13 ]

@Busta Rhymes - Use partial entities (only the data of the fields you specify is fetched and set in the entity). As pagination is most of the time used just for displaying data, one is fine with that.

Comment by Thomas Godar [ 23/Oct/13 ]

I was pretty disappointed with this resolution. I fail to see how the tasks of a paginator fail to work with Query object foo yet work with Query object bar. They are the same objects. I would think a query is a query for the intent and purpose of the paginator, get a count, set limit and offset, give me back the page of results. All the more so if that Query has HydrationMode set to an array.

What does "generic+complex pagination" even mean?

Comment by Marco Pivetta [ 23/Oct/13 ]

As discussed in private, the problem is that doctrine needs a selected root entity in a DQL query in order to paginate the results.

That's a current limitation that cannot be worked around.

What could be done is giving a "meaning" to scalars being selected, so that they are upgraded to (for example) identifiers of a particular root entity.

That is still not worth it given the amount of bugs and increase in LOC that spawns from it.

Comment by Steve Todorov [ 12/Oct/14 ]

For anybody who might be experiencing this issue, a possible workaround might be:

$paginator = new Paginator($query);
$paginator->setUseOutputWalkers(false);





[DDC-3346] findOneBy returns an object with partial collection for the properties with mapping oneToMany/Fetch Eager Created: 10/Oct/14  Updated: 10/Oct/14

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

Type: Bug Priority: Critical
Reporter: Adrien Russo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None


 Description   

findOneBy returns an object with partial collection for the properties with mapping oneToMany/Fetch Eager. This bug appear only for entities without inheritance.

Mapping
       
Test\Bar:
    type: entity
    table: bar
    fields:
        code:
            type: string
    oneToMany:
        posts:
            targetEntity: Test\Post
            fetch: EAGER
            mappedBy: bar
            cascade: ['all']
    
Test\Post:
    type: entity
    table: post
    fields:
        content:
            type: text
    manyToOne:
        bar:
            targetEntity: Test\Bar
            cascade: []
            joinColumn:
                name: bar_id
                referencedColumnName: id
Data
    
$bar = new \Test\Bar('foo');
$bar->addPost(
  new Test\Post('toto')
);
$bar->addPost(
  new Test\Post('tata')
);
 
$bar->getPosts()->count(); #value is 2
$manager->persist($bar);
$manager->flush();
FindOneBy with fetch eager
$bar = $repository->findOneBy(['code' => 'foo']);
$bar->getPosts()->count(); #value is 1
FindOneBy with fetch Lazy
$bar = $repository->findOneBy(['code' => 'foo']);
$bar->getPosts()->count(); #value is 2

I think this bug is due to the LIMIT 1 clause happening on findOneBy which also applies on joins generated here.

For instance, the generated SQL statement generated might look like

Sql Statement
SELECT
	t0. ID AS id_1,
	t0.code AS code_2,
	t1. ID AS id_3,
	t1.content AS content_4,
	t1.bar_id AS bar_id_5
FROM
	bar t0
LEFT JOIN post t1 ON t1.bar_id = t0. ID
WHERE
	t0. code = 'foo'
LIMIT 1





[DDC-1958] pager produces wrong results on postgresql Created: 30/Jul/12  Updated: 09/Oct/14  Resolved: 12/Nov/12

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

Type: Bug Priority: Major
Reporter: Miha Vrhovnik Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: paginator
Environment:
  • Postgres 9.1, 9.2
  • PHP 5.4

Issue Links:
Reference
is referenced by DDC-3336 Undefined property: Doctrine\ORM\Quer... Open
Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-2593 Same bug occurs in MariaDB 5.5 Sub-task Resolved Marco Pivetta  
DDC-2729 Same bug affects SQLServer2008Platform Sub-task Open Benjamin Eberlei  

 Description   

The query build by pager to get the subset of PKs to fetch produces wrong results on potgresql (and probably any database), that conforms to the SQL standard. The standard says, that if you wish to have the results in specific order, then you have to specify that by using an ORDER BY clause. If such a clause is not present the database can return the results in whatever order it sees fit.

Testcase fixtures:

CREATE TABLE test (
    id integer,
    name text
);

INSERT INTO test VALUES (1, 'c');
INSERT INTO test VALUES (2, 'a');
INSERT INTO test VALUES (3, 'e');
INSERT INTO test VALUES (4, 'b');
INSERT INTO test VALUES (5, 'd');
INSERT INTO test VALUES (6, 'a');
INSERT INTO test VALUES (7, 'g');
INSERT INTO test VALUES (8, 'h');
INSERT INTO test VALUES (9, 'e');
INSERT INTO test VALUES (10, 'j');

Passing f.e.

$qb = $this->repository
    ->createQueryBuilder('t')
    ->select('t')
    ->setFirstResult(0)
    ->setMaxResults(5)
    ->addOrderBy('t.name', 'ASC')

to pager produces SQL like this modified for readability

SELECT DISTINCT id FROM (
    SELECT id, name FROM test ORDER BY name
  ) dctrn_result
  LIMIT 5 OFFSET 0

Now there is nothing wrong with this modified query per se, but there is no ORDER BY clause in the outer query so according to the standard the DB can choose whatever order it seems fit. Now mysql chooses the same order, but postgresql does not and it's probably not the only DB doing so.

If you are interested in the results, this is the output I'm seeing:

  • postgresql: 8,4,1,5,3
  • mysql : 2,6,4,1,5

I and my coworker came to the standard compliant solution it was also tested on the dataset above on both postgresql and mysql and it produced equal results. We have found only one corner case this won't work and IMHO that can't be fixed. The problem is when you do a sort on a field from a table that is in 1:n relation to the main table.. e.g tables posts and tags, where one post can have a multiple tags and you want your results sorted by a tag.

Recipe for a correct query is:

  • remember the ORDER BY fields from original query and then remove them
  • wrap the original query with a DISTINCT query, but add the fields from ORDER BY to the SELECT part of that query and add the whole ORDER BY to the end of it, also add the PK to the order by clause, and add the LIMIT clause
  • wrap the resulting query into another query and select just the id.

so if I take the example from above the SQL should look like this:

SELECT id FROM (
  SELECT DISTINCT id, name FROM (
    SELECT id, name FROM test
  ) dctrn_result_inner
  ORDER BY name, id LIMIT 5 OFFSET 0
) dctrn_result


 Comments   
Comment by Jean-Philippe THEVENOUX [ 08/Nov/12 ]

I reproduce same problem with Postgres 7.4, Doctrine 2.3 whereas with doctrine 2.2, all is fine
Hope there'll a fix in next doctrine version

Comment by Raymond Kolbe [ 09/Apr/13 ]

http://www.doctrine-project.org/jira/browse/DDC-1800 This relates.

I just published a PR for an Oracle fix, but your solution appears to work for Oracle as well (issue is the same).

Comment by Bojidar Hristov [ 06/Aug/13 ]

Same bug occurs in MariaDB 5.5.

I commented out check for PostgreSQL and it works fine. Can you fix it for MariaDB too? Thanks

Comment by Guilherme Santos [ 21/Aug/14 ]

I make a ORDER BY with a HIDDEN field and this still happen to me! Like this:
$qb->addSelect('CASE WHEN p.description LIKE :description THEN 0 ELSE 1 END HIDDEN relevance')->addOrderBy('relevance');

This order by is ignored causing the same error!

In this line https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/SqlWalker.php#L1310
you don't add to ResultSetMapping so when you verifying in function preserveSqlOrdering the field doesn't exists!

Comment by Liam O'Boyle [ 16/Sep/14 ]

I've just been bitten by the "corner case" described above, "the problem is when you do a sort on a field from a table that is in 1:n relation to the main table.. e.g tables posts and tags, where one post can have a multiple tags and you want your results sorted by a tag.".

This is a pretty significant bug, as the end result is that data that should come back from the query doesn't. While there probably isn't a good universal workaround, the MySQL behaviour before this was already correct because the outer query was returning the ids in the same order as the internal query (even though it isn't required to by the standard). Is it possible to avoid having this apply to MySQL so that it doesn't introduce an additional bug in an attempt to fix an issue that doesn't apply to that platform anyway?

Comment by Miha Vrhovnik [ 16/Sep/14 ]

@Liam As you can se above the same applies to mariadb and if you look at the issues on the githubs doctrine project page you'll see that there is the same problem with newer mysql releases. AS I've written above. this corner case cannot be solved.

Comment by Liam O'Boyle [ 16/Sep/14 ]

Thanks Miha. I couldn't find this on the github page so didn't realise that it was affecting some newer MySQL releases (it didn't seem to affect mine, 5.5). If that's the case, then as you point out it can't even be fixed for MySQL.

Perhaps the lack of support could be more explicit instead? If you attempt to use the paginator with two FROM tables then a RuntimeException is thrown, if we did the same when the ORDER BY conditions applied to tables joined via a 1:m relationship then at least users would know that things were going wrong rather than getting strangely unpredictable results.





[DDC-3339] [GH-1154] Hotfix/php 5.6 serialization fix Created: 06/Oct/14  Updated: 06/Oct/14  Resolved: 06/Oct/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4, 2.4.1, 2.4.2, 2.4.3, 2.4.4, 2.4.5
Fix Version/s: 2.4.6
Security Level: All

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

Issue Links:
Reference
relates to DDC-3120 Warning: Erroneous data format for un... Resolved

 Description   

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

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

Message:

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

This PR provides a backport for the 2.4 branch



 Comments   
Comment by Steve Müller [ 06/Oct/14 ]

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

Comment by Dominik Zogg [ 06/Oct/14 ]

Thx you





[DDC-3120] Warning: Erroneous data format for unserializing PHP5.6+ Created: 11/May/14  Updated: 06/Oct/14  Resolved: 27/Aug/14

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

Type: Bug Priority: Critical
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


Issue Links:
Duplicate
is duplicated by DDC-3252 [GH-1109] DDC-3120 - PHP 5.6-RC3 comp... Resolved
Reference
is referenced by DDC-3156 [GH-1050] DDC-3120 -- Catch Reflectio... Resolved
is referenced by DDC-3339 [GH-1154] Hotfix/php 5.6 serializatio... Resolved

 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.

Comment by Chase Noel [ 12/Aug/14 ]

Im still getting this error running php 5.6RC2 and the dev-master(6ac19b04bfbd7a97aad5ed8c2abd6279ff5e0022) build of D2/orm. Am i missing something?

Comment by Marco Pivetta [ 12/Aug/14 ]

This was semi-fixed in PHP5.6-RC3, and it will be patched into ORM once doctrine/instantiator is out

Comment by Chase Noel [ 12/Aug/14 ]

Ok good to know. Thanks

Comment by Marco Pivetta [ 13/Aug/14 ]

Not yet fixed for PHP 5.6

Comment by Marco Pivetta [ 14/Aug/14 ]

Provided a hotfix proposal at https://github.com/doctrine/doctrine2/pull/1109 - please check it out with PHP 5.6.0-RC3 or later

Comment by Doctrine Bot [ 27/Aug/14 ]

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

Comment by Marco Pivetta [ 27/Aug/14 ]

Due to a new introduced dependency, this issue will only be solved for PHP 5.6 in 2.5.0 and later.

Comment by Doctrine Bot [ 28/Aug/14 ]

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

Comment by Dominik Zogg [ 10/Sep/14 ]

@ocramius would be great if there where backports for 2.4 and 2.3

Comment by Attila Bukor [ 28/Sep/14 ]

I agree with Dominik, we'd like to use the latest stable version and would need this patch.

Comment by Marco Pivetta [ 06/Oct/14 ]

This has been backported in DDC-3339





[DDC-3337] Changes in @UniqueConstraint annotation are not synced by orm:schematool Created: 06/Oct/14  Updated: 06/Oct/14

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

Type: Bug Priority: Minor
Reporter: Andreas Goetz Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

If the only metadata cahnges is the uniqueconstraint annotation, e.g. the contraint name, orm:schema is not able to sync this hcange to the database.
Instead, it claims "nothing to do".






[DDC-3335] Merge with value object causes notice Created: 03/Oct/14  Updated: 03/Oct/14

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

Type: Bug Priority: Major
Reporter: David de Boer Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This:

// Assume Location is some value object
$valueObject = new Location(); // or e.g. new \stdClass()
$em->merge($valueObject);

causes this:

Notice: Undefined offset: 0 in /vagrant/api/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 729

While I agree merge shouldn't work for value objects, wouldn't it be better to throw an exception when ClassMetadataInfo tries to find an identifier that isn't there?






[DDC-3324] [GH-1147] Extended the docs for mapping attributes precision and scale Created: 25/Sep/14  Updated: 02/Oct/14  Resolved: 02/Oct/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: 1
Labels: None


 Description   

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

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

Message:

I for myself am always confused about precision and scale and have to lookup what is the numer of maximum digits and what is the number for digits right of the decimal point. Other people seem to have the same [problem](http://stackoverflow.com/questions/14940574/what-do-scale-and-precision-mean-when-specifying-a-decimal-field-type-in-doctrin).

So I have extended the docs to make it more clear.



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

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

Comment by Doctrine Bot [ 02/Oct/14 ]

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





[DDC-3334] Allow to set @Id in @AttributeOverride Created: 02/Oct/14  Updated: 02/Oct/14

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

Type: Improvement Priority: Minor
Reporter: Jakob Schumann Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: annotation, orm, primary-key


 Description   

Hello!

@AttributeOverride only allows to change the column definition of a property that is defined in a parent class or trait. It is not possible to define such an "foreign" column (through inheritance/trait) as ID column and also there is no possibility define the primary key through any other annotation.

It would be greatly useful to extend the @AttributeOverride to allow specification of @ID, @GeneratedValue and @CustomIdGenerator in this annotation as those are also property/attribute related and there is no reason those should not be overrideable.

Example:

trait ForeignColumn
{
    /**
     * @ORM\Column(type="string", nullable=true)
     */
    protected $foreignColum = null;
}

/**
 * @ORM\Entity()
 * @ORM\AttributeOverrides({
 *      @ORM\AttributeOverride(name="foreignColum",
 *          column=@ORM\Column(type="string", nullable=false),
 *      )
 * })
 */
class MyEntity {
  use ForeignColum;

    /**
     * @ORM\Id
     * @ORM\Column(type="string", nullable=false)
     */
    protected $myColum = null;
}

In this example it is not possible to add the property to the class again and annotate it directly as this would throw a Strict Error as trait properties cannot be overwritten.

It is also not possible to create a composite key with foreignColumn and myColumn (and it is also not be possible to define only foreignColumn as primary key without modifying the trait).






[DDC-3333] doctrine:schema:update --complete does not detect old index Created: 02/Oct/14  Updated: 02/Oct/14

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

Type: Bug Priority: Minor
Reporter: Grégoire Paris Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: postgresql, schematool
Environment:

Ubuntu 14.04, PostgreSQL 9.3



 Description   

When changing the name of an index and using the symfony proxy command doctrine:schema:update --complete --dump-sql, the output only shows a CREATE statement. I would expect to also see a DROP statement. Here is what my index definition looks like :

    indexes:
        admin_entity_created_at_index:
            columns: [ createdAt ]





[DDC-3332] [GH-1152] Adds error message when the key is composite Created: 02/Oct/14  Updated: 02/Oct/14

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

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


 Description   

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

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

Message:

An example is:

```
SELECT u FROM User u INNER JOIN Address a ON a.user = u
```

When User has a composite key.



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

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





[DDC-2794] the Paginator does not support arbitrary join Created: 14/Nov/13  Updated: 01/Oct/14  Resolved: 22/Sep/14

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

Type: Improvement Priority: Major
Reporter: Christophe Coevoet Assignee: Marco Pivetta
Resolution: Fixed Votes: 3
Labels: paginator

Issue Links:
Dependency
depends on DDC-3233 [GH-1092] Arbitrary Join count walker... Resolved

 Description   

Using the following query with the paginator fails:

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

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

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



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

Hi,

I have the same issue.

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

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

Best,

Comment by Christophe Coevoet [ 23/Dec/13 ]

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

Comment by Glen Ainscow [ 30/Sep/14 ]

Is this going to be back-ported to 2.4.x?

Comment by Marco Pivetta [ 01/Oct/14 ]

No, this is actually a new supported feature: I'm changing the issue type.





[DDC-3330] Bad Pagination - rows with sorted collection Created: 29/Sep/14  Updated: 29/Sep/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:

Ubuntu 12.04, PHP 5.5.3


Attachments: File DDC3330Test.php    

 Description   

I use the Doctrine Paginator to be able to have a correct pagination with collection.
I followed the documentation here:
http://doctrine-orm.readthedocs.org/en/latest/tutorials/pagination.html

It works well in most cases but there is a problem when ordering on a property of the entity + on an other property of the collection.

See the failing unit test I joined to this ticket.






[DDC-3327] [GH-1149] Update Composite.php for HHVM compatibility Created: 26/Sep/14  Updated: 26/Sep/14

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

Type: Bug Priority: Major
Reporter: 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 zhil:

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

Message:

Not sure, why this issue is not founded in unittests, but I got HHVM crushed with message
```
Fatal error: Stack overflow in ...../vendor/doctrine/orm/lib/Doctrine/ORM/Query/Expr/Composite.php on line 58
```
The same issue is being reported here
https://github.com/facebook/hhvm/issues/1747

@LinuxDoku proposed quick patch, which works great for me and its in this PR.

Just in case, if you wonder what trigger this error - here is my repository function, which trigger it
```
public function findOpenTeamTimeEntry($user)
{
$r = $this->createQueryBuilder("t")
->join("t.owner","u")
->where("t.dateEnd IS NULL")
->andWhere("u.id = :user_id")
>setParameter(":user_id",$user>getId())
->getQuery()
->getResult();
if(is_array($r) && count($r))

{ return $r[0]; }

else

{ return false; }

}
```






[DDC-3322] [GH-1146] Allow orderBy to reference associations Created: 23/Sep/14  Updated: 23/Sep/14

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

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


 Description   

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

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

Message:

If I specify an order-by clause on a to-many association, e.g. `@OrderBy(

{"foo" = "ASC"}

)`, where foo is a to-one-association on the target entity, the collection is sorted by foo_id (this behaviour is implemented in BasicEntityPersister::getOrderBySQL()).

This works fine. However, Doctrine\ORM\Tools\SchemaValidator complains that foo is not a field.

This change makes the validator accept order-by clauses on associations where the target entity is the owning side, and the association is single-valued (AFAICT this is the same restrictions that BasicEntityPersister uses).






[DDC-3321] [GH-1145] Minor performance tweaks Created: 23/Sep/14  Updated: 23/Sep/14  Resolved: 23/Sep/14

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

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

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

Message:

Function calls are expensive in PHP, this PR just removes unnecessary calls to `call_user_func()` when a direct `$variable()` call is possible.



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

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

Comment by Doctrine Bot [ 23/Sep/14 ]

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





[DDC-3319] Get the converted value in convertToDatabaseValueSQL() Created: 23/Sep/14  Updated: 23/Sep/14

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

Type: Bug Priority: Minor
Reporter: Benjamin Morel Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping


 Description   

I have a use case where it would be useful to get the value being converted in the convertToDatabaseValueSQL() method, not just in convertToDatabaseValue().

Take the following mapping for a Geometry type:

    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
        return $value->asBinary();
    }

    public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform)
    {
        return sprintf('ST_GeomFromWkb(%s, %s)', $sqlExpr, 4326);
    }

In GIS-enabled databases, ST_GeomFromWkb() takes two parameters: the WKB binary representation of the geometry, and an integer representing the SRID (coordinate system) of the geometry, in this example the hardcoded value 4326.

I would be nice to have access to the value being converted in the convertToDatabaseValueSQL() as well, to be able to get the SRID from the geometry object itself, and replace the above code with something like:

    public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform, $value)
    {
        return sprintf('ST_GeomFromWkb(%s, %s)', $sqlExpr, $value->srid());
    }

I don't think there is currently a technical way to do this (please correct me if I'm wrong).

Could we find a BC way to pass the value being converted to the convertToDatabaseValueSQL() method to add support for this use case?






[DDC-3314] Error with AttributeOverride when upgrading schema Created: 19/Sep/14  Updated: 23/Sep/14

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

Type: Bug Priority: Major
Reporter: JB Blanchon Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm


 Description   

I want to override an attribute from FOSuserBundle:User class with annotations.

My class extends BaseUser

SiteCustomer.php
class SiteCustomer extends BaseUser

My use statement is like this

SiteCustomer.php
use FOS\UserBundle\Model\User as BaseUser;

When I put the annotations on my entity

SiteCustomer.php
 /*
 * @ORM\AttributeOverrides({
 *     @ORM\AttributeOverride(name="emailCanonical",
 *         column=@ORM\Column(
 *             name="email_canonical",
 *             type="string",
 *             length=255,
 *             unique=false
 *         )
 *     )
 * })
 */

I get this error message :


MappingException: Invalid field override named 'emailCanonical' for class SiteCustomer.

I got the same error message, for usernameCanonical.
I need to override this field in order to remove the uniqness of the field
I use Doctrine v2.4.4 what is wrong with my annotation ? Why do I get this error when trying to upgrade my schema

Thank you



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

Did you try reaching where the exception is thrown? It typically says more about the specific failure.

Comment by JB Blanchon [ 23/Sep/14 ]
Stack Trace 1
  */
    public static function invalidOverrideFieldName($className, $fieldName)
    {
        return new self("Invalid field override named '$fieldName' for class '$className'.");
    }
    /**
[1] Doctrine\ORM\Mapping\MappingException: Invalid field override named 'emailCanonical' for class 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer'.
    at n/a
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/MappingException.php line 129

    at Doctrine\ORM\Mapping\MappingException::invalidOverrideFieldName('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', 'emailCanonical')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 2032

    at Doctrine\ORM\Mapping\ClassMetadataInfo->setAttributeOverride('emailCanonical', array('fieldName' => 'emailCanonical', 'type' => 'string', 'scale' => '0', 'length' => '255', 'unique' => false, 'nullable' => false, 'precision' => '0', 'columnName' => 'email_canonical'))
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php line 415

    at Doctrine\ORM\Mapping\Driver\AnnotationDriver->loadMetadataForClass('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', object(ClassMetadata))
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/Driver/MappingDriverChain.php line 103

    at Doctrine\Common\Persistence\Mapping\Driver\MappingDriverChain->loadMetadataForClass('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer', object(ClassMetadata))
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php line 117

    at Doctrine\ORM\Mapping\ClassMetadataFactory->doLoadMetadata(object(ClassMetadata), object(ClassMetadata), true, array('Ylly\CrmBundle\Entity\User'))
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php line 318

    at Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->loadMetadata('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php line 211

    at Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory->getMetadataFor('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 295

    at Doctrine\ORM\EntityManager->getClassMetadata('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php line 67

    at Doctrine\ORM\Repository\DefaultRepositoryFactory->createRepository(object(EntityManager), 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/Repository/DefaultRepositoryFactory.php line 50

    at Doctrine\ORM\Repository\DefaultRepositoryFactory->getRepository(object(EntityManager), 'Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php line 759

    at Doctrine\ORM\EntityManager->getRepository('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/src/Ylly/CmsBundle/Controller/CmsBaseController.php line 93

    at Ylly\CmsBundle\Controller\CmsBaseController->getRepo('Ylly\Extension\SiteCustomerBundle\Entity\SiteCustomer')
        in /home/jaybe/www/yProx/src/Ylly/Extension/SiteCustomerBundle/Controller/AdminController.php line 79

    at Ylly\Extension\SiteCustomerBundle\Controller\AdminController->getSiteCustomerRepo()
        in /home/jaybe/www/yProx/src/Ylly/Extension/SiteCustomerBundle/Controller/AdminController.php line 15

    at Ylly\Extension\SiteCustomerBundle\Controller\AdminController->indexAction()
        in  line 

    at call_user_func_array(array(object(AdminController), 'indexAction'), array())
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2952

    at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), '1')
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2924

    at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), '1', true)
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 3063

    at Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(object(Request), '1', true)
        in /home/jaybe/www/yProx/apps/bootstrap.php.cache line 2331

    at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
        in /home/jaybe/www/yProx/web/admin_dev.php line 14

Here is the stack trace of my error.
If this is not what you need, tell me what do you want and how to get it.
Thank you.





[DDC-3243] [GH-1099] Fixed a bug so that a versioned entity with a OneToOne defined as an id can be created Created: 07/Aug/14  Updated: 23/Sep/14  Resolved: 23/Sep/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 MajorCaiger:

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

Message:

Changed the visibility of UnitOfWork::flattenIdentifier for use in BasicEntityPersister.

In BasicEntityPersister::fetchVersionValue I have added a line to flatten the id's before fetching the version value.

Without this change, an entity with a OneToOne relationship defined as an Id, with a Version property, could not be created. Rather than trying to use the ID in the query to select the version, the related entity was being passed.



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

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





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

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

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

Issue Links:
Dependency
is required for DDC-2794 the Paginator does not support arbitr... Resolved

 Description   

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

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

Message:

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

Added a condition to test query component against SelectStatement from
clause



 Comments   
Comment by Christophe Coevoet [ 20/Aug/14 ]

This is a fix for DDC-2794

Comment by Doctrine Bot [ 22/Sep/14 ]

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

Comment by Doctrine Bot [ 22/Sep/14 ]

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





[DDC-2681] [GH-790] HHVM compatibility: func_get_args Created: 15/Sep/13  Updated: 22/Sep/14  Resolved: 15/Sep/13

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

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

Issue Links:
Reference
is referenced by DBAL-608 [GH-372] HHVM compatibility: func_get... Resolved
is referenced by DDC-3317 [GH-1142] func_get_args() call order ... Resolved

 Description   

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

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

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 [ 15/Sep/13 ]

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

Comment by Doctrine Bot [ 22/Sep/14 ]

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





[DDC-1870] [GH-372] [DDC-1845] QuoteStrategy Created: 12/Jun/12  Updated: 22/Sep/14  Resolved: 04/Jul/12

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

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


 Description   

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

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

Message:

      1. QuoteStrategy

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

This patch fix some quote problems using a default quote strategy and allows users find solutions themselves for weird quote cases.

This DBAL PR shoud be merged to fix sqlite tests in : https://github.com/doctrine/dbal/pull/158

There is a lote of new method calls, the performance tests in sqlite are the following :

        1. My branch :
          ```
          . testSimpleQueryScalarHydrationPerformance10000Rows - 0.37292098999023 seconds
          . testSimpleQueryArrayHydrationPerformance10000Rows - 0.50411009788513 seconds
          . testMixedQueryFetchJoinArrayHydrationPerformance10000Rows - 1.1323919296265 seconds
          . testSimpleQueryPartialObjectHydrationPerformance10000Rows - 1.0243051052094 seconds
          . testSimpleQueryFullObjectHydrationPerformance10000Rows - 4.1673181056976 seconds
          . testMixedQueryFetchJoinPartialObjectHydrationPerformance2000Rows - 0.40403699874878 seconds
          . testMixedQueryFetchJoinFullObjectHydrationPerformance2000Rows - 0.873291015625 seconds
          . 99 CompanyContract: 0.023395
          . 99 CompanyContract: 0.019528
          . Memory usage before: 111715.53125 KB
          . Memory usage after: 110282.875 KB
          . Inserted 10000 objects in 5.5240259170532 seconds
          . 100 CmsArticle findAll(): 0.018410
          . 100 CmsArticle findAll(): 0.014157
          . 100 CmsArticle find(): 0.043304
          . 100 CmsArticle find(): 0.041451
          . 100 CmsGroup: 0.009315
          . 100 CmsGroup: 0.009239
          . 100 CmsUser: 0.024051
          . 100 CmsUser: 0.023655
          . Compute ChangeSet 100 objects in 0.040482997894287 seconds

. Time: 19 seconds, Memory: 261.50Mb

```

        1. Doctrine Master :
          ```
          . testSimpleQueryScalarHydrationPerformance10000Rows - 0.37668490409851 seconds
          . testSimpleQueryArrayHydrationPerformance10000Rows - 0.5009880065918 seconds
          . testMixedQueryFetchJoinArrayHydrationPerformance10000Rows - 1.131824016571 seconds
          . testSimpleQueryPartialObjectHydrationPerformance10000Rows - 1.037791967392 seconds
          . testSimpleQueryFullObjectHydrationPerformance10000Rows - 4.1992859840393 seconds
          . testMixedQueryFetchJoinPartialObjectHydrationPerformance2000Rows - 0.41158103942871 seconds
          . testMixedQueryFetchJoinFullObjectHydrationPerformance2000Rows - 0.86575293540955 seconds
          . 99 CompanyContract: 0.023206
          . 99 CompanyContract: 0.020555
          . Inserted 10000 objects in 5.4995818138123 seconds
          . 100 CmsArticle findAll(): 0.018785
          . 100 CmsArticle findAll(): 0.014160
          . 100 CmsArticle find(): 0.042067
          . 100 CmsArticle find(): 0.041076
          . 100 CmsGroup: 0.009478
          . 100 CmsGroup: 0.010591
          . 100 CmsUser: 0.023727
          . 100 CmsUser: 0.023073
          . Compute ChangeSet 100 objects in 0.040009021759033 seconds

. Time: 19 seconds, Memory: 260.50Mb
```



 Comments   
Comment by Benjamin Eberlei [ 25/Jun/12 ]

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

Comment by Doctrine Bot [ 15/Sep/13 ]

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

Comment by Doctrine Bot [ 22/Sep/14 ]

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





[DDC-3317] [GH-1142] func_get_args() call order fix for HHVM bug Created: 22/Sep/14  Updated: 22/Sep/14  Resolved: 22/Sep/14

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.4.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 DBAL-608 [GH-372] HHVM compatibility: func_get... Resolved
relates to DDC-2681 [GH-790] HHVM compatibility: func_get... Resolved

 Description   

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

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

Message:

This PR fixes bugs in `Doctrine\ORM\QueryBuilder` where the values provided to method arguments to `::andWhere()`, `::orWhere()`, `::andHaving()`, and `::orHaving()` are overwritten by code within the methods in HHVM and PHP7.

After much fun and headscratching in both #doctrine and #hhvm on Freenode, we discovered that in the following code, `$where = $this->getDqlPart('where');` overwrites the values stored internally for the `$where` parameter of the function which is returned by `func_get_args()`:

public function orWhere($where)

{ $where = $this->getDqlPart('where'); $args = func_get_args(); }

This means that instead of `$args` being set as expected to an array containing the string or object provided to the function, it actually contains the object returned by `QueryBuilder::getDqlPart()`, which causes all the problems you'd expect it to.

This PR simply swaps the order of the calls so that the function arguments are retrieved via `func_get_args()` before the `$where` variable is modified, fixing the problem.



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

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





[DDC-3316] [GH-1141] Always allow proxies on ToOne associations Created: 22/Sep/14  Updated: 22/Sep/14

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

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


 Description   

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

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

Message:

Hi!
This patch combined with https://github.com/doctrine/common/pull/338 will allow to have proxies for long chains of ToOne associations:

```
User

{ private $id; // @id private $city; private $name; }

City

{ private $id; // @id private $region; // @id private $name; }

Region

{ private $id; // @id private $country; // @id private $name; }

Country

{ private $id; // @id private $name; }

```

```php
$user = $repo->find(1);

// the current implementation must load the city, region
$user->getCity()>getRegion()>getCountry();
// the current implementation must load the city, region and the country
$user->getCity()>getRegion()>getCountry()->getName();

//with this patch
// here no queries will be executed
$user->getCity()>getRegion()>getCountry();
// here only will be loaded
$user->getCity()>getRegion()>getCountry()->getName();
```
Of course this patch will require some unit test, but can be acceptable as idea?






[DDC-1401] Unusable entity in postRemove hook when using SINGLE_TABLE inheritance Created: 04/Oct/11  Updated: 21/Sep/14  Resolved: 15/Oct/11

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

Type: Bug Priority: Major
Reporter: Benjamin Dulau Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 1
Labels: None
Environment:

PHP 5.3.8-Win7 64bits
doctrine-common 2.1.1
doctrine-dbal 2.1.2
Symfony 2 project



 Description   

In a postRemove hook (from a dedicated listener, not inside an entity), the entity retrieved through Lifecycle event args is unusable when using SINGLE_TABLE inheritance.

Use case :

// base Media entity
namespace My\Entity;

class Media
{
    protected $id;
    protected $name;

    // ...setters/getters
}
<!-- Media mapping -->
<entity name="My\Entity\Media" table="medias" inheritance-type="SINGLE_TABLE">
    <id name="id" type="integer" column="id">
        <generator strategy="AUTO" />
    </id>

    <discriminator-column name="discr" type="string" />
    <discriminator-map>
        <discriminator-mapping value="media" class="My\Entity\Media" />
        <discriminator-mapping value="picture" class="My\Entity\Picture" />
    </discriminator-map>
</entity>
// Picture entity
namespace My\Entity;

class Picture extends Media
{}
<!-- Picture mapping -->
<entity name="My\Entity\Picture" />
// User entity
namespace My\Entity;

class User
{
    private $id;
    private $name;   
    private $picture;

    // ...setters/getters
}
<!-- User mapping -->
<entity name="My\Entity\User" table="users">
    <id name="id" type="integer" column="id">
        <generator strategy="AUTO" />
    </id>

    <field name="name" column="name" type="string" length="80" />

    <one-to-one field="picture" target-entity="My\Entity\Picture">
        <cascade>
            <cascade-all />
        </cascade>
    </one-to-one>
</entity>
// Listener
namespace My\Listener;

use Doctrine\ORM\Event\LifecycleEventArgs;
use Doctrine\ORM\Event\PreUpdateEventArgs;

class DoctrineMediaListener
{
    private $mediaManager;  // injected by IOC

    public function postRemove(LifecycleEventArgs $eventArgs)
    {
        $entity = $eventArgs->getEntity();
        if (!$entity instanceof Media) {
            return;
        }
        
        $this->mediaManager->removeMedia($entity);
    }   
}
// Media Manager
namespace My\Entity;

class MediaManager
{
    public function removeMedia(Media $media)
    {
        // try to read some $media property
        // and an exception (500) is thrown : Entity was not found.
    }
}

It works well if i use directly a Media object instead of a Picture one in my User class.
But as soon as i use a child object, here Picture, a 500 exception is systematically thrown when i try to access the entity given by the lifecycle event args.

This is really inconvenient since i can't perform any post remove operation when using inheritance system.



 Comments   
Comment by Benjamin Eberlei [ 15/Oct/11 ]

In your case i think the $media is a proxy object and then cannot be loaded in "postRemove" anymore.

Cant you just do that in preRemove (find the path)? And then work on postRemove() to delete it from a stack in the Media manager.

Comment by Benjamin Eberlei [ 15/Oct/11 ]

Invalid since in postRemove this can happen when you have an proxy and there is a workaround.

Comment by Benjamin Dulau [ 16/Oct/11 ]

Cant you just do that in preRemove (find the path)? And then work on postRemove() to delete it from a stack in the Media manager.

No i can't because the remove behaviour is not just about removing files and i need the informations about my entity.
I could register entities to be removed in the "preRemove" hook and do something with them later in the "postRemove" hook, but i assume the entities i would register would be Proxy objects too, so same problem.

Is there a way to retrieve the actual entity and not its proxy object ?

For now there is no workaround for my use case.

Comment by Adrian Colomitchi [ 21/Sep/14 ]

Please review/reconsider. I fail to understand the reason why setting the id to null is necessary.

In my case, the entity (derived) is loaded (so no proxy).
I'm asking the entityManager to delete it (not to modify it). As such, when getting to the postRemove to:
a. delete file system resources (based on the id)
b. adjust an audit record
I find the id field set to null, so everything blows.

True, intercepting preRemove and scheduling the actual deletion to postRemove/postFlush may be a workaround, but why should it be done in such a contorted way? If the EM absolutely need to "damage" the deleted entity (ubder the risk of loosing the consistency), then how about passing the pre-existing values as separate parameters in the event?





[DDC-3311] Add ESCAPE clause support after LIKE pattern, in Expr class Created: 17/Sep/14  Updated: 20/Sep/14

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

Type: Improvement Priority: Minor
Reporter: Vincent Bories-Azeau Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Actually, it is not possible to specify an ESCAPE character in a LIKE clause.
The Expr::like method only takes two arguments, and an optional third one shall be added.
Behaviour in common databases shall be checked, but I guess ESCAPE belongs to the ISO specification



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

Can you add a few usage examples? What APIs are affected?

Comment by Vincent Bories-Azeau [ 20/Sep/14 ]

Sorry, I don't understand what kind of information you're missing.
The API is the Doctrine\ORM\Query\Expr class, in the ORM.
The need is to improve the like method by addind a third optional parameter, that would allow to push an escape character, which seems to me "standard" SQL.
See LIKE specs in vendors documentation, for usage examples:

Comment by Marco Pivetta [ 20/Sep/14 ]

Vincent Bories-Azeau this is exactly what the kind of feedback I was asking for. As of http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#ebnf, the ESCAPE char is actually supported:

LikeExpression           ::= StringExpression ["NOT"] "LIKE" StringPrimary ["ESCAPE" char]

I suppose it just needs to be added to the query builder.

Comment by Vincent Bories-Azeau [ 20/Sep/14 ]

Sure, that's it , using direct DQL for requests, it is possible to write such conditions. However, as you notice it, using the QueryBuilder and the Expr methods, it is not possible to generate such queries. Thanks Marco!





[DDC-3315] [GH-1140] [DDC-2704] merge throughout entity hierarchy Created: 19/Sep/14  Updated: 19/Sep/14

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

Type: Bug Priority: Major
Reporter: 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 tiger-seo:

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

Message:






[DDC-3312] Cascade persist on non-owing side of a relation Created: 18/Sep/14  Updated: 18/Sep/14  Resolved: 18/Sep/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: Asmir Mustafic Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: info


 Description   

Hi!
I have a strange behavior/question...

Looking to this test: https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Functional/BasicFunctionalTest.php#L1152

in my opinion, it may be not correct.

CmsAddress is on non-owing side of CmsUser (https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/Models/CMS/CmsUser.php#L151).

$address has the cascade persist property.

Looking at the documentation (http://doctrine-orm.readthedocs.org/en/latest/reference/unitofwork-associations.html#important-concepts) seems that changes on non-owing side of a relation are always ignored, but the testFlushAndCascadePersist supposes that persit call has to be propagate to all associations.

Where I'm wrong?

Is persist propagated to all owing and non-owing associations?

BTW, here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L2217 i can't identify anything that "skips" the non-owing side of an association.

I have also created a PR https://github.com/doctrine/doctrine2/pull/1139 that is related to my question.
I'm trying to implement the proposed PR, but I need to understand this first.



 Comments   
Comment by Asmir Mustafic [ 18/Sep/14 ]

I prefer to move this issue to https://github.com/doctrine/doctrine2/pull/1139





[DDC-3313] [GH-1139] Single entity flush Created: 18/Sep/14  Updated: 18/Sep/14

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

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


 Description   

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

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

Message:

The current `flush` behavior seems to be inconsistent or not well documented.






[DDC-3222] PostUpdate event destroying collectionUpdates Created: 21/Jul/14  Updated: 17/Sep/14  Resolved: 17/Sep/14

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

Type: Bug Priority: Critical
Reporter: Jacob Spizziri Assignee: Marco Pivetta
Resolution: Invalid 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?

Comment by Marco Pivetta [ 17/Sep/14 ]

After checking again, I think this issue is invalid. Please use the onFlush event to log changes (instead of post-* events





[DDC-3224] getResult(HYDRATE_OBJECT) with joined query is returning reduced number of rows Created: 23/Jul/14  Updated: 17/Sep/14

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

Type: Bug Priority: Major
Reporter: gondo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

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



 Description   

given that i have these 2 entities (pseodocode):

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

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

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

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

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

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

tables and data

entity1:

id name
1 Jhon
2 Clare

entity2:

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

my query builder

use Doctrine\ORM\EntityRepository;

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

proper result is this:

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

what is happening

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

is really returning proper number of rows

BUT and here comes the BUG finally:

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

is returning just 2 rows:

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

this is because somehow entities are made unique.

my workaround

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



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

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

Comment by gondo [ 23/Jul/14 ]

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

Comment by Marco Pivetta [ 23/Jul/14 ]

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

Comment by gondo [ 23/Jul/14 ]

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

Comment by Marco Pivetta [ 23/Jul/14 ]

What I mean is that in

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

, parameter :date does not exist in the DQL.

Comment by gondo [ 23/Jul/14 ]

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





[DDC-2474] [GH-679] Fix getting started doc to work with current version Created: 28/May/13  Updated: 17/Sep/14  Resolved: 28/May/13

Statu