### [DDC-2810] Doctrine\ORM\EntityNotFoundException - Entity was not found. Created: 21/Nov/13  Updated: 21/Nov/13

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

 Type: Bug Priority: Blocker Reporter: Timothy Lorens Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Linux 2.6.32-358.18.1.el6.x86_64 #1 SMP Fri Aug 2 17:04:38 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux Server version: Apache/2.2.22 (Unix) PHP 5.3.3 (cli) (built: Jul 12 2013 04:36:18)

 Description
 Doctrine\ORM\EntityNotFoundException - Entity was not found. /zf2/framework/Infrastructure/Vendor/doctrine/orm/lib/Doctrine/ORM/Proxy/ProxyFactory.php:177 OneToOne join-side doesn't contain a matching record. One would assume this would just continue with an empty proxy object (full of null properties). The offending line of code is on line 750 of DOctrine\ORM\BasicEntityPersister.php. A quick fix/work-around was to replace the return null value with $entity which seems to be the object proxy class. Change this: return$entities ? $entities[0] : null; To This: return$entities ? $entities[0] :$entity;

### [DDC-2822] Replacing object in a OneToOne with OrphanRemoval=true isn't working as expected Created: 26/Nov/13  Updated: 29/Nov/13

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

 Type: Bug Priority: Blocker Reporter: Felipe Guaycuru Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: orm Environment: PHP 5.4

 Description
 So I have a class defined like this: class PhoneSettings { [...] /** @OneToOne(targetEntity="Medium", cascade= {"persist", "remove"} , orphanRemoval=true) @JoinColumn(name="medium_id", referencedColumnName="medium_id", nullable=true, onDelete="SET NULL") **/ protected $medium = null; [...] } And class Medium has no reference to the class Settings. Now suppose I have a$Settings object that is already persisted and has been correctly loaded. Also suppose that the $Settings object has a$medium (that is, $Settings->medium =$OldMedium) Now suppose I do: $Settings->medium =$NewMedium; Where $NewMedium is a different Medium object. When I persist$Settings, Doctrine does delete $OldMedium from the DB, but the problem is that it also deletes$NewMedium ... I have tried removing onDelete="SET NULL", but then I receive a "cannot delete, constraint failed" error...

### [DDC-274] Class and namespace naming inconsistency Created: 24/Jan/10  Updated: 31/Oct/10

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

 Type: Improvement Priority: Critical Reporter: Glen Ainscow Assignee: Roman S. Borschel Resolution: Unresolved Votes: 1 Labels: None

 Description
 There are inconsistencies with some class and namespace names that include acronyms. Examples: Classes with upper-casing: ORMException, DBALException, OCI8Connection, etc. Classes with proper-casing: RunDqlTask, CliException, MySqlPlatform, etc. Namespaces with upper-casing: DBAL, ORM, Doctrine\DBAL\Driver\PDOMsSql, etc. Namespaces with proper-casing: Doctrine\Common\Cli, Doctrine\DBAL\Tools\Cli\, Doctrine\ORM\Id, etc. There is more proper-casing than upper-casing. IMHO, proper-casing is better as it's easier to read "SqlException" than it is to read "SQLException" (the "E" looks like part of the acronym), and things like "CLITask" can be avoided. I discussed this a bit with Benjamin and Guilherme, and they were unsure and said that the whole team needed to reach consensus. I'm leaving the priority as "Major" because this should probably be fixed sooner rather than later to prevent compatibility breaks.

### [DDC-222] Create unit tests for CLI components Created: 22/Dec/09  Updated: 30/Oct/10

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0-ALPHA3
Fix Version/s: 2.x
Security Level: All

 Type: Task Priority: Critical Reporter: Roman S. Borschel Assignee: Guilherme Blanco Resolution: Unresolved Votes: 0 Labels: None

 Reference is referenced by DDC-359 Specified, but empty CLI Options --op... Resolved

 Comment by Roman S. Borschel [ 19/May/10 ] Whats the status here? Do we have any? Comment by Guilherme Blanco [ 19/May/10 ] Since we moved to Symfony Console I don't think this is needed anymore. The purpose of this ticket was actually to test our own CLI support, which was dropped. I'm closing the ticket due to this. Reopen if you have any other comment. Comment by Benjamin Eberlei [ 20/May/10 ] I think we do need some basic functional tests of our Commands, they have been subject to many bugs in the past becaues they are not tested. Comment by Benjamin Eberlei [ 19/Jun/10 ] Fixed another fatal error in the command due to missing namespace dependency. We need tests for all the commands, there have been dozens of issues on these things so far. This commit shows a simple approach on how testing is easily possible for symfony commands: http://github.com/doctrine/doctrine2/commit/51e6681934a7cf4448b85c5670c04045f66c6056 Comment by Roman S. Borschel [ 26/Aug/10 ] Can we expect some more tests for beta4 or is it unlikely that you find the time? Should we move this further back or does someone else want to step in?

### [DDC-2237] oracle IN statement with more than 1000 values Created: 11/Jan/13  Updated: 02/Apr/13

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

 Type: Bug Priority: Critical Reporter: Marc Drolet Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 If I have a query with a IN statement with more tahn 1000 values I get an sql error. I've try IN with implode: select * from test where id IN(' . implode(',', $values) . ') and I've also try with executeQuery: select * from test where id IN(:test) executeQuery($sql, array($values), array(\Doctrine\DBAL\Connection::PARAM_INT_ARRAY))  Comments  Comment by Marc Drolet [ 11/Jan/13 ] Here is the way I've implement the solution on my side: (for oracle) into Doctrine/DBAL/Statement.php, I've add this method: /** * Binds a parameter value to the statement. * This is implemented this way for oracle only. Other drivers are redirected to bindValue method. * * The value will be bound with to the type provided (that required to be a table type). * * @param String$name The name or position of the parameter. * @param Array $value The value of the parameter. * @param String$type The name of the type to use to bind. * @return boolean TRUE on success, FALSE on failure. */ public function bindList($name, Array$value, $type) { if ('oracle' !==$this->platform->getName()) { $this->bindValue($name, $value,$type); } else { return $this->stmt->bindList($name, $value,$type); } }  into Doctrine/DBAL/Driver/Statement.php I've add: /** * @TODO: docs */ function bindList($param, Array$values, $type);  into Doctrine/DBAL/Driver/OCI8/OCI8Statement.php I've add this method: /** * {@inheritdoc} */ public function bindList($param, Array $value,$type) { if (!($list = oci_new_collection($this->_dbh, $type))) { //throw new OCI8Exception::fromErrorInfo($this->errorInfo()); } foreach ($value as$entry) { $list->append($entry); } if (!oci_bind_by_name($this->_sth,$param, $list, -1, OCI_B_NTY)) { //throw new OCI8Exception::fromErrorInfo($this->errorInfo()); } }  // NOTE: we should probably add the bindList to all driver Statement object. into your code you can use it this way: $sql = " SELECT * FROM test WHERE id IN ( SELECT * FROM ( CAST (: p_ids AS list_int_type) ) ) ";$stmt = connection->prepare($sql);$stmt->bindList(': p_ids', $ids, 'list_int_type');$stmt->execute(); $rs =$stmt->fetchAll(PDO::FETCH_ASSOC);  NOTE: list_int_type need to be a valid oracle data type. You can create one with the name you want. example: you can have 2 type of accepted array of values: integer and string let's say we create one for string named: list_str_type and one for integer list_int_type create or replace type list_str_type as table of varchar2(4000); create or replace type list_int_type as table of number; Comment by Benjamin Eberlei [ 01/Apr/13 ] Hey Marc Drolet thanks for the feedback and the solution, however i would like to have something generic that is working independent of the database driver. This code is very specific. Can you point me to some documentation why oci collection works with more than 1000 elements and how it works in PHP? Comment by Marc Drolet [ 02/Apr/13 ] Hi Benjamin, The limitation is not from the oci driver, it's an oracle limitation. There are a couple of possible solution/implementation that can be done but the one I've provide is the one that perform better for the test I've done and from what I can found over the blogs I've read. I can't find the exact documentation of oracle. oracle doc is so poor. Here is the best description link I can provide that describe some possible implementation. http://vsadilovskiy.wordpress.com/substituting-a-collection-for-in-list-performance-study/ I don't know if there is similar limitation with other database. With the implementation I've provided, It will be possible to implement the proper solution depending on the database limitation you face otherwise it will execute the generic IN. What's bad, we need to create the type into the database. NOTE: In my case, I can not perform a sub-query, I get the my collection from a web service call.

### [DDC-2332] [UnitOfWork::doPersist()] The spl_objact_hash() generate not unique hash! Created: 05/Mar/13  Updated: 30/May/13

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

 Type: Bug Priority: Critical Reporter: Krisztián Ferenczi Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Symfony 2.1.8, php 5.4.7 and php 5.4.12, Windows 7

 Attachments: hashlogs.txt

 Description
 I created fixtures and some data was inserted many times without calling the Task entity PrePersist event listener. I printed the used and generated hash and I saw a Proxies_CG_\Asitly\ProjectManagementBundle\Entity\User hash equal a Task entity hash!

 Comment by Marco Pivetta [ 05/Mar/13 ] Please provide either a code example or a test case. As it stands, this issue is incomplete Comment by Benjamin Eberlei [ 05/Mar/13 ] Are you calling EntityManager#clear() inbetween? Because PHP reuses the hashes. The ORM accounts for this. Comment by Benjamin Eberlei [ 05/Mar/13 ] This is not a reproduce case, i don't want to execute your whole project. I want to know, what is the actual bug that you see? Can you just print a list of all the hashes? Because the hashes dont differ at the end, bu tjust somewhere in the middle. Comment by Krisztián Ferenczi [ 05/Mar/13 ] I attached a hashlogs.txt file. The last Task class hash is 0000000050ab4aba0000000058e1cb12 ( line 3 129 ) This is not unique, view the line 2 760 . The Task is not being saved and the program don't call the prePersist listener. The "UnitOfWork" believe the entity has been saved because the isset($this->entityStates[$oid]) is true. But it is an other entity. Comment by Krisztián Ferenczi [ 06/Mar/13 ] The EntityManager::clear() fix the problem, but this is not "good" and "beautiful" solution. Shows no sign of that conflicts were and this is causing the problem. I was looking for the problem 7 hours.

### [DDC-2647] SSL Off Created: 03/Sep/13  Updated: 08/Sep/13

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

 Type: Improvement Priority: Critical Reporter: Eder Campelo Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 Hello all, How can i connect using SSL whit PostgreSQL? When i try, a have this error: SQLSTATE[08006] [7] FATAL: no pg_hba.conf entry for host "...", user "...", database "...", SSL off Gtraz

 Comment by Benjamin Eberlei [ 08/Sep/13 ] This is not yet possible, the Doctrine\DBAL\Driver\PDOPgSQL\Driver is missing this functionality. You can add a Pull Request to DBAL so that we can add it.

### [DDC-2768] Doctrine could not work with date as primary key Created: 30/Oct/13  Updated: 30/Oct/13

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

 Type: Bug Priority: Critical Reporter: Nikita Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 Part of my mapping:  id: statDate: type: date phrase: type: string bannerId: type: integer  So I've got an exception: Object of class DateTime could not be converted to string in /Users/hell0w0rd/dev/rsol/direct/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php line 13 45

### [DDC-2624] ManyToManyPersister fails to handle cloned PeristentCollections Created: 20/Aug/13  Updated: 18/Nov/13

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

 Type: Bug Priority: Critical Reporter: Martin Prebio Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: None

 Description
 I want to clone an entity and persist the clone. The entity itself works (if I reset the identifiers to null) but a M2M collection was first ignored since I only did a shallow copy. When I do a deep copy with the following, Doctrine throws the following exception: public function __clone() { if ($this->question_versions instanceof PersistentCollection) {$this->question_versions = clone $this->question_versions; } } Fatal error: Uncaught exception 'Doctrine\Common\Persistence\Mapping\MappingException' with message 'The class 'Doctrine\ORM\Persisters\ManyToManyPersister' was not found in the chain configured namespaces Foo\Entity' in /var/www/foo/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/MappingException.php on line 37 I've traced the error to the ManyToManyPersister class at the methods get {Delete,Insert} RowSQL where$coll->getOwner() is called which returns null because the owner is cleared when the collection is cloned. Therefore get_class does not work as expected under this circumstances. I've also tried to use $coll->getTypeClass() for$class at that point but this leads to other warnings ("array key not existing" and "spl_object hash got null") and finally an SQL exception because Doctrine is inserting null as one of the identifiers. There is a workaround for this issue but I think that this edge case should be handled too. The workaround is not to clone the collection itself but only copy the values with getValues() and let Doctrine convert it back to a collection.

 Comment by Martin Prebio [ 20/Aug/13 ] This issue may be related to DDC-2074 Comment by Marcin Iwański [ 18/Nov/13 ] I have the same problem on v2.4.1 after cloning collections in __clone() method of the entity, so seems that DDC-2074 didnt fix this case. But collection cloning is needed to properly manage cloned entity relationships. Comment by Martin Prebio [ 18/Nov/13 ] The getValues() workaround created some issues for us but I found another workaround. This one works for us for some time in a small to medium sized project where we heavily clone, detach and so on: __clone() { if ($this->m2mcoll instanceof PersistentCollection) {$this->m2mcoll = clone $this->m2mcoll;$this->m2mcoll->setOwner($this,$this->m2mcoll->getMapping()); } } The problem here is that this can not be put into the collection's clone method since it requires the entity object (which is $this). Comment by Marcin Iwański [ 18/Nov/13 ] Thanks Martin for your help, your workaround seems to work well in my case. I dont know yet if it has any drawbacks that may occur in longer time period. My general thought after dealing with entity cloning is that official manual should pay more attention to this topic, because I had to figure out most of the issues by myself. Comment by Martin Prebio [ 18/Nov/13 ] Yes, I've made the same experience regarding the documentation but still I haven't found time to contribute to it. Nevertheless if you run in any problems with my new workaround, please let me know of it. (I already spent some hours in the Doctrine code for some other issues) ### [DDC-2800] Something wrong with documentation generation Created: 18/Nov/13 Updated: 18/Nov/13 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: None Fix Version/s: None Security Level: All  Type: Documentation Priority: Critical Reporter: Flip Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  The ArrayCollection has a matching() function, but it does not show in the API docs. http://www.doctrine-project.org/api/common/2.4/class-Doctrine.Common.Collections.ArrayCollection.html ### [DDC-851] Automerge of detached entities passed to doctrine Created: 31/Oct/10 Updated: 30/Dec/10 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.0-BETA4 Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: Daniel Alvarez Arribas Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None  Description  This is a feature request. Currently it is not possible to assign a detached entity to a relationship. You have to manually "merge" it, and only then you are able to assign it to relationships of managed objects. This can become complicated to do. The way it is now, when assigning an entity to a relationship in a process using a large number of entities, the entity's state needs to be checked and the entity possibly merged - all in userland code. This adds a level of complexity and potential for errors, while it could be solved transparently and elegantly within the ORM. There are ways to implement it in userland code, too, with moderate effort (see below), but this does not change the fact that responsibility for implementing a purely technical feature is delegated to the user, who could be spending his time much better writing business code. And if the user actually implements it, it will clutter the application with non-problem-domain code. To keep things simple, I propose Doctrine be extended to simply auto-merge any detached entities passed to it. That would save the programmer the manual tracking of object states and merge() calls. This would be especially handy when using cascades, as keeping track of deep object graphs in userland code would duplicate substantial ORM functionality. In programs that work with massive amounts of data, it is practically impossible to keep all entities managed due to resource constraints (see e.g. the batch processing patterns documented in the Doctrine 2 reference at http://www.doctrine-project.org/projects/orm/2.0/docs/reference/batch-processing/en). In a situation like that, one would probably simply flush and clear the entity manager regularly. Doctrine 2 currently forces the user to manually "merge" all persistent objects he/she still holds references to and wants to assign e.g. to other newly created persistable objects. I can not think of any reason why Doctrine 2 should not be able to do it automatically. Below is another comment originally attached to the GitHub proposal, containing a userland implementation of the feature as a temporary fix, for whoever cares. Here is a userland implementation for the functionality I am proposing, though I feel it is technical clutter that belongs into the ORM. Changing doctrine to be able to auto-merge unmanaged entities would be ideal. I thought I'd share this, for use as long as Doctrine 2 does not provide equivalent functionality. The implementation assumes all entities inherit from a base class (named "YourEntityBaseClass here") and intercepts the assignment to ToOne-relationships in a __set() method provided in that base class. For ToMany-relationships we extend ArrayCollection to intercept calls to add() and set() to accomplish the same. As an alternative to defining a __set() method in a base class you could also implement the interception by changing any mutator methods you define in your entities. But that would bloat your code quickly as you define more and more relationship attributes on your entities. The following __set() method implementation relies on reflection to parse the DocBlock-Comment with the Annotation and determine whether or not the property to be set is a ToOne-relationship.  public function __set($name, &$value) {$reflectionClass = new ReflectionClass($this);$property = $reflectionClass->getProperty($name); if ( self::isToOneRelationship($property) &&$value !== null) { $value = self::mergeIfDetached($value); } $this->$name = $value; }  The following is an implementation of mergeIfDetached(), that assumes there is a __get defined on the entity, to be able to access the protected mapped properties. public static function mergeIfDetached(YourEntityBaseClass$dataObject) { $doctrineEntityManager = DB::getDoctrineEntityManager(); if ($doctrineEntityManager->getUnitOfWork()->getEntityState($dataObject) == \Doctrine\ORM\UnitOfWork::STATE_DETACHED) {$dataObject = $doctrineEntityManager->merge($dataObject); } return $dataObject; }  For your purposes, consider DB to be just a class holding a reference to the Doctrine entity manager. Here are the helper methods for the reflection:  private static function isToOneRelationship(ReflectionProperty$property) { return self::matchDoctrineAnnotation($property, self::$doctrineToOneRelationshipAnnotation); } private static function matchDoctrineAnnotation(ReflectionProperty $property,$pattern) { return preg_match('/\@' . $pattern . '/',$property->getDocComment()) != 0; }  Here is the drop-in-replacement class for use with ToMany-Relationships. It uses the static reloadIfDetached method defined in the entity base class: use Doctrine\Common\Collections\ArrayCollection; class Collection extends ArrayCollection { public function set($key,$value) { $value = YourEntityBaseClass::mergeIfDetached($value); parent::set($key,$value); } public function add($value) {$value = YourEntityBaseClass::mergeIfDetached($value); return parent::add($value); } }  This approach keeps the amount of unnecessary code to a minimum, so that merges are not scattered throughout the problem-domain code.

 Comment by Daniel Alvarez Arribas [ 29/Dec/10 ] I have to note that the code I listed above turned out to be broken. There is nothing that guarantees that a data object just merged will not become detached again after being merged on assignment, unless the object is immediately persisted afterwards. The correct solution would be to merge all data objects found through relationships for a given data object, right from the persistence manager, immediately before calling persist() on the data object. I am currently using this solution (save() saves a data object safely for use within long-running batch jobs):  public static function save(DataObject $dataObject) { self::mergeRelatedDataObjectsIfDetached($dataObject); self::$doctrineEntityManager->persist($dataObject); } public static function merge(DataObject $dataObject) { return self::$doctrineEntityManager->merge($dataObject); } protected static function mergeRelatedDataObjectsIfDetached(DataObject$dataObject) { $reflectionClass = new ReflectionClass($dataObject); $properties =$reflectionClass->getProperties(); foreach ($properties as$property) { $propertyName =$property->getName(); $propertyValue =$dataObject->__get($propertyName); if (MetadataReader::isToOneRelationship($property)) { if ( $propertyValue !== null && !$propertyValue instanceof Proxy && self::isDetached($propertyValue)) {$relatedDataObject = self::merge($propertyValue);$dataObject->__set($propertyName,$relatedDataObject); } } else { if (MetadataReader::isToManyRelationship($property)) {$relatedDataObjects = $propertyValue->toArray(); foreach ($relatedDataObjects as $index =>$relatedDataObject) { if ( ! $relatedDataObject instanceof Proxy && self::isDetached($relatedDataObject)) { $relatedDataObject = self::merge($relatedDataObject); // Replace the entry in the collection with the merged copy. $propertyValue->set($index, $relatedDataObject); } } } } } } protected static function isDetached(DataObject$dataObject) { return self::$doctrineEntityManager->getUnitOfWork()->getEntityState($dataObject) == UnitOfWork::STATE_DETACHED; }  I still wish there would be an automerge feature, kind of Hibernate's "update". Comment by Daniel Alvarez Arribas [ 29/Dec/10 ] Wrapped the code sections into proper code blocks...

### [DDC-813] Validate Schema should complain on bi-directional relationships with mapped superclasses Created: 21/Sep/10  Updated: 29/Oct/12

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

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

 Description
 @ManyToOne and @OneToOne on mapped superclasses have to be unidirectional. The Schema Validator should verify this.

### [DDC-810] Issue with detaching entities and updating when using change notification Created: 17/Sep/10  Updated: 04/Jul/11

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

 Type: Improvement Priority: Major Reporter: Jonathan H. Wage Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None

 Attachments: DDC810Test.php

 Description

 Comment by Benjamin Eberlei [ 20/Sep/10 ] From reading the issue i know what the bug is, indeed this sucks. Comment by Roman S. Borschel [ 28/Sep/10 ] @Jon: Any more information coming? @Benjamin: Can you summarize the essence of the issue shortly? Comment by Benjamin Eberlei [ 29/Sep/10 ] @Roman: The UnitOfWork (may) still be pushed as a listener into that entity, and still recieve noticies of update. Which may throw notices because the oid hashes are removed everywhere. Additionally you cant serialize the thing because you still got the UoW inside there. Comment by Jonathan H. Wage [ 04/Oct/10 ] I don't have anymore information currently. The issue was relayed to me. I will try and find some more information and report back. Comment by Benjamin Eberlei [ 03/Apr/11 ] There is no way to "fix" this issue, i am turning it into a feature request. There needs to be a "postDetach" event that is triggered where the developer can detach the change notification objects.

### [DDC-803] Create subselect queries within join statements Created: 14/Sep/10  Updated: 14/Sep/10

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

 Type: New Feature Priority: Major Reporter: Martijn Evers Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None

### [DDC-785] Post-Post-Persist event Created: 02/Sep/10  Updated: 14/Jan/11

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

 Type: Improvement Priority: Major Reporter: arnaud-lb Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None

 Description
 postPersist/postUpdate events are triggered in the middle of a unitOfWork, and querying the DB in such events causes infinite loops. Doctrine attempts to flush the entity manager before running any query, which triggers flushing of entities, and postPersist/postUpdate events are triggered again. I did not checked, but the flush() before each query may be a performance problem too, if doctrine has to determine what has changed, depending on the changetracking policy. Also, it would be great if postPersist / postUpdate events were triggered after all entities have been persisted. It looks like that entities are flushed by groups of same 'type', and that events for a type are triggered once all of the elements of that group have been flushed, potentially before entities of an other type have been flushed : postPersist / postUpdate events are triggered while some other entities are still not flushed.

 Comment by Benjamin Eberlei [ 03/Sep/10 ] That is documented and for perfomance reasons we cannot move the preUpdate/postUpdate/prePersist/postPersist events to other locations inside the UnitOfWork. There is an onFlush event that allows for more flexibility and is triggered before any update/insert/delete is done by the UnitOfWork. Comment by arnaud-lb [ 04/Sep/10 ] Thanks. I understand that. Is there any chance of getting some onPostFlush or similar, which would be triggered like onFlush, but after all update/insert/delete ? Or just some post-something event which is allowed to issue db queries. Comment by Gediminas Morkevicius [ 24/Sep/10 ] onFlush you can store your entity for furher processing and on postPersist you can check if there are no more insertions and process the entity if it needs additional query I have faced all these issues and you can check http://github.com/l3pp4rd/DoctrineExtensions/tree/master/lib/DoctrineExtensions/Translatable/ for a solution to your problem Comment by Gediminas Morkevicius [ 14/Jan/11 ] I think this issue should be closed since the main reason of opening it was the possibility to execute additional queries when inserts were pending in unit of work. In current release it does not cause a flush during an additional query execution anymore.

### [DDC-779] Doctrine\ORM\Configuration should be immutable after construction of EntityManager Created: 30/Aug/10  Updated: 30/Aug/10

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

 Type: Improvement Priority: Major Reporter: Benjamin Eberlei Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None

 Description
 Currently the Doctrine\ORM\Configuration instance is not immutable after construction of the EM, which can lead to funny behavior when changing essential dependencies such as caches or others.

### [DDC-769] Disabling discriminator column in WHERE clause Created: 26/Aug/10  Updated: 07/Sep/10

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

 Type: Improvement Priority: Major Reporter: Lars Strojny Assignee: Roman S. Borschel Resolution: Unresolved Votes: 1 Labels: None

 Description
 Per default Doctrine 2 adds an IN(...)-part to the query when hydrating an entity where a discriminator column is defined. While this makes sense as a default behavior, it would be pretty helpful if one could disable the WHERE-clause for discriminator columns alltogether for performance optimization.

 Comment by Roman S. Borschel [ 26/Aug/10 ] That would obviously produce wrong results. Maybe you can elaborate more with an example. Comment by Lars Strojny [ 07/Sep/10 ] I use ENUM("foo","bar") as discriminator columns. That means, the column will contain the right values out of the box, no further result set limiting required with WHERE.

### [DDC-1270] Incorrect QueryBuilder example Created: 11/Jul/11  Updated: 11/Jul/11

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

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

 Description

### [DDC-1197] Proxies should handle variable argument lists Created: 05/Jun/11  Updated: 05/Jun/11

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

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

 Description
 This is a contingency issue for https://github.com/doctrine/doctrine2/pull/60 "Fix to allow for proxy generated classes to respect methods in parent which may use func_get_args internally. Previously they would be passed nothing and thus fail. Also reduces need to build up argumentString. "

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

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

 Description

 Comment by Gediminas Morkevicius [ 27/May/11 ] Sounds logic, each driver would expect NULL or data (wrapped specifically for the driver used)

### [DDC-1164] doctrine:schema:update --force == doctrine:schema:create Created: 20/May/11  Updated: 20/May/11

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

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

 Description
 Doctrine:schema:update --force is the same as doctrine:schema:create. Under the hood, this may not be true, but they basically accomplish the same task. Schema:create should be removed, as it is redundant. Just look at django, one command to update db: ./manage.py syncdb Not saying that django gets everything correct, but the one command to synchronize the database is consistent. doctrine:schema:update should be smart enough to do all of the work, instead of relying on the redundant doctrine:schema:create.

### [DDC-1154] Proxies should take convention while loading *ToOne associations to reduce 1 extra query Created: 17/May/11  Updated: 17/May/11

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

 Type: Improvement Priority: Major Reporter: Guilherme Blanco Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 Read the IRC log: [2:38pm] guilhermeblanco: beberlei: ping [2:38pm] guilhermeblanco: I'm curious about a feature if Doctrine supports [2:38pm] guilhermeblanco: if we do this on a proxy: [2:38pm] guilhermeblanco: $proxy->getOneToOneAssoc() [2:39pm] guilhermeblanco: shouldn't Doctrine already populate the assoc entity? [2:39pm] guilhermeblanco: it would be an inner join [2:39pm] beberlei: how would doctrine know it needs it? [2:39pm] guilhermeblanco: beberlei: it always repass the ClassMetadata to Persister [2:40pm] guilhermeblanco: so all needed item is to also pass the fieldname/assocname [2:40pm] beberlei: but how would doctrine know getOneToOneASsoc() really returns this assoc [2:40pm] beberlei: it could contain any logic [2:40pm] guilhermeblanco: it wouldn't... but as soon as we trigger __load($fieldName) [2:40pm] guilhermeblanco: we know that we could populate not only the Proxy, but also assoc [2:40pm] beberlei: by convention? [2:40pm] guilhermeblanco: ya [2:41pm] beberlei: sounds good, can you open a ticket? [2:41pm] guilhermeblanco: getUser() would trigger __load('user') [2:41pm] guilhermeblanco: sure! [2:41pm] guilhermeblanco: I'll pastie this as content... it would be awesome to have [2:41pm] guilhermeblanco: I see a lot of queries here that could be optimized 

### [DDC-1144] How insert a AES_ENCRYPT value in a table field Created: 10/May/11  Updated: 10/May/11

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

 Type: New Feature Priority: Major Reporter: dquintard Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Win XP, MySql5, Php5.3, ZendFramework 1.11.4

 Description

### [DDC-1016] Example code does not reflect real code Created: 03/Feb/11  Updated: 03/Feb/11

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

 Type: Documentation Priority: Major Reporter: thoth Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Website

 Description
 http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html#entity-state In the switch cases all the UnitOfWork constants are invalid. Example: UnitOfWork::NEW instead of being UnitOfWork::STATE_NEW

### [DDC-1011] Finding out if a model is persist Created: 02/Feb/11  Updated: 02/Feb/11

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

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

 Description
 To find out if a model is persist, is missing in the documentation of doctrine 2. To become the state of an model you must call the entitymanager->getUnitOfWork()->getEntityState(model)

### [DDC-998] Code example for custom AST functions incorrect Created: 23/Jan/11  Updated: 23/Jan/11

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

 Type: Documentation Priority: Major Reporter: Timo A. Hummel Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 On http://www.doctrine-project.org/docs/orm/2.0/en/reference/dql-doctrine-query-language.html#adding-your-own-functions-to-the-dql-language the code example is slightly incorrect. Mistakes: Lexer::T_ABS doesn't exist anymore, I assume Lexer::T_IDENTIFIER is what one wants to use Missing use for \Doctrine\ORM\Query\Lexer Additionally, the section should tell the user that he best has a look at lib/Doctrine/ORM/Query/AST/Functions/* to learn how to write custom functions. It also could be noted that stored procedures can be called with custom functions.

### [DDC-999] DQL always needs a FROM clause, should be changed Created: 23/Jan/11  Updated: 23/Jan/11

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

 Type: New Feature Priority: Major Reporter: Timo A. Hummel Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: None

 Description
 Sometimes a developer needs to issue a query without a FROM clause. This especially occurs using the QueryBuilder, when you may or may not have a table to select from, but call a stored procedure always. Example: $query =$em>createQuery('SELECT (1+1)');  The above query fails because the lexer expects T_FROM. If you replace (1+1) with a stored procedure, this example makes more sense. One might argue about that you should use DBAL directly, but I disagree, because it always can happen that you end up in a situation like this: $qb =$em->createQueryBuilder(); $qb->select("SOMEFANCYPROCEDURE()"); if ($condition) { $qb =$qb->from("additionalTable t"); } 

### [DDC-993] Cookbook: Overriding the ID Generator during a database migration Created: 19/Jan/11  Updated: 28/Oct/12

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

 Type: Documentation Priority: Major Reporter: Timo A. Hummel Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: None

 Description
 If you need to override the ID Generator, e.g. during a migration, you can do that in your migration script as follows: Overriding the ID generator $em->getClassMetadata('foo\bar\Entity')->setIdGenerator(new \Doctrine\ORM\Id\AssignedGenerator());$em->getClassMetadata('foo\bar\Entity')->setIdGeneratorType(constant('Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE')); Make sure that both calls equal to the same generator type. You can now modify the @Id fields in your entities. Additionally, make sure that you set the IdGenerator after you created the database using e.g. SchemaTool->create().

 Comment by Endre Kósa [ 27/Oct/12 ] Hi, this doesn't seem to work for me. I have written a small database export / import utility. As long as I use the automatic ID generation, everything works flawlessly, but I'm trying to preserve the existing IDs. I do exactly what you've suggested in your post. It works for @OneToOne relations, but I get the following error messages when persisting entities that are parts of @ManyToOne relations: Notice: Undefined index: [....] in [...]Doctrine/ORM/UnitOfWork.php on line 2655 I'm using version 2.2.2 Am I doing something wrong? Comment by Endre Kósa [ 28/Oct/12 ] Never mind. I've upgraded to Doctrine 2.3.0 and it works as expected.

### [DDC-947] Optmize Code-Generation Strategies Created: 24/Dec/10  Updated: 29/Mar/11

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

 Type: Improvement Priority: Major Reporter: Benjamin Eberlei Assignee: Jonathan H. Wage Resolution: Unresolved Votes: 0 Labels: None

 Description
 We should optimize code-generation somehow.

 Comment by Benjamin Eberlei [ 29/Mar/11 ] Descheduled to 2.x

### [DDC-946] Evaluate optional use of igbinary for serialization Created: 22/Dec/10  Updated: 22/Dec/10

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

 Type: Improvement Priority: Major Reporter: Benjamin Eberlei Assignee: Roman S. Borschel Resolution: Unresolved Votes: 1 Labels: None

 Description
 Igbinary is supposed to be faster and better than serialize/unserialize(). We should check if its relevant for us (metadata and query caching for example): https://github.com/phadej/igbinary

 Comment by Benjamin Eberlei [ 22/Dec/10 ] http://ilia.ws/archives/211-Igbinary,-The-great-serializer.html#extended

### [DDC-930] A table cannot have more than one many to many relationship with the same table when using reverse engineer Created: 13/Dec/10  Updated: 13/Dec/10

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

 Type: Improvement Priority: Major Reporter: Jiri Helmich Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None Environment: FreeBSD, PostgreSQL 8.4

 Description
 This is caused by taking the join column name as the identifier while generating a property name for annotation. The mapping driver detects that the same property is already defined and ends the convert process. A little bit smarter approach for me was to take the local table name. But this assumes a specific style of join table naming convention. Doctrine\ORM\Mapping\Driver\DatabaseDriver::loadMetadataForClass() Replace: $associationMapping['fieldName'] = Inflector::camelize(str_replace('_id', '', strtolower(current($otherFk->getColumns())))); With: $name = explode("_",$myFk->getLocalTableName()); if (count($name) > 1) { array_shift($name); } $name = implode("_",$name); $associationMapping['fieldName'] = Inflector::camelize(str_replace('_id', '', strtolower($name))); Maybe to switch to this behavior with an additional option?

### [DDC-923] Add note about DateTime Query Parameter Type Hint Created: 10/Dec/10  Updated: 10/Dec/10

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

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

### [DDC-919] subselect Created: 08/Dec/10  Updated: 20/Mar/11

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

 Type: Documentation Priority: Major Reporter: Mungiu Dragos Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None

 Description
 i'd like to see more example in documentation with this subselects [23:08] can you open a tciket on jira? then i dont forget to do that when i have time

 Comment by Alberto [ 20/Mar/11 ] Subselect as columns or FROM clause should have mor examples.

### [DDC-896] Use PDepend for Code-Generation Created: 27/Nov/10  Updated: 27/Nov/10

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

 Type: Improvement Priority: Major Reporter: Benjamin Eberlei Assignee: Jonathan H. Wage Resolution: Unresolved Votes: 0 Labels: None

 Description
 Our current code-generation tool has many shortcomings and due to its hard to test nature also many (known and unknown) bugs, as well as high maintenance. Since people are overusing this tool and I am sort of annoyed by how much time goes into this we should rewrite this in a two-step procedure: 1. Move code into Common so we can share it between ORM, Mongo and CouchDB. 2. Use PDepend to read an entities source file (it generates an AST) and modify the AST with the required changes. This gives us the advantage of having to maintaining less code for this stuff.

### [DDC-1475] Documentation for One-To-Many, Bidirectional Association does not have YAML example Created: 07/Nov/11  Updated: 07/Nov/11

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

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

 Description
 When you are looking for a config example for the bidirectional mapping of an one-to-many association you will just find an example with XML, but not with YAML or PHP. It would be nice if somebody could add an example or a link to the bidirectional one-to-one association, because it should be the same, right? Here the link to the example: http://www.doctrine-project.org/docs/orm/2.0/en/reference/association-mapping.html#one-to-many-bidirectional

### [DDC-1465] Fetching partial objects doesn't work if HINT_FORCE_PARTIAL_LOAD is not explicitly used Created: 02/Nov/11  Updated: 11/Nov/11

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

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

 Duplicate duplicates DDC-624 Partial object query that leaves out ... Open

 Description
 Using the DQL "partial" keyword is not enough to get a partial entity as a result. The DQL hint HINT_FORCE_PARTIAL_LOAD must be used as well. $q =$em->createQuery('SELECT partial r.{id,comment} FROM Entities\Rating r WHERE r.id=3'); $r =$q->getResult() /* HYDRATE_OBJECT is the default hydration mode */  Here, $r contains the full Entity, a SELECT * has been sent $q = $em->createQuery('SELECT partial r.{id,comment} FROM Entities\Rating r WHERE r.id=3');$q->setHint(Doctrine\ORM\Query::HINT_FORCE_PARTIAL_LOAD, 1); $r =$q->getResult() /* HYDRATE_OBJECT is the default hydration mode */  Here, $r contains only the selected fields, hence a true partial Entity ### [DDC-1459] Move DDC-331, DDC-448, DDC-493, DDC-513, DDC-698 Tests into SQLGeneration Testsuite Created: 29/Oct/11 Updated: 01/Aug/12 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: None Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None ### [DDC-1450] UnitOfWork Transaction Rollback Support Created: 24/Oct/11 Updated: 20/Dec/11 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: None Fix Version/s: 2.x Security Level: All  Type: Improvement Priority: Major Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  The UnitOfWork does not handle the case very well where a rollback is necessary. Can this be optimized?  Comments  Comment by Guilherme Blanco [ 20/Dec/11 ] Updating fix version ### [DDC-1443] Subscribers reachs maximum nesting level when creating association on pre/postPersist with cascade persist Created: 20/Oct/11 Updated: 29/Oct/11 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: Git Master Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Guilherme Blanco Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Attachments: DDC1443Test.php DDC1443Test.php  Description  Suppose a situation where: A -> B Where the OneToOne unidirectional association contains cascade persist. If I decide to save an entity B that should create an A instance, it goes into maximum nesting level no matter if I track prePersist or postPersist.  Comments  Comment by Guilherme Blanco [ 20/Oct/11 ] Failing test case Comment by Guilherme Blanco [ 20/Oct/11 ] Uploading a new version, now passing successfully, but consuming the onFlush event (which should not be ideal). Comment by Benjamin Eberlei [ 29/Oct/11 ] Ah yes, this never worked. The transaction stuff will fix that. You have to use scheduleForInsert() something inside prePersist. ### [DDC-1445] Improve error messages Created: 22/Oct/11 Updated: 20/Dec/11 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: None Fix Version/s: 2.x Security Level: All  Type: Improvement Priority: Major Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  Error messages throughout ClassMetadata validation and UnitOfWork cycles can be significantly improved. Work is being done on: https://github.com/doctrine/doctrine2/tree/ImproveErrorMessages  Comments  Comment by Guilherme Blanco [ 20/Dec/11 ] Updating fix version ### [DDC-1441] Metadata cannot be loaded for not registered proxy objects Created: 20/Oct/11 Updated: 05/Apr/12 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.1.2 Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: Aigars Gedroics Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: MySQL, Ubuntu, PHP 5.3.6  Attachments: DDC1441Test.php not-loaded-proxy-patch.diff  Description  We are using several Doctrine managers in our project with the same entity classes and different database tables. The problem appears when we are willing to merge entity with lazy associations from one manager to another. The second entity manager instance hasn't got the proxy object metadata defined yet so it fails with Doctrine\ORM\Mapping\MappingException exception "Class EntityProxy is not a valid entity or mapped super class.". If both entity managers share the proxy objects the problem can be fixed by calling $em->getProxyFactory()->getProxy('Entity', -1);  which will register the entity metadata for the proxy classname as well. Still if the proxy configuration differs, there is no fix found without changing the Doctrine ORM code. The fix inside the Doctrine would be to detect Proxy classes before loading the metadata and load the metadata for it's parent class instead. Please see the diff attached with proposed solution. Also I think this issue could arise when unserialized entity objects will be merged into the entity manager. I will try creating test case for this.

 Comment by Aigars Gedroics [ 24/Nov/11 ] Test case attached. Comment by Aigars Gedroics [ 05/Apr/12 ] See my pull request in https://github.com/doctrine/doctrine2/pull/332.

### [DDC-1438] Add test for DDC-1437 Created: 19/Oct/11  Updated: 19/Oct/11

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

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

 Description

### [DDC-1429] Add a method to the unit of work that merges any detached entity into UoW without calling SQL Created: 17/Oct/11  Updated: 17/Oct/11

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

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

 Description
 This is for those that know what they are doing

### [DDC-1415] EventListener delegate on entity basis Created: 11/Oct/11  Updated: 20/Dec/11

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

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

 Comment by Benjamin Eberlei [ 12/Dec/11 ] Removed from master, as i dont like the api at all Comment by Guilherme Blanco [ 20/Dec/11 ] Updating fix version

### [DDC-1393] Skipping tables or columns in database driver or SchemaTool Created: 24/Sep/11  Updated: 20/Dec/11

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

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

 Description
 There should be a sane way to skip sources of errors in SchemaTool and the DatabaseDriver.

 Comment by Benjamin Eberlei [ 24/Sep/11 ] Idea: Develop a datastructure of sorts that allows saving information about skipping tables and columns therein when reverse engeneering. Comment by Guilherme Blanco [ 09/Dec/11 ] This is not possible unless you take advantage of Topological Sorting to map class dependencies like we do inside of UnitOfWork AFTER creating the ClassMetadata. The necessity of having this is mandatory because we can never skip classes that have associations to other ones though FK. You may try that, but it doesn't compensate the effort. I'd rather mark this bug as won't fix, but I'm leaving for you do that. =) Comment by Guilherme Blanco [ 20/Dec/11 ] Updating fix version

### [DDC-1390]  Lazy loading does not work for the relationships of an entity instance, whose class inherits from another entity class Created: 22/Sep/11  Updated: 06/Jan/13

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

 Type: Bug Priority: Major Reporter: Daniel Alvarez Arribas Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Debian Linux 6.0, MySQL 5.0.51a

 Attachments: CommissionNoteCreatorResult.php     ConsumerInvoiceExporterResult.php     DataObject.php     DataVersion.php     DDC1390Test.php     InvoiceCreatorResult.php     Result.php     Run.php

 Description
 Lazy loading does not work for the relationships of an instance of an entity, whose class inherits from another entity class. Assume there are two entity classes, A and B, where A inherits from B. Now let $a be an instance of A, e. g. the result of "SELECT a FROM \A WHERE a.id = 1". Outputting$a will confirm it is a valid instance of a proxy object inheriting from A. Assume that the database row corresponding to $a contains a non-null foreign key that actually links to an existing row in another table, corresponding to another entity instance of a different class. Now,$a->someRelationship will always returns null in this scenario. I assume this is unintended behaviour, because clearly, the other entity should be lazily loaded on accessing it, and there is a value in the database. The fetch annotation attribute on that relationship has not been explicitly set, so I assume it is set to the default value, which, according to the docs, should be "lazy". The loading only fails when accessing the relationships of an entity instance, whose class inherits from another entity class. For entity instances, whose classes do not inherit from another entity class, lazy loading of their relationships works as expected. I had a look at the proxy objects and verified that they are present and override the __get method with an implementation containing a call to the load() method. Still, the loading won't work for some reason. This could be related to Bug DDC-1389 (http://www.doctrine-project.org/jira/browse/DDC-1389) which also happens exclusively in an inheritance scenario. Maybe the current implementation of inheritance is generally wrong or incomplete.

### [DDC-2104] BasicEntityPersister::load() doesn't allow for cache usage Created: 25/Oct/12  Updated: 12/Nov/12

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

 Type: New Feature Priority: Major Reporter: Dan McFaul Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: None Environment: This is a new feature, not a bug

 Description

### [DDC-2093] Doctrine Criteria does not support sorting by relationed field Created: 20/Oct/12  Updated: 06/Jan/13

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

 Type: Improvement Priority: Major Reporter: Bogdan Yurov Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 // Here I call Criteria filter public function getWalletsActive() { $criteria = Criteria::create() ->where(Criteria::expr()->eq("isRemoved", "0")) ->orderBy(array("currency.id" => "ASC")); return$this->wallets->matching($criteria); } // Relation /** * @var Currency * * @ORM\ManyToOne(targetEntity="Currency") * @ORM\JoinColumns({ * @ORM\JoinColumn(name="id_currency", referencedColumnName="id") * }) */ protected$currency; // File BasicEntityPersister.php // This cause the problem: if ( ! isset($this->_class->fieldMappings[$fieldName])) { throw ORMException::unrecognizedField($fieldName); } // There are no relations in$this->_class->fieldMappings at all! 

 Comment by Benjamin Eberlei [ 06/Jan/13 ] Mark as improvement.

### [DDC-2087] Select colum Hydration Created: 18/Oct/12  Updated: 18/Oct/12

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

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

 Description
 Simple way to select colum for example I want select id's of entity's to save in cache or in other select query Or i vant select one distinct field. SELECT u.id FROM User as u getResult give array( 0=>array('id' => 1), 1=>array('id' => 2), ) but how can take this array( 0=> 1, 0=> 2, )

 Comment by Ivan Borzenkov [ 18/Oct/12 ] for example http://stackoverflow.com/questions/11327798/change-the-getresult-array-key-for-the-primary-key-value this code would be good add in library (and array key maybe too )

### [DDC-2042] Metadata association overriding : allow to override 'targetEntity' Created: 26/Sep/12  Updated: 26/Sep/12

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

 Type: Improvement Priority: Major Reporter: Charles Rouillon Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 While associating object to an descriminated table I wasn't enable to fix the entityTarget (only one can be set in entity annotation). It could be resolve by adding the possibility to override 'targetEntity' value in Doctrine\ORM\Mapping\ClassMetadataInfo::ClassMetadataInfo(). Such as : if (isset($overrideMapping['targetEntity'])) {$mapping['targetEntity'] = $overrideMapping['targetEntity']; } That would need to add a control on the new targetEntity in Doctrine\ORM\Mapping\ClassMetadataInfo::_validateAndCompleteAssociationMapping(). Such as : if ( ! ClassLoader::classExists($mapping['targetEntity']) ) { throw MappingException::invalidTargetEntityClass($mapping['targetEntity'],$this->name, $mapping['fieldName']); } cro. ### [DDC-2043] Extra cache operation in DBAL\Cache\ResultCacheStatement.php Created: 26/Sep/12 Updated: 26/Sep/12 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.3 Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: Bogdan Albei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: CentOS, PHP 5.3.10  Description  This is the closeCursor() method in DBAL\Cache\ResultCacheStatement.php: public function closeCursor() {$this->statement->closeCursor(); if ($this->emptied &&$this->data !== null) { $data =$this->resultCache->fetch($this->cacheKey); if ( !$data) { $data = array(); }$data[$this->realKey] =$this->data; $this->resultCache->save($this->cacheKey, $data,$this->lifetime); unset($this->data); } }  We are using Memcache and I noticed an extra GET operation on all cache misses. In the code above I believe the fetch call is not necessary and that the code would do the same without it. Also, may I ask why is the SQL used as a key in the cached data?  Comments  Comment by Christophe Coevoet [ 26/Sep/12 ] The SQL is used as a key because it is what identifies the query which is done (well, the statement and the parameters) Comment by Bogdan Albei [ 26/Sep/12 ] The cacheKey already identifies the query(or at least it should). Would we have cases where different queries would want to use the same cache key? ### [DDC-2021] Array Data in Member OF Created: 09/Sep/12 Updated: 09/Sep/12 Status: Open Project: Doctrine 2 - ORM Component/s: DQL Affects Version/s: 2.2.3 Fix Version/s: None Security Level: All  Type: New Feature Priority: Major Reporter: vahid sohrabloo Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: array, dql  Description  Hi. First sorry for my bad english. In SELECT u.id FROM CmsUser u WHERE :groupId MEMBER OF u.groups DQL we can't use Array of groupId like ### [DDC-2007] [GH-434] allowed to pass filter objects to the configurator Created: 31/Aug/12 Updated: 05/Sep/12 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: None Fix Version/s: None Security Level: All  Type: New Feature Priority: Major Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  This issue is created automatically through a Github pull request on behalf of bamarni: Message: If DDC-2004 gets approved. ### [DDC-1999] Lazy loading doesn't get the field type when generating sql Created: 29/Aug/12 Updated: 29/Aug/12 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: victor Velkov Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  When calling with lazy loading the Sql generated doesn't convert the parameters according to their types. After debugging the problem I found that the problem is in the getType($field, $value) function in the BasicEntityPersister as it is it will never be able to return the filed type when called for lazy loading for oneToMany or ManyToMany. I put a quick fix for my self  private function getType($field, $value) { switch (true) { //here we have original code default:$type = null; // my fix starts here $fieldParts = explode('.',$field); if (count($fieldParts > 1)) { foreach ($this->_class->associationMappings as $mapping) { if (isset($mapping['joinColumnFieldNames'][$fieldParts[1]])) {$targetClass = $this->_em->getClassMetadata($mapping['targetEntity']); if (isset($targetClass->fieldNames[$fieldParts[1]])) { $type =$targetClass->fieldMappings[$targetClass->fieldNames[$fieldParts[1]]]['type']; } break; } } } //my fix end here } //here we have original code return $type; }  i have only added that check in the default case of the switch. I am not sure if that is the most elegant way. I hope that helps and that it will be fixed soon. Thanks for the great work .  Comments  Comment by Benjamin Eberlei [ 29/Aug/12 ] Fabio B. Silva Guilherme Blanco do we have a current best practice/policy regarding casting of join column types? There are some issues regarding it, this is another one. Comment by Guilherme Blanco [ 29/Aug/12 ] We avoid the manual breakdown of path expressions. Also, in BasicEntityPersister it is done behind the scenes and can get into weird scenarios. Personally speaking, I don't see how we can easily fix this issue. ### [DDC-1991] Add parameter indexBy to EntityRepository->createQueryBuilder() Created: 20/Aug/12 Updated: 20/Aug/12 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: Git Master Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: Philipp Cordes Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  createQueryBuilder() currently doesn’t have a parameter to set the third option on the FROM fragment: indexBy. Right now you have to read it, create a new From with the read properties and your desired indexBy value and replace the existing one on the QueryBuilder. Should be ten minutes’ work including tests. Thanks a lot! ### [DDC-1986] findBy hydration with limit and offset with Oracle database (oci8 driver) Created: 17/Aug/12 Updated: 08/Jan/13 Status: Awaiting Feedback Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.3 Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Benjamin Grandfond Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: oracle Environment: composer.json require : "php": ">=5.3.3", "symfony/symfony": "2.1.*", "doctrine/orm": ">=2.2.3,<2.4-dev", "doctrine/doctrine-bundle": "dev-master", "twig/extensions": "dev-master", "symfony/assetic-bundle": "dev-master", "symfony/swiftmailer-bundle": "dev-master", "symfony/monolog-bundle": "dev-master", "sensio/distribution-bundle": "dev-master", "sensio/framework-extra-bundle": "dev-master", "sensio/generator-bundle": "dev-master", "jms/security-extra-bundle": "1.2.*", "jms/di-extra-bundle": "1.1.*", "twitter/bootstrap": "master", "friendsofsymfony/rest-bundle": "dev-master", "doctrine/doctrine-fixtures-bundle": "dev-master"  Description  I tried to use the findBy method with limit and offset parameters against an Oracle database using oci8 driver. The query seems to executed successfully but the hydrator fails when hydrating data as there is a DOCTRINE_ROWNUM column appending the "limit" clause. Here is the exception thrown : "Notice: Undefined index: DOCTRINE_ROWNUM in [...]/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php line 183" I was thinking about something like this to fix this issue : add an attribute (platformExtraColumns) to the platform class, storing every column added by methods like doModifyLimitQuery check in hydrator method hydrateRowData if the column exists among the extra columns attribute of the custom platform don't use the column if true Maybe there is a better approach, what are your thoughts?  Comments  Comment by Benjamin Grandfond [ 17/Aug/12 ] I implemented it in my forks : It works for me, but I didn't write unit tests. Comment by Benjamin Grandfond [ 24/Aug/12 ] Hi, Did you have time to have a look at this issue? Thanks Comment by Christophe Coevoet [ 24/Aug/12 ] Please send a pull request when you submit a fix. It is the proper way to submit them for review. When we want to see things waiting for review, we look at the list of pending PRs, not at all comments of the issue tracker to find links in them. And I can tell you that this change has a big issue: it introduces a state in the database platform whereas it is currently stateless. This is likely to cause some issues when using more than 1 query (which is a common use case). Comment by Benjamin Grandfond [ 29/Aug/12 ] Hi Christophe thank you for your feedback. I didn't send a PR because I wanted someone sharing his thoughts about what I suggested in this current issue. However I don't really understand the stateless argument, can you explain a bit more? Otherwise how would do you proceed to tell Doctrine not to hydrate platform-specific columns? Comment by Christophe Coevoet [ 29/Aug/12 ] If you run several queries, they will be affected by the extra columns of previous requests, which is wrong Comment by Benjamin Eberlei [ 29/Aug/12 ] I think the ObjectHydrator catches this by skipping undefined columns, i think we might just have overoptimized the SimpleObjectHydrator a little bit. ### [DDC-1971] [GH-419] Add ODM embedded-like functionality Created: 07/Aug/12 Updated: 14/Aug/12 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: None Fix Version/s: None Security Level: All  Type: New Feature Priority: Major Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  This issue is created automatically through a Github pull request on behalf of djlambert: Message: This PR adds ODM embedded-like functionality to the ORM. Including the new @MappedAssociation annotation on a field having a one-to-one association adds a discriminator column to the table for storing the class name of a "mapped" entity. This allows a class or mapped superclass with a one-to-one identifying association to be extended by additional entities without requiring any code changes (as is required with the discriminator map when using inheritance). I apologize if this is the incorrect way to submit a feature request. Currently just the annotation driver has been updated, I wanted to get feedback before continuing with the remaining drivers. Models and tests are included. ### [DDC-1965] Multiple Index fails if index name not specified Created: 02/Aug/12 Updated: 02/Aug/12 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: Pont Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: Cli Environment: Ubuntu 11.04, PHP 5.3.6 with Suhosin-patch, Symfony 2.0.15  Description  @ORM\Table(name="applications", indexes={@ORM\Index(name="csl_idx", columns= {"createdAt", "status", "loanType"}), @ORM\Index(name="s_idx", columns={"status"}), @ORM\Index(name="l_idx", columns={"loanType"})}) the above Annotation creates 3 different indexes BUT when: * @ORM\Table(name="applications", indexes={@ORM\Index(columns={"createdAt", "status", "loanType"} ), @ORM\Index(columns= {"status"} ), @ORM\Index(columns= {"loanType"} )}) index-names not specified Symfony2 schemaUpdate tools shows only the last Index ### [DDC-1963] Remove by-ref access to changeset in lifecycle event args Created: 31/Jul/12 Updated: 31/Jul/12 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: None Fix Version/s: Git Master Security Level: All  Type: Improvement Priority: Major Reporter: Marco Pivetta Assignee: Marco Pivetta Resolution: Unresolved Votes: 0 Labels: None  Description  UoW currently passes computed changesets to lifecycle event args byref. This has to be changed to force users to use UoW public API to modify changesets instead. ### [DDC-1960] mapping joins in native queries breaks if select columns are starting with columns from joined table Created: 31/Jul/12 Updated: 21/Nov/12 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.1.4, 2.1.7 Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Thomas Subera Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: ubuntu kernel 2.6.32-40-server php 5.3.10-1ubuntu2ppa6~lucid with Suhosin-Patch (cli) apache 2 2.2.14-5ubuntu8.9 postgres 9.1.4-1~lucid4  Attachments: testcase.zip  Description  Using a simple Testcase like in http://docs.doctrine-project.org/projects/doctrine-orm/en/2.1/reference/native-sql.html there are two Tables: *) users:  Column | Type | Modifiers | Storage | Description ------------+---------+-----------+----------+------------- u_id | integer | not null | plain | u_name | text | not null | extended | address_id | integer | not null | plain |  *) address:  Column | Type | Modifiers | Storage | Description ----------+---------+-----------+----------+------------- a_id | integer | not null | plain | a_street | text | not null | extended | a_city | text | not null | extended |  address_id is a foreign key to address; Now i created the Entities and setup a native query using ResultSetMappingBuilder: $rsm = new \Doctrine\ORM\Query\ResultSetMappingBuilder($entityManager);$rsm->addRootEntityFromClassMetadata('MyProject\Entity\Users', 'u'); $rsm->addJoinedEntityFromClassMetadata('MyProject\Entity\Address', 'a', 'u', 'address');$query = ' SELECT u.*, a.* FROM users u LEFT JOIN address a ON (u.address_id = a.a_id) '; /** @var $native \Doctrine\ORM\NativeQuery */$native = $entityManager->createNativeQuery($query, $rsm);$ret = $native->getResult();  This returns the Entities correctly: array(2) { [0] => class MyProject\Entity\Users#61 (3) { protected$id => int(1) protected $name => string(5) "Smith" protected$address => class MyProject\Entity\Address#63 (4) { protected $id => int(1) protected$street => string(8) "Broadway" protected $city => string(8) "New York" protected$users => class Doctrine\ORM\PersistentCollection#64 (9) { ... } } } [1] => class MyProject\Entity\Users#66 (3) { protected $id => int(2) protected$name => string(7) "Sherlok" protected $address => class MyProject\Entity\Address#67 (4) { protected$id => int(2) protected $street => string(13) "Oxford Street" protected$city => string(6) "London" protected $users => class Doctrine\ORM\PersistentCollection#68 (9) { ... } } } }  BUT if you change the order of the select columns starting with ones from address you get borked Data: $query = ' SELECT a.*, u.* FROM users u LEFT JOIN address a ON (u.address_id = a.a_id) ';  array(2) { [0] => class MyProject\Entity\Users#61 (3) { protected $id => int(1) protected$name => string(5) "Smith" protected $address => class MyProject\Entity\Address#63 (4) { protected$id => int(2) protected $street => string(13) "Oxford Street" protected$city => string(6) "London" protected $users => class Doctrine\ORM\PersistentCollection#64 (9) { ... } } } [1] => class MyProject\Entity\Users#66 (3) { protected$id => int(2) protected $name => string(7) "Sherlok" protected$address => NULL } }  This happens because the function Doctrine\ORM\Internal\Hydration\AbstractHydrator::_gatherRowData does not consider the Mapping i set up. Instead it just add the columns as they get starting with address ones. Doctrine\ORM\Internal\Hydration\ObjectHydrator::_hydrateRow then knows the Mapping and ignores the first Address as there is no User to map on, cycling to the next row will then add the address of the second row to the user from the first one. There are multiple ways to fix this. One would be to consider the mapping in _gatherRowData, the second to rewrite the _hydrateRow generating the Entities first and then the mapping in a second foreach loop. This bugger had me for 2 days until i finally figured it out. thanks

 Comment by Frederic [ 21/Nov/12 ] Hello, Has same issue with using DQL /createQuery() ! Try all the day to find where was my mistake but seems to be a CRITICAL bug ! How did you solve this ? Doctrine version used : 2.3.1-DEV $query =$this->getEntityManager()->createQuery(" SELECT cc, oc FROM category cc JOIN cc.offer_category oc WHERE cc.catalog = :catalog_id ORDER BY oc.name ASC ") ->setParameter(":catalog_id", $catalog_id) ; Problem is that the order of the Aliases (cc, oc) is not considered on building SQL . In my case, in the ObjectHydrator::hydrateRowData method :$rowData = $this->gatherRowData($row, $cache,$id, $nonemptyComponents); returns Array ( [oc] => Array ( [id] => 14 [name] => toto ) [cc] => Array ( [catalog_id] => 1 [offer_category_id] => 14 ) ) As "oc" is a mapping, on the first loop the$parentAlias is not yet known and so : if ($this->_rsm->isMixed && isset($this->_rootAliases[$parentAlias])) { echo "parentObject 1\n";$first = reset($this->_resultPointers);$parentObject = $first[key($first)]; } else if (isset($this->_resultPointers[$parentAlias])) { echo $parentAlias." parentObject 2\n";$parentObject = $this->_resultPointers[$parentAlias]; } else { // HERE : on first loop, for "oc", parent not yet known so skipped !!! continue; } using a workaround on ObjectHydrator::hydrateRowData like this : $rowData = array_reverse($rowData); make it work... Sorry for my dirty explanation...

### [DDC-1957] DB -> Entity: Reverse engeniering with two relations between two tables Created: 29/Jul/12  Updated: 29/Jul/12

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

 Type: Bug Priority: Major Reporter: sky diablo Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: Cli Environment: windows 7, php 5.3, symfony 2.1

 Description

### [DDC-1954] Specialized Batch Insert Mode for the Entity Manager Created: 29/Jul/12  Updated: 29/Jul/12

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

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

 Description
 While it is already possible to speed up batch inserts by using raw SQL, that has the disadvantage to maintain a separate set of code that needs to be kept in sync with your schema. Therefore, it would be nice if the entity manager would provide a special batch insert mode where it can skip the change tracking related features, collection snapshots, etc. This might already be good enough for many people.

### [DDC-1645] Paths to Annotations classes are not considered Created: 10/Feb/12  Updated: 10/Feb/12

Status: Open
Project: Doctrine 2 - ORM
Component/s: Documentation, Mapping Drivers
Affects Version/s: 2.2
Fix Version/s: None

 Type: Improvement Priority: Major Reporter: feathers and down Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: openSUSE 12.1 x86, Apache/2.2.21, mysql 5.5.16, PHP 5.3.8 (modules: Core, ctype, curl, date, dom, ereg, filter, gd, hash, http, iconv, json, libxml, mbstring, mcrypt, mhash, mysql, mysqli, mysqlnd, pcre, PDO, pdo_mysql, pdo_sqlite, Reflection, session, SimpleXML, SPL, SQLite, sqlite3, standard, tokenizer, xml, xmlreader, xmlwriter, zip, zlib )

 Attachments: bugtracker.zip

 Description

### [DDC-1513] Missing documentation for using references in Docs Created: 28/Nov/11  Updated: 29/Nov/11

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

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

 Description
 I am in the process of switching over from Doctrine 2.0.7 to Doctrine 2.1 and one of the major missing components in my entities was the new use of using the mapping entity. Example: 

 Comment by Erik Bernhardson [ 28/Nov/11 ] I also glanced through the docs and didn't find it. I would suggest it be added to the Annotations Reference page: http://www.doctrine-project.org/docs/orm/2.1/en/reference/annotations-reference.html Comment by Thomas Gray [ 29/Nov/11 ] Ahh, so there are some docs about it; http://www.doctrine-project.org/docs/common/2.1/en/reference/annotations.html however they do not seem to be that clear; nor well linked too.

### [DDC-1507] State change detection for version incrementation (for optimistic locking) in combination with orphanRemoval Created: 23/Nov/11  Updated: 27/Nov/11

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

 Type: Improvement Priority: Major Reporter: Georg Wächter Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 As i understand the documentation correctly, orphanRemoval associations have the meaning of a "part of" relationship. In the example (http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-associations.html#orphan-removal) the adresses are part of the contact. In my opinion we should reason that the state of the adress consists of the states of all nested contacts. As a consequence we should flag the contact as "dirty" when the adresses change. This is relevant for optimistic locking scenarios or event handlers. In my application i tried to use optimistic locking for "contacts", which does not work if i don't change anything in the contact but only in the nested addresses.

 Comment by Benjamin Eberlei [ 27/Nov/11 ] This is still only an approvement, you can workaround this and handle is in your domain code. Comment by Georg Wächter [ 27/Nov/11 ] Not in all cases. The first problem is that my domain code can't modify the version property, doctrine seems to block any manipulations to it. So i'm not able to increment the variable myself. The only solution is to implement optimistic locking on my own or to add a dummy persistent boolean field that gets inversed by my domain code .. which would trigger the doctrine implementation for the optimistic locking. I think it's clear that the second option shouldn't be a choice. If doctrine doesn't handle the overall case exactly it should allow me to increment the version number myself.

Possible Regression with OneToOne relation (DDC-1461)

### [DDC-1506] Possible Regression with OneToOne relation Created: 23/Nov/11  Updated: 23/Nov/11

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

 Type: Sub-task Priority: Major Reporter: Maxim Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 /** * @ORM\Entity */ class Top { /** * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="AUTO") */ protected $id; /** * @ORM\OneToOne(targetEntity="LevelOne", orphanRemoval="true", cascade={"persist", "remove"}) */ protected$levelOne; public function getId() { return $this->id; } public function setLevelOne(LevelOne$levelOne) { $this->levelOne =$levelOne; } public function getLevelOne() { return $this->levelOne; } } /** * @ORM\Entity */ class LevelOne { /** * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="AUTO") */ protected$id; /** * @ORM\OneToOne(targetEntity="LevelTwo", orphanRemoval="true", cascade={"persist", "remove"}) */ protected $levelTwo; public function getId() { return$this->id; } public function setId($id) {$this->id = $id; } public function setLevelTwo(LevelTwo$levelTwo) { $this->levelTwo =$levelTwo; } public function getLevelTwo() { return $this->levelTwo; } } /** * @ORM\Entity */ class LevelTwo { /** * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="AUTO") */ protected$id; public function getId() { return $this->id; } public function setId($id) { $this->id =$id; } }  trying to clone objects $top = new Top();$top->setLevelOne(new LevelOne()); $top->getLevelOne()->setLevelTwo(new LevelTwo());$this->em->persist($top);$this->em->flush(); $newTop = new Top();$newTop->setLevelOne(clone $top->getLevelOne());$newTop->getLevelOne()->setId(null); $newTop->getLevelOne()->getLevelTwo()->setId(null); var_dump($newTop->getLevelOne()->getId()); var_dump($newTop->getLevelOne()->getLevelTwo()->getId());$this->em->persist($newTop);$this->em->flush();  the output is: NULL NULL [PDOException] SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'UNIQ_82A72CD0778BC57F' (it duplicates level two entity) I worked for a while with entities, in a certain set of entity properties it completely persisted into database, but without relation between level one and level two.

### [DDC-1947] Update EBNF with arbitrary joins Created: 26/Jul/12  Updated: 26/Jul/12

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

 Type: Documentation Priority: Major Reporter: Marco Pivetta Assignee: Marco Pivetta Resolution: Unresolved Votes: 0 Labels: None

 Description
 Arbitrary joins need to be documented in EBNF

### [DDC-1924] Let SQLFilters know the query type it is being applied to Created: 13/Jul/12  Updated: 13/Jul/12

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

 Type: Improvement Priority: Major Reporter: Jan Knudsen Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 I'm making an access control system and would like to automatically filter all queries based current user, targetEntity type and query type. Query type is relevant as different permissions are needed by the user for SELECT, UPDATE, DELETE and INSERT queries. I can access the first two things in my filter easily enough, but I cannot find a way to have the filter know what type of query the filter is being applied to.

### [DDC-1860] Make usage of Composer for CLI optional Created: 09/Jun/12  Updated: 09/Jun/12

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

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

 Description
 There's two problems with current CLI implementation: 1 - composer autoload.php file is hardcoded, which means that it is making assumptions about where doctrine/orm has been installed, and it also makes the assumption that doctrine/orm is not the main package. 2 - composer is a requirement, while requiring it should just fail silently and allow the end user to use his own autoloading strategy

 Comment by Marco Pivetta [ 09/Jun/12 ]

### [DDC-1859] Implement console command to convert DQL into object running NativeQuery Created: 08/Jun/12  Updated: 08/Jun/12

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

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

 Description
 As per our conversation during SFLive Paris 2012, we should create a command that receives a DQL and exposes back to you a PHP code of an object holding a conversion to NativeQuery, which is faster.

### [DDC-1829] [GH-352] Add the posibility to add a custom Comparator for Schema tool Created: 21/May/12  Updated: 22/May/12

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

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

 Description
 This issue is created automatically through a Github pull request on behalf of catacgc: Message: See catacgc/dbal#153

### [DDC-1820] [GH-348] [DDC-1819][WIP] Arbitrary object hydrator Created: 14/May/12  Updated: 27/May/12

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

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

 Description
 This issue is created automatically through a Github pull request on behalf of marijn: Message: Initial work (in progress) on a test suite for the arbitrary object hydrator, as discussed in DDC-1819[1]. Any tips are appreciated. I'm not too sure what the test suite should and should not cover. Other questions I have include: 1. Should the HYDRATE_ARBITRARY_OBJECT constant be added to the AbstractQuery class or the NativeQuery class? It only makes sense in the former but it might be missed when more constants are added in the future... 2. Should I use data providers in my tests for the result set data? 3. Should my tests be added to a DDC1819 namespace? 4. Should I add functional tests?

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

 Description
 Because you save column types in fieldmappings only, type information is not saved for join columns. Not having type info for join columns, makes it impossible to do call 'convertToPhpValue' on join columns. For example see a demo of problem here: https://github.com/doctrine/doctrine2/pull/347

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

 Type: Improvement Priority: Major Reporter: ross neacoders Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 Similar to DDC-1813 I propose saving 'quote' status in ClassmetadataInfo#quotedColumns instead of ClassmetadataInfo#fieldmappings['fieldname']['quoted'] Otherwise you have quotation info only for fieldColumns and not association columns

### [DDC-1806] DQL with and without fetch join cause Created: 01/May/12  Updated: 01/May/12

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

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

 Attachments: DDC1806Test.php     gist2473775-d202a38fdfb91921ef010df36322fb646561593a.tar.gz

 Description
 When running following DQL in newly cleared EntityManager, with the provided entities (see attached archive or gist at https://gist.github.com/2473775 ), results in different fetched association: DQL without join: SELECT a FROM Entity\A a WHERE a.id = :id SQL without join: SELECT a0_.a_id AS a_id0, a0_.id AS id1 FROM a a0_ WHERE a0_.a_id = ? Result without join: $query->getOneOrNullResult()>getB()>getName(); // 'correct' DQL with fetch join: SELECT a, b FROM Entity\A a LEFT JOIN a.b b WHERE a.id = :id SQL with fetch join: SELECT a0_.a_id AS a_id0, b1_.id AS id1, b1_.name AS name2, a0_.id AS id3 FROM a a0_ LEFT JOIN b b1_ ON a0_.id = b1_.id WHERE a0_.a_id = ? Result with fetch join:$query->getOneOrNullResult()>getB()>getName(); // 'wrong' (different result) The problem seems to be strictly related with how the @JoinColumn is configured.

 Comment by Marco Pivetta [ 01/May/12 ] Attaching failing test from https://github.com/Ocramius/doctrine2/compare/DDC-1806

### [DDC-1812] Modify ResultSetMapping#addMetaResult function definition Created: 06/May/12  Updated: 06/May/12

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

 Type: Improvement Priority: Major Reporter: ross neacoders Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 Give correct names to arguments  public function addMetaResult($alias,$columnName, $fieldName,$isIdentifierColumn = false) {  $alias - should be$tableAlias $columnName should be$columnAlias $fieldName should be$columnName Here are some exmple calls from code: AbstractEntityInheritancePersister.php 79: $this->_rsm->addMetaResult('r',$columnAlias, $joinColumnName); SqlWalker.php$this->_rsm->addMetaResult($dqlAlias,$columnAlias, $discrColumn['fieldName']);$this->_rsm->addMetaResult($dqlAlias,$columnAlias, $srcColumn, (isset($assoc['id']) && $assoc['id'] === true));$this->_rsm->addMetaResult($dqlAlias,$columnAlias, $srcColumn); ### [DDC-1803] Paginator usage with a DQL query that is using 2 time the same named binded value failed Created: 30/Apr/12 Updated: 25/Jan/13 Status: Awaiting Feedback Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: None Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Marc Drolet Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: linux, oracle  Description  I use a dql query where I bind a named parameter 2 time in the same query for different joined fields. The query work but the count query failed saying that there are missing bind variable. ex:$qb = $this->getQueryBuilder() ->select(' partial fl. {id, title, listing_date, abstract} , partial fla. {id}, partial ca.{id} , partial ds. {id} ') ->from('Fo_Listing', 'fl') ->join('fl.listing_properties', 'flp') ->join('flp.property', 'fp') ->leftjoin('fl.listing_assets', 'fla') ->leftjoin('fla.asset', 'ca') ->leftjoin('ca.ds', 'ds') ->where('fp.id = :propertyId') ->setParameter('propertyId',$id) ->andWhere('fl.object_status_id <> :deleted') ->setParameter('deleted', CoRefObjectStatus::DELETE) ->andWhere('fl.publishing_status_id = :published') ->setParameter('published', CoRefPublishingStatus::PUBLISHED) ->andWhere('fp.object_status_id <> :deleted') ->setParameter('deleted', CoRefObjectStatus::DELETE) ->andWhere('fp.publishing_status_id = :published') ->setParameter('published', CoRefPublishingStatus::PUBLISHED) ->add('orderBy', 'fl.listing_date DESC, fl.published_date DESC') ->setMaxResults($onTheMarketLimit);$onTheMarket = new Paginator($qb,$fetchJoin = true); To make it work, I've renamed the second usage of the named variable with a 2 at the end. deleted2 and published2.

 Comment by Marco Pivetta [ 23/Jan/13 ] This seems to be quite old. Marc Drolet is it still valid with the latest ORM? Comment by Marc Drolet [ 25/Jan/13 ] I'll try to test this problem on an updated version and I'll let you know. The bug entry is also quite old and I've a local modified version of the paginator here to make it work with oracle, so it can take some time before I can test this out on the current doctrine version. Comment by Marco Pivetta [ 25/Jan/13 ] Ok, marking as awaiting feedback

### [DDC-1787] Fix for JoinedSubclassPersister, multiple inserts with versioning throws an optimistic locking exception Created: 18/Apr/12  Updated: 18/Apr/12

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

 Type: Improvement Priority: Major Reporter: Jack van Galen Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Attachments: JoinedSubclassPersister.php.patch

 Description
 Attached is a small patch for a bug in the file JoinedSubclassPersister.php. When persisting multiple new entities that are subclasses of a baseclass (joined), and having the @Version attribute set, only for the last one a query is run to fetch the new value of the version field. The other one is tested with NULL, and throws an optimistic locking exception.

### [DDC-1785] Paginator problem with SQL Server around DISTINCT keyword. Created: 18/Apr/12  Updated: 19/Jan/13

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

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

 Description
 PDOException: SQLSTATE[42000]: [Microsoft][SQL Server Native Client 10.0][SQL Server]Incorrect syntax near the keyword 'DISTINCT'. (uncaught exception)

 Comment by Craig Mason [ 18/Oct/12 ] There are four major issues with this: 1: SQLServerPlatform.php modifies the query to prepend 'SELECT ROW_NUMBER() OVER ($over)', which is inserted before the DISTINCT keyword. 2: The order needs to be placed inside the OVER($over) block. At this point, the regex is using the exact column name rather than the alias, so the outer query cannot ORDER. 3: The DISTINCT queries select only the ID columns - as OVER() required the sort column to be available in the outer query, IDs alone will not work. 4: SQL Server cannot DISTINCT on TEXT columns. 2005,2008 and 2012 recommend using VARCHAR(MAX) instead, which does support it. That doesn't help us with 2003. We work around that with a custom TEXT type that casts as varchar. Incidentally, 2012 supports LIMIT, which gets rid of this issue altogether. Edit: Added #3 Comment by Craig Mason [ 18/Oct/12 ] I have a (very hacky) implementation working that uses regexes to correct the query so that it will execute. This also required modification in the ORM paginator, to select all columns instead of just IDs. This is certainly not a patch - more guidance. One interesting point... I had to wrap the whole query in a second SELECT *, as the WHERE IN confusingly returns non-distinct rows when part of the first inner query. No idea why this happens, but moving it out one layer makes it operate correctly. Comment by Craig Mason [ 25/Oct/12 ] Updated, view all commits for this experimental branch here: https://github.com/CraigMason/dbal/commits/mssql-distinct Comment by Craig Mason [ 29/Oct/12 ] This got waaaay too messy with regex alone due to the complicated nesting. As such, I have written the basis of a new SqlWalker class which can be used to create DISTINCT queries based on the root identifiers. It's not proper DISTINCT support, but it's a step forward. https://github.com/CraigMason/DoctrineSqlServerExtensions I've also added a Paginator (which was the original issue I had!) The current SqlWalker always sticks the ORDER BY on the end of the query, which just doesn't work properly with SqlServer. Is a vendor-specific walker breaking the DQL abstraction? Should this type of code be on the Platform object in the DBAL? Anyway, this repo fixes our immediate problem, and it would be good to revisit this in a wider context. Hopefully we can get some good SQL server support - there are plenty of other issues to deal with (UTF-8/UCS2, nvarchar etc) Comment by Benjamin Eberlei [ 19/Jan/13 ] Craig Mason We don't have an SQL Server expert on the team, so if you want really good support you should join and help us with it.

### [DDC-1760] [GH-324] simplified __call method Created: 03/Apr/12  Updated: 07/Apr/12

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

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

 Description
 This issue is created automatically through a Github pull request on behalf of brikou: Message:

 Comment by Benjamin Eberlei [ 04/Apr/12 ] A related Github Pull-Request [GH-324] was synchronize https://github.com/doctrine/doctrine2/pull/324 Comment by Benjamin Eberlei [ 06/Apr/12 ] A related Github Pull-Request [GH-324] was synchronize https://github.com/doctrine/doctrine2/pull/324 Comment by Benjamin Eberlei [ 07/Apr/12 ] A related Github Pull-Request [GH-324] was synchronize https://github.com/doctrine/doctrine2/pull/324

### [DDC-1756] Allow for master table only models on joined subclass inheritance Created: 03/Apr/12  Updated: 03/Apr/12

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

 Type: Improvement Priority: Major Reporter: Markus Wößner Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description

### [DDC-1750] [GH-319] [WIP] Added support to Multiple ID Generators Created: 01/Apr/12  Updated: 27/May/12

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

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

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

 Comment by Benjamin Eberlei [ 01/Apr/12 ] A related Github Pull-Request [GH-319] was synchronize https://github.com/doctrine/doctrine2/pull/319 Comment by Benjamin Eberlei [ 01/Apr/12 ] A related Github Pull-Request [GH-319] was synchronize https://github.com/doctrine/doctrine2/pull/319 Comment by Benjamin Eberlei [ 02/Apr/12 ] A related Github Pull-Request [GH-319] was synchronize https://github.com/doctrine/doctrine2/pull/319 Comment by Benjamin Eberlei [ 02/Apr/12 ] A related Github Pull-Request [GH-319] was synchronize https://github.com/doctrine/doctrine2/pull/319 Comment by Benjamin Eberlei [ 03/Apr/12 ] A related Github Pull-Request [GH-319] was synchronize https://github.com/doctrine/doctrine2/pull/319 Comment by Benjamin Eberlei [ 03/Apr/12 ] A related Github Pull-Request [GH-319] was synchronize https://github.com/doctrine/doctrine2/pull/319 Comment by Benjamin Eberlei [ 04/Apr/12 ] A related Github Pull-Request [GH-319] was synchronize https://github.com/doctrine/doctrine2/pull/319 Comment by Benjamin Eberlei [ 06/Apr/12 ] A related Github Pull-Request [GH-319] was synchronize https://github.com/doctrine/doctrine2/pull/319 Comment by Benjamin Eberlei [ 07/Apr/12 ] A related Github Pull-Request [GH-319] was synchronize https://github.com/doctrine/doctrine2/pull/319

### [DDC-2275] [GH-568] Fixed plural variable names to singular when generating add or remove methods for entities Created: 04/Feb/13  Updated: 04/Feb/13

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

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

 Description
 This issue is created automatically through a Github pull request on behalf of alexcarol: Message: Changed generateEntityStubMethod so that variable names in add or remove methods are singular too Edited tests for EntityGenerator so that variable names are checked too

### [DDC-2239] Allow dynamic modification of select queries (either filter the AST or query) Created: 11/Jan/13  Updated: 11/Jan/13

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

 Type: Improvement Priority: Major Reporter: Nathanael Noblet Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 I had built and used the following for doctrine 1: http://web.archive.org/web/20110705035547/http://www.doctrine-project.org/projects/orm/1.2/docs/cookbook/record-based-retrieval-security-template/en#record-based-retrieval-security-template I'd like to build something similar for D2 based projects. ocramius in IRC suggested a bug report/Improvement request. Figured that perhaps a custom event "dql_parse" or "ast_render" passing the AST or Query as a parameter. I'm under a tight timeline and am willing to pay for aid/feature implementation.

### [DDC-2223] unable to use scalar function when a scalar expression is expected Created: 04/Jan/13  Updated: 04/Jan/13

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

 Type: Bug Priority: Major Reporter: Alexis Lameire Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: dql Environment: (not affected by this bug)

 Description
 the DQL Parser don't parse properly functions when a ScalarExpression is needed like of all case functions. In fact first function token is interpreted as a T_IDENTIFIER and enter on line 1663 of Doctrine\ORM\Query\Parser class. in search of math operator, when not found this case considere that the token is a row element with no considération of the functions procession treated after. fix of this bug consist to enclose the line 1672 by a if (!$this->_isFunction()). ### [DDC-2219] computeChangeSets array_merging for associationMappings problem ? Created: 02/Jan/13 Updated: 07/Jan/13 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: None Fix Version/s: None Security Level: All  Type: Documentation Priority: Major Reporter: yohann.poli Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: unitofwork  Description  Is this normal that when i call "$changeset = $unitOfWork->getEntityChangeSet($myObject);", it only return changes of root Object, all changes in sub collection (OneToMany) are less (not merging in the changeset) ? Is there an issue for that?

 Comment by Marco Pivetta [ 02/Jan/13 ] Changesets of collections are computed separately from those of entities. Comment by yohann.poli [ 02/Jan/13 ] Have to call the compute method for each collection of the entity ? Comment by Benjamin Eberlei [ 06/Jan/13 ] Yes you have to, but this kind of operation seems weird. What are you trying to achieve. Comment by yohann.poli [ 07/Jan/13 ] I manage a complex entity who have a collection entity (each entity in this collection have another collection entity) attributes and i need to now if the flush method has "really" execute an update. For example if the level 3 entity is update, i have to know in the root entity all changes apply in child...

### [DDC-2193] Named native query bug? Created: 11/Dec/12  Updated: 31/Dec/12

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

 Attachments: DDC2193Test.php

 Description
 @NamedNativeQueries is a useful thing, but I have found some problems during my using. 1、Normal  /** * @NamedNativeQueries({ * @NamedNativeQuery( * name = "fetchMultipleJoinsEntityResults", * resultSetMapping= "mappingMultipleJoinsEntityResults", * query = "SELECT * FROM test " * ) * }) */  2、Error，cannot connect to the server  /** * @NamedNativeQueries({ * @NamedNativeQuery( * name = "fetchMultipleJoinsEntityResults", * resultSetMapping= "mappingMultipleJoinsEntityResults", * query = "SELECT * FROM test " * ) * }) */  3、Cannot use alias.The same problem as the second one. ....... query = "SELECT a as test FROM test " 

 Comment by Fabio B. Silva [ 12/Dec/12 ] Hi Doctrine does not change the native query at all The problem seems related with database connection. Could you provide more details please? Cheers Comment by dingdangjyz [ 13/Dec/12 ] Doctrine\Common\Lexer.php Hello, after checking， I found the problem should be here. As long as SQL wrap, or fill in alias, it will be error. It seems to be the preg_split problem?  $flags = PREG_SPLIT_NO_EMPTY | PREG_SPLIT_DELIM_CAPTURE | PREG_SPLIT_OFFSET_CAPTURE;$matches = preg_split($regex,$input, -1, $flags); foreach ($matches as $match) { // Must remain before 'value' assignment since it can change content$type = $this->getType($match[0]); $this->tokens[] = array( 'value' =>$match[0], 'type' => $type, 'position' =>$match[1], );  Comment by Fabio B. Silva [ 13/Dec/12 ] Hi Could you try to add a failing test case please ? Cheers Comment by dingdangjyz [ 14/Dec/12 ] xp php5.3.8 Apache addNamedNativeQuery(array( 'name' => 'find-hotel-item', 'query' => 'SELECT h FROM HTHotelItem h', 'resultSetMapping' => '\\Models\\Entities\\HTHotelItem' )); } function getId(){ return $this->id; } function getName(){ return$this->name; } function getCity(){ return $this->city; } function getUrl(){ return$this->url; } }  Comment by dingdangjyz [ 14/Dec/12 ] @NamedNativeQueries query If we write the long SQL, it will be fault. NO error massage. 1251 charecter must be wrong. I still insist it is the problem of preg_split in Doctrine\Common\Lexer.php Comment by Fabio B. Silva [ 16/Dec/12 ] Can't reproduce, Could you try to change the attached test case and make it fail. Cheers Comment by Benjamin Eberlei [ 24/Dec/12 ] The Doctrine\Common\Lexer is never used in combination with native queries, only with the Annotation Parser, so i cannot be the preg_split that causes your SQL to be broken. Or do you get annotation errors? Also what database are you using? maybe its related to the DBAL sql parsing? Comment by dingdangjyz [ 31/Dec/12 ] I'm sorry my English is too bad. I think it's Doctrine \ is \ Lexer. PHP preg_split the function of the problem in this file. My system environment is xp/apache 5.3 + / php_pdo_sqlsrv_53 / mssql2000

### [DDC-2183] Second Level Cache improvements Created: 03/Dec/12  Updated: 03/Dec/12

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

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

 Description
 Hibernate has a second level cache feature that is much more advanced than Doctrines result cache. With NoSQL in-memory databases such as Riak or MongoDB we could need a much more powerful cache to make Doctrine faaaaaasst. This ticket tracks the design and implementation of that feature.

### [DDC-2185] Better explain DQL "WITH" and implications for the collection filtering API Created: 04/Dec/12  Updated: 17/Dec/12

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

 Type: Documentation Priority: Major Reporter: Matthias Pigulla Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: collection, documentation, dql, filtering

 Description
 Available documentation is a bit thin regarding the "WITH" clause on JOIN expressions. Only a single example is provided in http://docs.doctrine-project.org/en/2.1/reference/dql-doctrine-query-language.html#dql-select-examples WITH seems to allow to only "partially" load a collection, so the collection in memory does not fully represent the associations available in the database. The resulting collection is marked as "initialized" and it seems there is no way to tell later on whether/how (with which expression) the collection has been initialized. When using the collection filtering API, the "initialized" flag on the collection will lead to in-memory processing. If a collection has been loaded WITH a restricting clause and another filter is applied later, results may not be what one might expect. I assume this is by design (no idea how the collection could be "partially" loaded and behave correctly under all conditions), so filing it as a documentation issue.

 Comment by Matthias Pigulla [ 17/Dec/12 ] An additional observation: If you eager-load a collection using WITH, for the resulting entities that collection is marked as initialized as described above. Should you happen to come across the same entity during hydration in another (later) context where you explicitly eager load the same association without the WITH restriction (or with another one), the collection on that (existing) entity won't be re-initialized and still contains the associated objects found during the first query.

### [DDC-2170] Decorator base classes for query related objects Created: 26/Nov/12  Updated: 26/Nov/12

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

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

 Description
 Doctrine\ORM\Query should not be directly extendable but it would be nice to decorate query objects and add additional methods. Use cases are e.g. doctrine-fun (see https://github.com/lstrojny/doctrine-fun/blob/master/src/Doctrine/Fun/Query.php) or even cases where users want to add domain specific methods. As Doctrine\ORM\Query is final it is not so easy to decorate correctly. I would propose: Add a new interfaces: Doctrine\ORM\QueryInterface that provides a contract for all methods Doctrine\ORM\Query provides Add a decorator base class Doctrine\ORM\QueryDecorator as an extension point Some for NativeQuery and QueryBuilder

 Comment by Lars Strojny [ 26/Nov/12 ] Related:

### [DDC-2166] Improve Identifier hashing in IdentiyMap Created: 25/Nov/12  Updated: 25/Nov/12

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

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

 Description
 There are currently some drawbacks with identifier hashing: They only work on one level for derived keys The code is suspect to high performance requirements Composite Keys might be suspect to weird bugs if they contain spaces. There is a PR by goetas (https://github.com/doctrine/doctrine2/pull/232) that solves some issues, however adds a performance hit. We should move the conditional logic of this code out and use a strategy pattern to improve both performance and robustness of this code.

### [DDC-2154] Traits and Code Generation Created: 18/Nov/12  Updated: 18/Nov/12

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

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

 Description

### [DDC-2141] Query should not be final Created: 13/Nov/12  Updated: 13/Nov/12

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

 Type: Improvement Priority: Major Reporter: Tarjei Huse Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: All

 Description
 The Query class should not be marked final as this makes it impossible to Mock it.

### [DDC-1099] Tutorial :: Getting started code sample entity manager Created: 04/Apr/11  Updated: 11/Jul/11

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

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

 Description
 see pull request 24 on github.com

 Comment by Michael Ridgway [ 11/Jul/11 ] This issue should be closed: https://github.com/doctrine/orm-documentation/pull/24

### [DDC-1089] Annotations reference examples are inaccurate and confusing Created: 30/Mar/11  Updated: 30/Mar/11

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

 Type: Documentation Priority: Major Reporter: Maarten van Leeuwen Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: N.A.

 Description
 In chapter 19 of the reference guide some coding examples seem to be inaccurate or incorrect. Especially when it comes to the bidirectional many-to-many associations, this might be confusing. Example: The code fragment on http://www.doctrine-project.org/docs/orm/2.0/en/reference/annotations-reference.html#annref-manytomany has the following issues: it does not include class declarations although the collections associated are both mentioned. It should be clear to which target entity they belong and therefore their classes should be declared. from the context it seems that the associated classes should probably be User and Group, and the owning side is User. So the association should probably be inversed by 'users', although the example mentions 'features'. the mapping for the inverse side maps a collection called $features, although this should probably be$users. Also the class declaration for the Group class is missing. Some other code fragments in chapter 19 have similar issues. I think they could easily be replaced by the examples from the earlier chapters, like for the bidirectional man-to-many association the example from chapter 5: http://www.doctrine-project.org/docs/orm/2.0/en/reference/association-mapping.html#many-to-many-bidirectional

### [DDC-1072] Private property mapping can cause issues, suggest changing to protected Created: 17/Mar/11  Updated: 17/Mar/11

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

 Type: Documentation Priority: Major Reporter: Kevin Bradwick Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: not applicable

 Description
 The documentation recommends using private variables in entities. This can be problematic on entities with relations when using caching drivers as the proxy objects cannot access private variables and so the caching driver can throw notices like ...apc_store(): "_id" returned as member variable from __sleep() but does not exist in ... Making member variables protected resolves this issue when caching is enabled. This information would be helpful on the documentation so others can be made aware of this issue. We spent a few days trying to debug the issue before understanding exactly what was going on.

### [DDC-1739] [GH-314] [WIP] Doctrine\Common metadata drivers reuse Created: 30/Mar/12  Updated: 07/Apr/12

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

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

 Description
 This issue is created automatically through a Github pull request on behalf of Ocramius: Message: This PR is strictly related with https://github.com/doctrine/common/pull/98 and tests won't pass until the doctrine-common submodule points to a merged version of it (will do so later, so please don't merge now ). Basically, I just stripped any code duplicate of what already available in dcom master under Doctrine\Common\Persistence\Mapping\Driver. Tests are OK on my environment when using the new commons submodule. (This is a cleanup for #263, where I sadly did pull from the remote branch after rebasing) Tests are still failing.

 Comment by Benjamin Eberlei [ 30/Mar/12 ] A related Github Pull-Request [GH-314] was synchronize https://github.com/doctrine/doctrine2/pull/314 Comment by Benjamin Eberlei [ 30/Mar/12 ] A related Github Pull-Request [GH-314] was synchronize https://github.com/doctrine/doctrine2/pull/314 Comment by Benjamin Eberlei [ 30/Mar/12 ] A related Github Pull-Request [GH-314] was synchronize https://github.com/doctrine/doctrine2/pull/314 Comment by Benjamin Eberlei [ 30/Mar/12 ] A related Github Pull-Request [GH-314] was synchronize https://github.com/doctrine/doctrine2/pull/314 Comment by Benjamin Eberlei [ 01/Apr/12 ] A related Github Pull-Request [GH-314] was synchronize https://github.com/doctrine/doctrine2/pull/314 Comment by Benjamin Eberlei [ 04/Apr/12 ] A related Github Pull-Request [GH-314] was synchronize https://github.com/doctrine/doctrine2/pull/314 Comment by Benjamin Eberlei [ 06/Apr/12 ] A related Github Pull-Request [GH-314] was synchronize https://github.com/doctrine/doctrine2/pull/314 Comment by Benjamin Eberlei [ 07/Apr/12 ] A related Github Pull-Request [GH-314] was synchronize https://github.com/doctrine/doctrine2/pull/314

### [DDC-1732] Unserialized non-initialized proxy classes should throw an exception when a method is called Created: 28/Mar/12  Updated: 28/Mar/12

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

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

 Attachments: ProxyFactory.php.patch

 Description
 When we serialize entities in a session, we often have pointers to uninitialized proxies. These proxies have $_entityPersister == null. The problem is that if you happen to call by mistake a method on such a proxy, you're not aware that this is an uninitialized proxy, and the business methods are called, with null values for every property. I think the proxy should throw an exception in that case. Attached, a patch with the proposed modification. ### [DDC-1728] There is no exact alternative function like MONTH in mysql Created: 27/Mar/12 Updated: 27/Mar/12 Status: Open Project: Doctrine 2 - ORM Component/s: DQL, ORM Affects Version/s: 2.2.0-RC1, 2.2, 2.2.1 Fix Version/s: None Security Level: All  Type: New Feature Priority: Major Reporter: Sudheesh MS Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Ubuntu 11.10  Description  i am not able to extract only month from the date field using doctrine2 using 'MONTH' function ### [DDC-1729] Translate queries into graphs of value objects (instead of array hydration?) Created: 27/Mar/12 Updated: 09/Jun/12 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: None Fix Version/s: 2.x Security Level: All  Type: New Feature Priority: Major Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  In decoupled applications the model layer returns "data-transfer-objects" through the boundary into the controller/view layer. It would make sense to have Doctrine directly generate any data-transfer/value-object from native and dql queries.  Comments  Comment by Benjamin Eberlei [ 09/Jun/12 ] Example: $dql = "SELECT new CustomerAddressView(c.id, c.name, a.id, a.street, a.number, a.city, a.code) FROM Customer c INNER JOIN c.address a WHERE c.id = ?1";  This supersedes DDC-1819. 1. One additional property in ResultSetMapping => $viewModelClass? 2. Changes to Parser (new ... syntax) 3. Changes to sQL Walker? 4. Changes to Hydration (Only object hydration!) ### [DDC-1721] LIKE clausule should accept functions on the pattern Created: 21/Mar/12 Updated: 24/Jan/13 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.1.6 Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: Ignacio Larranaga Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: None  Attachments: Parser.patch SqlWalker.patch  Description  Example: SELECT .... WHERE upper(n.title) LIKE upper(:filter) should be a valid SQL, now is rejected because the walker only accept a variable or an string expression. I'm adding a patch to address this.  Comments  Comment by Ignacio Larranaga [ 21/Mar/12 ] Sorry the Parser has to be modified also to allow expressions to be recognized, I'm attaching the necessary patch. Comment by Benjamin Eberlei [ 22/Mar/12 ] I am sure there is a reason why the walker doesn't accept this such as not all supported vendors allowing functions in right hand side LIKE expressions, but i am not sure about this. Comment by Glen Ainscow [ 03/Oct/12 ] This is not possible either: WHERE CASE WHEN p.name IS NULL THEN u.username ELSE p.name END LIKE :name Comment by Thomas Mayer [ 24/Jan/13 ] In my case it worked when using "=" instead of "LIKE". //works: (CASE WHEN (Book.id = BookFrom.id) THEN BookTo.displayName ELSE BookFrom.displayName END) = :name //[Syntax Error] line 0, col 1217: Error: Expected =, <, <=, <>, >, >=, !=, got 'LIKE' (CASE WHEN (Book.id = BookFrom.id) THEN BookTo.displayName ELSE BookFrom.displayName END) LIKE :name So the LIKE operator only needs to be allowed here. I'm wondering which vendor should not be able to handle that: The CASE WHEN ... THEN ... END is documented in DQL, and allowed. LIKE itself is allowed. If an RDBMs cannot use CASE WHEN and LIKE in combination, this would be a strange limitation. ### [DDC-1714] Prevent inverse side lazy loading owning side of the oneToOne relationsip if owning side's id is an assosiationKey of inversed side Created: 18/Mar/12 Updated: 18/Mar/12 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: None Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: David Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  This issue was originally discussed in http://www.doctrine-project.org/jira/browse/DDC-357 Say there is User and UserData with oneToOne bidirectional relationship. When we fetch User objects, UserData is lazy loaded right away. If we were to set UserData 's id as asssosiationKey of User, then user_id becomes the id of UserData and User object can already know that UserData owning side's id will equal it's own User->id. Can this be implemented? ### [DDC-1720] SqlWalter private variables should be protected to allow walker extensions Created: 21/Mar/12 Updated: 21/Mar/12 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.1.6 Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: Ignacio Larranaga Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Attachments: SqlWalker.patch  Description  I'm attaching a patch with the suggestion. ### [DDC-265] Possibility for Nested Inheritance Created: 21/Jan/10 Updated: 16/Jan/13 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: None Fix Version/s: None Security Level: All  Type: New Feature Priority: Major Reporter: Michael Fürmann Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None Issue Links:  Duplicate duplicates DDC-138 Allow for mixed inheritance mapping Open  Description  It would be great if Doctrine had the possibility to define a further inharitance in a subclass. Example: There is a class DataObject managing things like created- and lastedit- timestamps, archiving objects before updates, ... One of the sub-objects is Content. There are several types of content. Written directly to a database field, read from a textfile on server, executed php file on server, loaded from another server via xmlrpc and so on. I'd like to use a single table inheritance to map all information of the different content objects in one table. If I understand the model right the only alternate solution would be to write each single content object to the discriminator map of DataObject.  Comments  Comment by Benjamin Eberlei [ 21/Jan/10 ] The DataObject you describe is a no-go for Doctrine 2. Its just a very bad practice. Inheritance Mapping is for REAL inheritance only, otherwise you shouldnt go with a relational database in the first place. You should use the Event system for such changes, it offers you roughly the same possibilities and keeps you from having to use inheritance mapping. You could still create an abstract data object and define the fields that will be used in each "implementation" and then in events do something like: if ($entity instanceof DataObject) { $entity->updated();$archiver->makeSnapshot($entity); }  Comment by Jonathan H. Wage [ 20/Mar/10 ] With this patch I think you could setup a nice similar model where you can introduce new children of this parent class and have it added to the discriminator map from the child instead of having to modify the parents mapping information. http://www.doctrine-project.org/jira/browse/DDC-447 ### [DDC-128] Consider adding EntityManager#link/unlink methods for direct association manipulation Created: 07/Nov/09 Updated: 29/Dec/10 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.0-ALPHA2 Fix Version/s: 2.x Security Level: All  Type: New Feature Priority: Major Reporter: Roman S. Borschel Assignee: Roman S. Borschel Resolution: Unresolved Votes: 1 Labels: None Issue Links:  Reference is referenced by DDC-546 New fetch mode EXTRA_LAZY for collect... Resolved  Description  A problem when working with collection-valued associations is that almost all operations except add($obj) require the collection to become initialized in order for the operation to be performed properly. While this is all correct and beautiful OO-wise it may be problematic at times with regards to performance. Hence we might want to consider to provide some convenient methods along the lines of link/unlink (name suggestions?) which allow more direct, less OO collection manipulation. Such methods obviously would bypass the normal object lifecycle and the changes done through these methods will not be reflected in the in-memory objects and collections, unless the user keeps them in-synch himself.

 Comment by Benjamin Eberlei [ 11/Dec/09 ] Questions I suppose link and unlinked entities would then handled by UnitOfwork commit also? Since the collection is not initialized, one does not know upfront if the action will be successful, what happens if: an entity is linked with a collection, although they are already connected. an entity is unlinked from a collection it is not in. Regarding the naming, i like link/unlink. Comment by Roman S. Borschel [ 17/Dec/09 ] What do you mean by "handled by UnitOfWork commit" ? Whether the SQL is "scheduled" or executed immediately? Interesting question. Scheduling would probably be better but also more difficult. As far as usage is concerned, I currently imagine it as follows: // EntityManager#link($sourceObj,$field, $targetObj)$user = $em->getReference($userId); // $userId probably from request parameters$address = $em->getReference($addressId); // $addressId probably from request parameters$em->link($user, 'addresses',$address);  "What happens if: an entity is linked with a collection, although they are already connected." Probably an SQL error which results in an exception from the driver. Depends on the database constraints though. "What happens if: an entity is unlinked from a collection it is not in" Probably nothing, at least not from the SQL side. An exception could be thrown from Doctrine itself if the update affected 0 rows. Thanks for these initial questions. Thats definitely food for thought. Keep it coming. Comment by Roman S. Borschel [ 26/Aug/10 ] Pushed back.

### [DDC-586] Repo does not find "unflushed" object Created: 14/May/10  Updated: 26/Aug/10

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

 Type: Improvement Priority: Major Reporter: John Kleijn Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None

 Description
 The problem is this: $bar = new \entity\content\ContentTag();$bar->setName('bar'); $em->persist($bar); $existingTag =$em->getRepository('entity\content\ContentTag')->findOneByName('bar'); Seeing as in EntityRepository "find()" queries the Unit of Work first, and "findBy()" goes directly to the persister, only remotely stored objects will be found. Now if I want a tag object to attach related tags, it would have to query by name to see if an object already exist, BUT it wont find one as the UoW has not been committed, resulting in a new one being created, ultimately resulting in a PDO error on the unique name constraint. This can be "solved" by inserting a flush, but it is impossible to know whether a flush is required, without knowledge of what comes next. I.e. for one part to know it has to flush, it has to know another wants to fetch an object you just created. This causes an unacceptable amount of coupling. Somehow the repo will have to be able execute DQL against the objects in the UoW. This does not have to be full support (straight away), but it should fail (throw an exception) if the possibility exists that the UoW contains items that are excluded (e.g. the operation is not supported and the UoW still contains items). For right now, this means the EntityManager should throw an exception if DQL is executed on the type when the UoW is not empty. Until the time that the EntityManager can query the UoW using DQL. The alternative would be to "flush" before every operation that goes to the database for data.

 Comment by Roman S. Borschel [ 14/May/10 ] Hi, you mention a good point, however, this currently only affects findBy queries made through a repository. A DQL query already triggers a flush when there are pending insertions but this still has its own problems. First of, querying against the objects in the UoW is not a viable solution in my eyes. For a regular find() (by identifier) the situation is clear anyway, you must flush prior to a lookup on an entity you previously persisted in the same request because, by definition, generated primary key values are only guaranteed to be available after the next flush. Automatic flushing if the UoW has pending inserts (new objects) and a query is executed (either through DQL or a repository) currently has its own set of problems, namely that it is still subject to infinite recursion if such a query is triggered in an event (listener) that executes during commit of a UoW, and secondly, that it will easily lead to double-flushes that cause unnecessary overhead (currently a flush() even if nothing needs to be done is not free because the UoW actually has to check whether nothing needs to be done). Both of these problems could be addressed with some sort of flags, but the question still is whether its not better to flush manually in the first place. That would mean, in your example, you should flush after persisting the new objects, irrespectively of what code comes next, you persisted (a) new object(s) and you want to make sure these are fully available to the rest of the script. Comment by Roman S. Borschel [ 14/May/10 ] Furthermore, automatic flushing when there is no transaction active is probably also not a great idea, as it may split a single unit of work (that was supposed to be atomic) into 2 without the user knowing about it. So auto-flushing should better only happen when a transaction is active (i.e. explicit transaction demarcation is used). Comment by John Kleijn [ 14/May/10 ] That would mean, in every example, you should flush after persisting new objects, period. If I flush in some cases and not in others, I'm asking for issues that may not be caught by tests. It's an inconsistency that I personally am not comfortable with. Could be that I'm overlooking something, I've just started playing with D2. Why is querying against registered objects not viable? It's not easy, granted, but it doesn't seem impossible. There should probably be a layer between the UoW and the "persisters" (Data Mappers?). RE: the UoW double flush: state management on the UoW as a whole should prevent that. i.e. after a commit the whole UoW is clean? Just a suggestion, as I said, still getting my bearings. On a side note I just want to say that what I've seen so far, for the better part, pleases me greatly. Kudos. Comment by Roman S. Borschel [ 14/May/10 ] @"That would mean, in every example, you should flush after persisting new objects, period." Yes, if you want the objects to be visible to queries in the same request. Generally, you should flush when you complete a unit of work and that is usually not the whole request (but can be). I don't want to "query" against registered objects because it is a) not easy b) likely a lot of code and c) very likely error-prone. And in addition I don't see this helping with solving any inconsistency. If you want to use find() you have to flush anyway because you can not find() without having the identifier in the first place, which is only available after a flush. @RE: the UoW double flush: Yes, like I said, it can be done but it is a compromise. Having a "clean/dirty" flag in addition to calculating the changesets of the work to do (which implicitly tells us whether the UoW is dirty) adds more code and more potential for errors. Forget to update the flag in one location and you get flushes that don't do anything, because the flag was not updated. A dirty-flag for the UoW is not really required for proper working. It is similar to the approach of maintaining a separate counter for the number of elements in a collection implementation: can make many size/count requests faster but complicates the internal implementation and increases the likelihood for errors (and lock contention for the counter in a thread-safe/concurrent implementation, an interesting case where performance goes against scalability, but I digress and that does not apply to php obviously). That said, I am not strongly opposed to doing this. If you're interested in how this is specified by "big brother", take a look at section 3.8.7 of the JPA 2 specification. Shortly, with the default behavior it requires the implementation to ensure that unflushed changes are visible to queries which can be achieved by flushing these to the database automatically but only if a transaction is active, otherwise the implementation must not flush to the database. There is alternatively also a "MANUAL" flush mode, in that case the effect of updates made to entities in the UoW upon queries is unspecified. We do not have different flush modes anymore, however, in Doctrine. So I see two possible ways to go here: 1) More effort, more code, (really better?) Maintaining a dirty flag in the UoW (this could be done anyway at some point, even if 2) is chosen) Maintaining a flag to avoid infinite recursion triggered from events within a UoW commit/flush Flushing automatically when querying while there are pending inserts and a transaction is active 2) No effort, less code Removing the current auto-flush on DQL queries which is still subject to infinite recursion No automatic flushes, anywhere (less magic, so to speak?) Clearly documenting that new, unflushed entities are not visible in subsequent queries issued in the same request, and if this is desired, a flush should be issued. That's how I see it. Now we need some votes and volunteers for the implementation Personally, I am not sure yet about which version I prefer, 2) does not sound too bad for me. Comment by Roman S. Borschel [ 14/May/10 ] In Nr. 1) the case with the infinite recursion may actually be more problematic. I think you simply can not see unflushed new objects in queries made during a UoW commit. Comment by John Kleijn [ 14/May/10 ] When there's no in-memory objects inclusion, I'd say 2) as well. Again, I have no idea how this is implemented currently, but I would prefer something like this: $repo->start();$repo->register($object);$repo->commit(); Why? Commit instead of flush: "flush" has little semantic value IMO, "commit" leaves no questions: you're committing your changes (which implies that they are not, before) Operating on the repo leaves no question to what you are committing: changes of the associated type and relations configured to cascade, made after start() Register instead of persist: "persist" is misleading as the object is not immediately persisted, and as my example shows, may not be. The way I see it "start" would create a UoW associated with the repo, "commit" would calculate changes and write (the enitity manager would make sure references in other UoWs are removed). Because the way it is currently implemented (or so it seems), it's unclear when to flush and when not to flush, and unclear what I'm flushing at any one point in the code (because it is not locally isolated). If I have to decide whether to flush in some bit of client code, I am apparently making an assumption about the target entity, i.e. coupling. I know, you already went beta, so it's unlikely you would consider such a large change, but anyway, for your consideration. Finally, I realize I'm borderline nagging now as you've made it clear you see nothing it, but a Repository (as in the PoEAA pattern, p 322) may provide a method of fetching native in-memory objects using criteria, acting as a "buffer" between code and database. The Repository in D2 does effectively nothing but delegate to the UoW (or mostly to the underlying persister). Ref PoEAA 327 for an example of an in-memory strategy. As a final point of critique, the Repository does not always seem to be used as entry point for data requests, which is the whole point of the pattern. Most of what's in EntityManager, should be in EntityRepository ("manager" is a bit to abstract a concept to expect clear responsibilities anyway). EntityManager::find() delegates to EntityRepository, but pretty much everything else is the other way around. EntityManager would be better off named DataGateway, as that accurately describes its intended function. I admit, it would be very difficult to use DQL on in memory objects, but it would be far superior and if it work lead to much more predictable behaviour. It's the ONLY way the data store is ever going to be truly transparent. A few examples (DQL from the docs): SELECT u, UPPER(u.name) nameUpper FROM MyProject\Model\User u Fetch everything from the db Select all objects from the User UoW Iterate over the in memory ones and modify the name property to upper case Merge the results and return SELECT u FROM User u WHERE u.id = ?1 OR u.nickname LIKE ?2 ORDER BY u.surname DESC Execute against database Iterate over the User UoW, indexing by "surname", adding items that match the criteria Merge the results and return With joins it could get more complex, provided you want to intelligently merge results into existing objects. Question is whether that is really needed, but there's obviously a performance benefit. Actually this may already be implemented. I suspect there are edge cases, rooted in DQL still being based on SQL, but in theory it should be possible. Likely you would still want to do start(), and delegate to the driver to start an actual transaction to prevent inconsistent reads... The only way to find out if it's truly feasible is to to try it, I think. Ramble, ramble, ramble, I'm done. I know I seem critical, but it's positive critique, I love the direction you went with D2. Comment by Roman S. Borschel [ 14/May/10 ] Maybe I was not clear, with approach Nr.1 there would be in-memory objects inclusion (of new objects), in fact, there always is, due to the identity map. When you query for objects and some of them are already in memory, these are used, not again reconstructed. The EntityRepository provided by Doctrine is just a convenient mechanism for writing your own repositories. There are many different understandings for what a repository is, you can make it whatever you want it to be. Is a PoEAA repository the same as a DDD repository? Anyway, the repository could be stripped of the project, it is optional, the state management is handled by the EntityManager and UnitOfWork. These are the core components. I agree that the delegation from EntityManager#find to the repository is suboptimal in this regard and should be the other way around. Now to your question: "When should I flush?". Generally, you should flush at the end of a transaction, which in turn is a unit of work. That means, use explicit transaction demarcation. begin() ... flush() commit(). I've added some control abstractions recently that should make this even easier. I can only recommend to explicitly demarcate your transaction boundaries. As you probably know, you can not talk to your database outside of a transaction anyway. The default behavior (flush() wrapping all its stuff in a transaction) is for convenience mostly and so as not to alienate or confuse people even more who are used to autocommit mode. Concerning the naming, we mostly stick with the JPA specification and I, for one, really like the naming and I don't want to invent new names. PoEAA is far more abstract (and the examples far too specific) than what is specified in JPA, so I recommend giving that a read. The patterns in PoEAA obviously and intentionally leave a lot of room for different variants of implementation and also leave open a lot of open questions (many of the difficult questions especially, it is for a reason that the author recommends using an existing tool instead of writing your own). In my opinion it is just not feasible to query in-memory objects in a generic way, all the examples in PoEAA do not have generic but rather concrete code examples, which is obviously a lot easier. The feasible strategy, and that is what we do, is to do in-memory lookups only when querying by PK, otherwise the query is executed and afterwards nevertheless any objects reused that are already in memory (based on the PK) and not reconstructed. This is the approach we use. Thanks for your input, I do see that you are an experienced fellow in object-relational persistence, maybe we can see you as a committer some day? Comment by Roman S. Borschel [ 14/May/10 ] @ "SELECT u, UPPER(u.name) nameUpper FROM MyProject\Model\User u" This selects all users and their names in uppercase, the uppercase names are scalar values, the users are not modified! Scalar values are separate from objects. @ "... and unclear what I'm flushing at any one point in the code" flush() means: Synchronize the in-memory state of my objects with the database, making any changes that are only in-memory persistent. Nothing more, nothing less. Again, objects are always reused based on the identity map and the state that is in-memory prevails, unless you use refresh() or execute a query with the Query::HINT_REFRESH query hint. All objects you fetch from DQL, be it as a root object or as a joined association, are first looked up in-memory (but after the SQL query has been issued!). Maybe we have been talking past each other here, what I refer to as not feasible is querying the in-memory objects first in some way, even before the SQL query. This is just too complicated and error-prone, except for the simple case of a PK lookup and that is where we do it already. Comment by John Kleijn [ 14/May/10 ] > Scalar values are separate from objects. Right. Bad example. > flush() means: Synchronize the in-memory state of my objects with the database, making any changes that are only in-memory persistent. Nothing more, nothing less. I realize that it means that, but commit() would be more obvious. > Maybe we have been talking past each other here, what I refer to as not feasible is querying the in-memory objects first in some way, even before the SQL query. This is just too complicated and error-prone, except for the simple case of a PK lookup and that is where we do it already. Fair enough, you don't think it's feasible, so we'll keep it at that. Maybe I'll give it a shot some time.

### [DDC-536] Remove the _ prefix from private and protected members Created: 23/Apr/10  Updated: 19/Nov/10

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

 Type: Task Priority: Major Reporter: Roman S. Borschel Assignee: Roman S. Borschel Resolution: Unresolved Votes: 1 Labels: None

 Description
 The reasoning is simple: The prefix "_" is usually either used for easier distinction of instance variables from other, i.e. local variables, instead of always using "this." (often seen in C#), or it is used to signal that a member is not meant to be accessed from outside of the class when the language does not have visibility modifiers (PHP4). Since you always have to use "$this->" in PHP5+ when accessing instance members and there are visibility modifiers, the "_" is largely superfluous and just makes the verbose OO code even more verbose. Maybe the following find/replace steps will do the job almost completely: "private$_" => "private $" "protected$_" => "protected $" "$this->_" => "\$this->" `

 Comment by Benjamin Eberlei [ 27/Apr/10 ] i just found a possible BC issue with this. EntityRepository is allowed to be extended by us, it has several variables that are underscore prefixed. How to proceed in this case? Comment by Roman S. Borschel [ 27/Apr/10 ] I know but its not really a problem I think. We should just decide whether we make them private in the first place and provide getters instead (which would have avoided this problem in the first place). Comment by Roman S. Borschel [ 27/Apr/10 ] Leaving the prefixes on the repository class only is also an option... but I dont think thats necessary. Comment by Benjamin Eberlei [ 27/Apr/10 ] can we commit getters for Beta 1 then? We could give everyone a period until Beta 2 to fix their code and then make the change. EntityRepository is the only class that is meant to be userland extendable to my knowledge, so this should be the only problem to adress Comment by Roman S. Borschel [ 27/Apr/10 ] Yes, you can add getters and commit right away if you want. Plus adding a note on the upgrade document that direct access of these properties is deprecated. Comment by Roman S. Borschel [ 27/Apr/10 ] Persisters will be also extensible some day in userland but they need more polish for that, I've already started with it Comment by Johnny Peck [ 19/Nov/10 ] Is this still planned? Searching the code base finds this is not being implemented. It would be a good idea to implement the change sooner than later if it will be done at all. Also, +1 for the change. It makes complete sense.

### [DDC-763] Cascade merge on associated entities can insert too many rows through "Persistence by Reachability" Created: 23/Aug/10  Updated: 04/Jul/11

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

 Type: Improvement Priority: Major Reporter: Dave Keen Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 2 Labels: