### [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-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-2953] ArrayHydrator: Not all items hydrated while orderBy Created: 05/Feb/14  Updated: 06/Feb/14

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

 Type: Bug Priority: Critical Reporter: Mariusz Jaskółka Assignee: Marco Pivetta Resolution: Unresolved Votes: 0 Labels: array, hydration Environment: Linux and Windows, PHP5

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

 Description
 I will explain the problem using example and pseudo-code: I have query like that: SELECT (...) FROM order LEFT JOIN person LEFT JOIN identifier (...) order by (...) The rows returned by query are following (the order is very important): order_id|person_id|identifier_id| 12 |21 |33 | 12 |21 |34 | 11 |21 |35 | 11 |21 |33 | 11 |21 |34 | 12 |21 |35 | After hydration the result is like: result[0][person][identifier][0][id]=33 result[0][person][identifier][0][id]=34 result[1][person][identifier][0][id]=35 result[1][person][identifier][0][id]=34 But it should be: result[0][person][identifier][0][id]=33 result[0][person][identifier][0][id]=34 result[0][person][identifier][0][id]=35 result[1][person][identifier][0][id]=35 result[1][person][identifier][0][id]=34 result[1][person][identifier][0][id]=33 The reason is that ArrayHydrator::_identifierMap contains only object id and parents object id. In may example there is difference in parents parent (grandparent) id.

 Comment by Marco Pivetta [ 05/Feb/14 ] I've started work on this at https://github.com/doctrine/doctrine2/pull/933 Comment by Mariusz Jaskółka [ 06/Feb/14 ] This is how I temporary solved the issue, maybe it can help (attachment). Comment by Marco Pivetta [ 06/Feb/14 ] Mariusz Jaskółka can you provide a diff with current master? This seems to be based off 2.3 or previous versions... Comment by Mariusz Jaskółka [ 06/Feb/14 ] Version 2.4.2 oryginal file and bugfix Comment by Mariusz Jaskółka [ 06/Feb/14 ] Oh sorry it is version 2.4.1 (composer downloaded that version for me). I hope it will be ok. Comment by Marco Pivetta [ 06/Feb/14 ] Mariusz Jaskółka thanks! I'm trying it right now Comment by Mariusz Jaskółka [ 06/Feb/14 ] I added one dimention to $this->_identifierMap to be sure that all object's children's keys will be mapped separately. Comment by Marco Pivetta [ 06/Feb/14 ] Mariusz Jaskółka, I've applied your hotfix at https://github.com/doctrine/doctrine2/commit/c05921032ff6947daca2d7275031e5cde4700634 and the tests seem to pass on my system and on travis. You may want to check it out and see if it works for your use case. Comment by Mariusz Jaskółka [ 06/Feb/14 ] It works for my use case correctly. You apparently forgot to remove/comment line 82 which is not necessary now. Comment by Marco Pivetta [ 06/Feb/14 ] Mariusz Jaskółka fixed, thanks! ### [DDC-2978] OraclePlatform: rownum should not be used directly in WHERE clausule Created: 12/Feb/14 Updated: 12/Feb/14 Status: Open Project: Doctrine 2 - ORM Component/s: Mapping Drivers Affects Version/s: 2.4.1 Fix Version/s: None Security Level: All  Type: Bug Priority: Critical Reporter: Mariusz Jaskółka Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Oracle, All OSes.  Attachments: OraclePlatform.php OraclePlatform_bugfix.php  Description  At 90% of cases when we use ROWNUM in WHERE clause it will work correctly, but sometimes not. I noticed that that is why Doctrine sometimes works incorrect. Source: http://www.oracle.com/technetwork/issue-archive/2006/06-sep/o56asktom-086197.html Quote: "That is why a query in the following form is almost certainly an error: select * from emp where ROWNUM <= 5 order by sal desc; " I prepared modified OraclePlatform.php with solution (attachment) - rownum is being compared after all operations. ### [DDC-3017] UnitOfWork::$entityIdentifiers does not get updated when saving composite PK with a JoinColum as PK Created: 08/Mar/14  Updated: 08/Mar/14

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

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

 Description
 The Sonata Admin Bundle rely on the UnitOfWork::getEntityIdentifier method to retrieve the object identifier. We are adding support for composite PK with a FK as described in the gist: https://gist.github.com/rande/9439778 . The bug occurs when the Material reference is updated on the Color object. The Color has a new set of PK. However the UnitOfWork::$entityIdentifiers is not updated when the object is persisted. So the values stored UnitOfWork::$entityIdentifiers are invalid for the Color object. The consequence is that we are unable to redirect the user once the object is saved as the UnitOfWork::getEntityIdentifier refers to the old values.

### [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.  Comments  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-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.  Comments  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.  Comments  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  In the QueryBuilder section of the documentation (http://www.doctrine-project.org/docs/orm/2.1/en/reference/query-builder.html#the-expr-class) there's an example with statements like $qb->expr()->select('u')  But this doesn't work anymore.

 Comment by Michael Ridgway [ 11/Jul/11 ]

### [DDC-1269] Unexpected behavior while using association on a non primary key field Created: 11/Jul/11  Updated: 13/Jul/11

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

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

 Reference is referenced by DDC-1114 Association on a non primary key fiel... Closed

 Description
 We have association on non primary key. Something like this: Entities\Payment: type: entity table: payments fields: id: id: true type: integer nullable: false generator: strategy: IDENTITY [-- skipped --] manyToOne: order: targetEntity: Entities\Order inversedBy: payments joinColumn: name: scode referencedColumnName: scode  Entities\Order: type: entity table: h_orders fields: id: id: true type: integer unsigned: false nullable: false generator: strategy: IDENTITY scode: type: integer unsigned: false nullable: false [-- skipped --] oneToMany: payments: targetEntity: Entities\Payment mappedBy: order  When I try to fetch Order from Payment with lazy loading I receive empty Order object with null properties. If I use eager fetching Order object is valid. SQL generated for lazy loading seems to be valid, so I suppose the problem is in mapping result to the object. At the same time lazy loading works fine with 2.0.6 version. Another problem appears while persisting new Payment. $payment = new \Entities\Payment(); ...$order = $this->em->getRepository('\Entities\Order')->find(46320);$payment->setOrder($order);$order->addPayments($payment);$this->em->persist($payment);$this->em->flush();  I get this error: Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'scode' cannot be null' in /usr/share/php/Doctrine/DBAL/Statement.php:131 I found issue which is still open and looks like mine – http://www.doctrine-project.org/jira/browse/DDC-1114. What do you think about this?

 Comment by Benjamin Eberlei [ 12/Jul/11 ] Formatting, please add a second ticket for the second issue. Comment by Benjamin Eberlei [ 12/Jul/11 ] I don't think its supported to use a non primary id for foreign key matching. I cant tell for sure though since i wasnt responsible to design this part of the Doctrine code. I would strongly suggest not to do this. Comment by Benjamin Eberlei [ 12/Jul/11 ] Marked as improvement. The problem is we cannot detect this invalid mapping, so no exception is thrown during compilation of the mappings, Comment by Benjamin Eberlei [ 12/Jul/11 ] This kind of mapping error is already acknowledged by the schema-validator console task. Comment by Alexandr Torchenko [ 13/Jul/11 ] Should I create second ticket? Please confirm that I understood correctly. Should we avoid such mapping as it is considered as invalid. Comment by Benjamin Eberlei [ 13/Jul/11 ] Yes, it will not work at all. You dont need to create the second ticket as that error steams from the mapping error. You will see an error message when calling ./doctrine orm:schema:validate with this mapping.

### [DDC-1263] @ManyToOne Arbitrary References Created: 09/Jul/11  Updated: 09/Jul/11

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
 Could it be possible to allow for arbitrary many to one entities through a "class + id" construct as join columns?

### [DDC-1259] Atomic creation of Proxy files Created: 08/Jul/11  Updated: 09/Jul/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
 From 265e5086ea51ebcafc73f91abc64334d17e2f416 Mon Sep 17 00:00:00 2001 From: Karsten Dambekalns Date: Wed, 25 May 2011 12:11:55 +0200 Subject: [PATCH 4/5] Use temporary file and rename for proxy class creation Instead of a simple file_put_contents() the proxy class code is written to a temporary file and renamed to the final filename. This allows file access even if only allowed by the directory permission. --- lib/Doctrine/ORM/Proxy/ProxyFactory.php | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/lib/Doctrine/ORM/Proxy/ProxyFactory.php b/lib/Doctrine/ORM/Proxy/ProxyFactory.php index f0cf19c..b2d42fb 100644 --- a/lib/Doctrine/ORM/Proxy/ProxyFactory.php +++ b/lib/Doctrine/ORM/Proxy/ProxyFactory.php @@ -152,7 +152,15 @@ class ProxyFactory $file = str_replace($placeholders, $replacements,$file); - file_put_contents($fileName,$file, LOCK_EX); + $temporaryFileName =$fileName . uniqid( ) . '.temp'; + $result = file_put_contents($temporaryFileName, $file ); + + if($result === FALSE) throw new \RuntimeException('The temporary proxy class file "' . $temporaryFileName . '" could not be written.'); +$i = 0; + while(!rename( $temporaryFileName,$fileName ) && $i < 5) { +$i++; + } + if($result === FALSE) throw new \RuntimeException('The proxy class file "' .$fileName . '" could not be written.'); } /** -- 1.7.4.1 

 Comment by Benjamin Eberlei [ 09/Jul/11 ] Nette Framework uses a safe stream: https://github.com/nette/nette/blob/master/Nette/Utils/SafeStream.php

### [DDC-1235] Provide fluent interfaces in stub methods Created: 28/Jun/11  Updated: 29/Oct/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: Andreas Hörnicke Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 Or maybe some template-files could be provided for all stubs. private static $_setMethodTemplate = '/** * * * @param$ */ public function ($) {$this-> = $; return$this; }'; 

 Comment by Christophe Coevoet [ 29/Oct/12 ] @beberlei this should be closed as it is the case since 2.2

### [DDC-1217] Use the DBAL ReservedKeywordsValidator in orm:validate-schema Created: 20/Jun/11  Updated: 20/Jun/11

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

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

 Description
 DBAL provides a ReservedKeywordsValidator to check whether a word is reserved. But this tool is not used by the ORM when validating the schema. It would be useful to use it to avoid WTF from users getting a PDOException when creating their schema because of this. The other solution if you don't want to add this in orm:validate-schema would be to create a dedicated command.

### [DDC-1201] DQL Example about count(*) related entity is wrong Created: 10/Jun/11  Updated: 10/Oct/11

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

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

 Description
 DQL Example about count related entity is wrong

 Comment by Aigars Gedroics [ 10/Oct/11 ] Also similar DQL in documentation URL http://www.doctrine-project.org/docs/orm/2.1/en/reference/dql-doctrine-query-language.html#pure-and-mixed-results fails parsing stage: $dql = "SELECT u, 'some scalar string', count(u.groups) AS num FROM User u JOIN u.groups g GROUP BY u.id";  with error  [Doctrine\ORM\Query\QueryException] [Semantical Error] line 0, col 40 near 'localizations)': Error: Invalid PathExpression. StateFieldPathExpression or SingleValuedAssociationField expected.  Should be "count(g.id)" instead of "count(u.groups)". ### [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. " ### [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-1143] deprecated or missing method,$cacheDriver->setManageCacheIds(true); Created: 10/May/11  Updated: 10/May/11

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

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

 Description

### [DDC-1137] SchemaTool#getUpdateSchemaSql() does not respect database identifier in table names Created: 05/May/11  Updated: 14/May/11

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

 Type: Improvement Priority: Major Reporter: Hugh Lomas Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Linux 2.6.18-194.32.1.el5.centos.plus x86_64 GNU/Linux

 Description
 Given two databases, 'foo' and 'bar', with entities in /Entities/Foo/ annotated as follows: /** * Test * * @Table(name="foo.test") * @Entity */  Create an EntityManager instance with $connectionOptions = array( 'dbname' => 'Foo', 'driver' => 'pdo_mysql', <..etc..> ); Use EntityManager#getClassMetaData( "Entities\\FooTest" ) to pass to SchemaTool#createSchema() and Doctrine appropriately creates a database table foo.test Use EntityManager#getClassMetaData( "Entities\\FooTest" ) to pass to SchemaTool#updateSchema() and Doctrine fails with Exception -> SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'test' already exists Inserting die( print_r($fromSchema, 1 ) . print_r( $toSchema, 1 ) . print_r($schemaDiff, 1 ) ); into Doctrine/ORM/Tools/SchemaTool.php line 632 shows $fromSchema outputs [_tables:protected] => Array ( [test] but$toSchema outputs [_tables:protected] => Array ( [foo.test] which causes $schemaDiff to output [newTables] => Array ( [foo.test] In summary, Doctrine/DBAL/Schema/Comparator considers foo.test a new table, because Doctrine/DBAL/Schema/AbstractSchemaManager lists its table as "test" rather than "foo.test".  Comments  Comment by Hugh Lomas [ 05/May/11 ] It seems that changing AbstractSchemaManager.php to the following corrected the issue for me, however I am not sure of any repercussions that may arise as a result, being unfamiliar with the codebase. Doctrine/DBAL/Schema/AbstractSchemaManager.php line 228 return new Table($tableName, $columns,$indexes, $foreignKeys, false, array()); Doctrine/DBAL/Schema/AbstractSchemaManager.php line 228 return new Table($this->_conn->getDatabase() . "." . $tableName,$columns, $indexes,$foreignKeys, false, array()); Comment by Benjamin Eberlei [ 14/May/11 ] Multi databases are not supported by schema manager and schema tool yet.

### [DDC-1106] Wrong inversedBy in example Created: 07/Apr/11  Updated: 07/Apr/11

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

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

 Attachments: screen-shot.zip

 Description
 on page http://www.doctrine-project.org/docs/orm/2.0/en/reference/working-with-objects.html section : 8.1. Association Example Entities, first example. Please see the .jpg in attachement(it explains clearly what I think is an error) Regards.

### [DDC-1038] there are tabs in the code base Created: 16/Feb/11  Updated: 16/Feb/11

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

 Type: Task Priority: Major Reporter: Lukas Kahwe Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 a quick search through the ORM code base finds quite a few tabs. other doctrine projects there might also be some, though in common i only found some inside the LGPL license file.

MsSQL-Server DateTime microseconds issue (DDC-1028)

### [DDC-1032] ensure the dateformat Y-m-d gets used by the MsSQL-Server 2005 Created: 14/Feb/11  Updated: 14/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: Sub-task Priority: Major Reporter: Martin Weise Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: php5.3.5; MsSQL-Server 2005; W2K8; Apache2; MS pdo_sqlsrv_ts_vc6 driver

 Description
 To ensure that the MsSQL-Server 2005 (and maybe higher) uses the format that is specified in the MsSqlPlatform class (Y-m-d) set it via 'SET DATEFORMAT ymd' . This should be done directly after the connection has be opened.

 Comment by Martin Weise [ 14/Feb/11 ] Issue created as wished from Juozas Kaziukenas.

### [DDC-1025] Please repalce 'Doctrine\XXX\YYY' with '\Doctrine\XXX\YYY' in code and document Created: 09/Feb/11  Updated: 13/Dec/11

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

 Type: Improvement Priority: Major Reporter: ben yan Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 7 Labels: None

 Description
 It will help us use the namespace and code autocomplete in some IDE.

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

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

 Description

### [DDC-1380] Standardize proxy class naming Created: 18/Sep/11  Updated: 18/Sep/11

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

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

 Description

### [DDC-1371] Optimistic Locking using hash column or all columns Created: 10/Sep/11  Updated: 10/Sep/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
 We can implement optimistic locking using hash values or other all columns of an entity

### [DDC-1357] Queries with multiple joins resulting in multiple scalar results for each top level entity only retain one scalar value for each entity Created: 01/Sep/11  Updated: 01/Sep/11

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

 Description
 Consider this example: select g.id, u.id, u.status, count(p.phonenumber) numPhones from Group * g join g.user u join u.phonenumbers p group by g.id, u.status, u.id With data: phonenumbers: [1, 2, 3, 4, 5, 6] users: [{id: 1, status: developer, phonenumbers: [1, 2]}, {id: 2, status: developer, phonenumbers: [3]}, {id: 3, status: developer, phonenumbers: [4, 5, 6]}] groups: [{id: 1, users: [1, 2]]}, {id:2, users: [3]}]  The result currently is: array( array( 0 => object(CmsGroup) { 'id' => 1, 'users' => Collection( object(CmsUser) { 'id' => 1 }, object(CmsUser) { 'id' => 2 } ) }, 'numPhones' => 1 ), array( 0 => object(CmsGroup) { 'id' => 2, 'users' => Collection( object(CmsUser) { 'id' => 3 } ) }, 'numPhones' => 3 ) )  Note that the first entry contains only one value numPhones => 1, even though there are two users associated with that group. One of whom has 2 phone numbers and the other has 1. The result I would expect is: array( array( 0 => object(CmsGroup) { 'id' => 1, 'users' => Collection( object(CmsUser) { 'id' => 1 }, object(CmsUser) { 'id' => 2 } ) }, 'numPhones' => array(2, 1) ), array( 0 => object(CmsGroup) { 'id' => 2, 'users' => Collection( object(CmsUser) { 'id' => 3 } ) }, 'numPhones' => array(3) ) )  The difference is that numPhones for each row now contains an array of the scalar values matching the corresponding users.

 Comment by Nils Adermann [ 01/Sep/11 ] You can find a test case for the correct result here: https://github.com/naderman/doctrine2/commit/a1ca3d9847cbc514fc951fb0b221b26fe03a6619

### [DDC-1347] Github-PR-110 by shesek: Support NULL in EntityRepository's magic findBy and findOneBy methods Created: 25/Aug/11  Updated: 25/Aug/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
 This issue is created automatically through a Github pull request on behalf of {username} : Message: The magic findBy and findOneBy methods don't support passing NULL as the value, because ["we cannot (yet) transform it into IS NULL"](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/EntityRepository.php#L207). However, BasicEntityPersister::_getSelectConditionSQL() [does support that](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L1229). It seems like leftovers from when there was no support for it. I tried it locally (after applying this change) and it does seem to work well.

### [DDC-1342] Github-PR-109: Remove trailing spaces Created: 21/Aug/11  Updated: 21/Aug/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
 alOneh created a pull request on Github:

### [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-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-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-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-1923] Type conversion error with oracle Created: 12/Jul/12  Updated: 12/Jul/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: Alexander Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: None

 Description

### [DDC-1894] Cannot view Doctrine 2.2 QueryBuilder documentation Created: 27/Jun/12  Updated: 27/Jun/12

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

 Type: Documentation Priority: Major Reporter: Douglas Teoh Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Chrome, Firefox, Safari on OS X

 Description
 Visiting the following page: http://www.doctrine-project.org/api/orm/2.2/class-Doctrine.ORM.QueryBuilder.html always redirects back to http://www.doctrine-project.org/api/orm/2.2/

### [DDC-1882] AbstractQuery#getResultCacheId() should be public to be able to manage the cache Created: 19/Jun/12  Updated: 19/Jun/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: AbstractQuery.patch

 Description
 The method getResultCacheId of Doctrine\ORM\AbstractQuery should be public. I'm trying to customize the cache refresh mechanism to clear previously cached objects in my app. To do that I'm adding a prefix to define regions in the cache. To be able to set the Id's correctly (adding region prefixes) I need to get the "normal" hash doctrine were used in the normal scenario (trying to avoid introduce new code). That's why I will prefer the method to be public.

 Comment by Ignacio Larranaga [ 19/Jun/12 ] Attaching the patch despite is a trivial change.

### [DDC-1879] Orphans are neither nulled nor removed when merging a graph of detached entities Created: 18/Jun/12  Updated: 23/Jan/13

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

 Type: Bug Priority: Major Reporter: Philippe Van Eerdenbrugghe Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Doctrine 2.2.2 PHP 5.3.10 with Suhosin-Patch mysql Ver 14.14 Distrib 5.5.15, for osx10.7 Mac OS X 10.7 Lion

 Description
 When merging a graph of detached entities, the created entitied are created and the updated entities are updated but the non-present entities (which exist in the database but are not in the graph) are neither removed nor have them their association column nullified. Example : In my code I have 2 entities : Parent and Child. There is a OneToMany(cascade= {"all"} , orphanRemoval=true) relation defined in Parent. In my database I have a Parent row with an id of 1, which has 3 Children with ids 1,2,3. When I write the following code, I expect the Parent with id 1 and the Child with id 2 to be updated, a new Child to be created and the Child with id 1 and 3 to be deleted. $parent = new Parent();$parent->id = 1 // detached entity $existing_child = new Child();$child->id = 2 // detached entity $new_child = new Child(); // new entity$dinner->addChild($existing_child);$dinner->addChild($new_child);$em->merge($dinner);$em->flush();  The objects I expect to be created and updated have the correct behaviour but the old children are not touched, they are still present in the database.

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

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

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

 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

 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.

 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-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-726] DQL should deal correctly with composite primary keys Created: 30/Jul/10  Updated: 04/Oct/11

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

 Type: Improvement Priority: Major Reporter: Guilherme Blanco Assignee: Guilherme Blanco Resolution: Unresolved Votes: 1 Labels: None

 Duplicate is duplicated by DDC-1162 Add support for multi-column IN state... Resolved

 Description
 DQL should deal correctly with composite primary keys: SELECT u FROM User u WHERE u.CompositeAssocEntity = ?1 Should be converted to: SELECT ... FROM users u WHERE (u.cae_id1, u.cae_id2) = (?, ?) // or something similar  It also supports IN expressions: SELECT u FROM User u WHERE u.CompositeAssocEntity IN (?1, ?2) Should be converted to: SELECT ... FROM users u WHERE (u.cae_id1, u.cae_id2) IN ((?, ?), (?, ?)) // or something similar  MySQL, SQLite and PgSQL works smoothly. Need to check out MSSQL, Oracle and DB2.

### [DDC-688] Original Entity Data gets overridden by the change set Created: 12/Jul/10  Updated: 28/Dec/10

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

 Type: Improvement Priority: Major Reporter: Jasper Kuperus Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None Environment: Mac OS X 10.6; PHP 5.3.2; MySQL 5.1.44

 Description
 When changing data in an entity, the UnitOfWork will call computeChangeSet on a flush event. If there is a changeset, the original data ($this->_originalEntityData) gets overridden by the new data. However, the _originalEntityData should hold the original data, that was present at the time the entity was reconstituted from the database. This does no longer hold now. I think this can simply be fixed by commenting this line, however I do not know of any consequences this may bring with it:$this->_originalEntityData[$oid] =$actualData; (in computeChangeSet, after if( $changeSet )); Anyway, I ran into this problem while trying to retrieve the original data at the onFlush event of an update.  Comments  Comment by Roman S. Borschel [ 08/Aug/10 ] This is actually currently expected. You can not get access to the original data in the onFlush event right now. I'm not saying that this will never be possible but it is simply the way it works at the moment. Comment by Jasper Kuperus [ 08/Dec/10 ] Does this mean that it is currently impossible to implement a Versionable mechanism using snapshots? Comment by Benjamin Eberlei [ 09/Dec/10 ] You can hold a map of them yourself if your listener also implements the "postLoad" event: $entity = $args->getentity();$this->originalData[spl_object_hash($entity)] =$args->getEntityManager()->getUnitOfWork()->getOriginalData($entity);  Comment by Benjamin Eberlei [ 28/Dec/10 ] Changed into possible improvement for the future ### [DDC-683] EntityManager#lock() on unitialized proxy coudl be optimized Created: 10/Jul/10 Updated: 21/Jul/10 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.0-BETA2 Fix Version/s: None Security Level: All  Type: New Feature Priority: Major Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Issue Links:  Reference relates to DDC-681 PATCH: UnitOfWork#lock locks by colum... Resolved  Description  If you call lock() on an unitiialized proxy, it would be possible to combine the fetch and lock in one operation. Is this feasible from a technical / workflow perspsective?  Comments  Comment by Benjamin Eberlei [ 21/Jul/10 ] Ok this is what refresh() with LOCK support is actually needed for:  public function lock($entity, $lockMode,$lockVersion = null) { if ($this->getEntityState($entity) != self::STATE_MANAGED) { throw new InvalidArgumentException("Entity is not MANAGED."); } else if ($entity instanceof Proxy &&$entity->__isInitialized__) { $this->refresh(....); // with LOCK! } ... }  ### [DDC-678] OneToMany/OneToOne + onDelete=CASCADE may corrupt UoW. Created: 10/Jul/10 Updated: 05/Jun/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: Roman S. Borschel Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None  Description  OneToMany/OneToOne associations together with an onDelete=CASCADE schema generation hint on the @JoinColumn and appropriate foreign key constraints can potentially result in a corrupt UoW if the associated objects are already managed. We need to add tests for such scenarios and settle on a well-defined behavior in such cases.  Comments  Comment by Benjamin Eberlei [ 31/Oct/10 ] I think to preserve the semantics the following has to happen: "on-delete" => "cascade" has to implicitly set cascade = remove. This hurts performance of course vs just using the on-delete, however it won't corrupt the UoW. Comment by Benjamin Eberlei [ 02/Jan/11 ] Not entirely would it hurt performance, you could check if on-delete => cascade is set. If this is the case you wouldnt need to do an explicit remove using the UnitOfWorks cascade. Comment by Benjamin Eberlei [ 05/Jun/11 ] Changed to improvement ### [DDC-138] Allow for mixed inheritance mapping Created: 12/Nov/09 Updated: 24/Dec/10 Status: Open Project: Doctrine 2 - ORM Component/s: DQL, Mapping Drivers, ORM Affects Version/s: None Fix Version/s: None Security Level: All  Type: New Feature Priority: Major Reporter: Reinier Kip Assignee: Roman S. Borschel Resolution: Unresolved Votes: 2 Labels: None Issue Links:  Duplicate is duplicated by DDC-265 Possibility for Nested Inheritance Open  Description  Requesting implementation of mixed inheritance mapping (class table inheritance and single table inheritance). This would be especially handy when the difference between certain classes is only "implementational" (i.e. a subclass only functions differently/implements abstract methods and does not specify any additional fields). Using class table inheritance would result in tables only containing an id column. ### [DDC-1180] Indexed Associations: foreign key (association) cannot be used as indexBy field Created: 29/May/11 Updated: 02/Mar/13 Status: Open Project: Doctrine 2 - ORM Component/s: Mapping Drivers Affects Version/s: 2.1 Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: Petr Sobotka Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 3 Labels: None Environment: Using Doctrine ORM 2.1.0BETA1  Description  I am trying to index a collection by its entity's column which is also a foreign key (association). It seems to me that it is not possible at the moment. For example: /** * @Entity */ class Hotel { //$id column and other stuff /** * @oneToMany(targetEntity="Booking", mappedBy="hotel", indexBy="room") * @var Booking[] */ private $bookings; } /** * @Entity */ class Booking { /** * @var Hotel * * @Id * @ManyToOne(targetEntity="Hotel", inversedBy="bookings") * @JoinColumns({ * @JoinColumn(name="hotel_id", referencedColumnName="id") * }) */ private$hotel; /** * @var Room * * @Id * @ManyToOne(targetEntity="Room") * @JoinColumns({ * @JoinColumn(name="room_id", referencedColumnName="id") * }) */ private $room; }  Only possible workaround I found is to define another (plain) entity's property mapped to the same table column and index by it: /** * @Entity */ class Hotel { //$id column and other stuff /** * @oneToMany(targetEntity="Booking", mappedBy="hotel", indexBy="roomId") * @var Booking[] */ private $bookings; } /** * @Entity */ class Booking { // ... /** * @var Room * * @Id * @ManyToOne(targetEntity="Room") * @JoinColumns({ * @JoinColumn(name="room_id", referencedColumnName="id") * }) */ private$room; /** * @var integer $roomId * * @Column(name="room_id", type="integer", nullable=false) */ private$roomId; }  Wouldn't it be easy to support it?

 Comment by Benjamin Eberlei [ 05/Jun/11 ] It is not so easy to implement from the first gimplse and it is not a bug but an improvement/feature request. Comment by Benjamin Morel [ 02/Mar/13 ]

### [DDC-2337] Allow an entity to use its own persister to take advantage of DB level features if necessary Created: 06/Mar/13  Updated: 06/Mar/13

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

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

 Attachments: persister.patch

 Description
 I have a situation where I wanted a single table to use INSERT DELAYED. Its an audit log table where I expect each http request to generate many inserts for. In an effort to not over tax the system I implemented a custom Entity Persister so that it would work. This obviously doesn't work with all mapping drivers. However if this is a feature that you think is worth integrating I will fork it on github and complete the implementation alongside any changes/improvements requested...

### [DDC-2354] [GH-617] Wrong UnitOfWork::computeChangeSet() Created: 16/Mar/13  Updated: 16/Mar/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 fchris82: Message: Sometimes some fields are Proxy when compute "changeSet". If it is Proxy, some listeners - example Gedmo sortable listener - belive the value has changed and this leads to chaos. I check the $actualValue, if it is Proxy, the value didn't change. ### [DDC-2351] Entity Listener vs. Event Listener Created: 15/Mar/13 Updated: 15/Mar/13 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: Git Master Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: Fabian Spillner Assignee: Fabio B. Silva Resolution: Unresolved Votes: 0 Labels: None  Description  Entity Listener and Event Listener don't get same events. An example is the onFlush event, which Entity Listener doesn't get. Why are both listeners receiving different events and not same events? For consistency I'd like to see that both get same events - if I understand the purpose of Entity Listener correctly: it should be an alternative to Event Listener with same functionality but is bound to an entity.  Comments  Comment by Benjamin Eberlei [ 15/Mar/13 ] onFlush and postFlush should be propagated to entity listeners as well ### [DDC-2352] [GH-615] Update SqlWalker.php Created: 15/Mar/13 Updated: 15/Mar/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 mikemeier: Message: Always be sure that only a-z characters are used for table alias, otherwise use generic "t" for "table" ### [DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13 Updated: 22/Mar/13 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.3.2 Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Manuele Menozzi Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: orphanRemoval, proxy Environment: Tested both Mac OS X and Ubuntu  Description  There is a problem that causes duplicate records are created when EntityManager has to remove an entity due to orphanRemoval. The problem occurs only with a double flush and referred object is a proxy. I'm trying to submit a pull request for this ticket. Please, stand by. ### [DDC-2364] [GH-625] [DDC-2363] Duplicated record with orphanRemoval and proxy Created: 22/Mar/13 Updated: 22/Mar/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 mmenozzi: Message: ### [DDC-1605] No documentation about the usage of indexes with YAML and XML Created: 16/Jan/12 Updated: 08/Apr/13 Status: In Progress 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: documentation  Description  I am missing documentation about how to handle indexes in YAML and XML definition files. I had to search in the code to learn how to do that. Please add some documentation about it. This issue is related to #DDC-160 where the reporter asked for documentation about indexes in annotation mapping. EDIT: Maybe an example how I have done it with YAML would be helpful for others: User: type: entity fields: id: id: true type: integer generator: strategy: IDENTITY email: type: string length: 150 unique: true active: type: boolean indexes: indexActiveField: { name: idx_user_active, columns: [ active ] }  indexActiveField is the name of the index used by doctrine and idx_user_active is the name of the index in the database. The rest should be clear.  Comments  Comment by Christian Stoller [ 27/Sep/12 ] Hi. I got an email notification that arbuscula has changed the status to "Awaiting Feedback". Do you need any feedback from me? ### [DDC-2119] Problem with inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS Created: 03/Nov/12 Updated: 08/Apr/13 Status: Open Project: Doctrine 2 - ORM Component/s: DQL, Tools Affects Version/s: 2.1 Fix Version/s: None  Type: Bug Priority: Major Reporter: SergSW Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: dql, schematool  Attachments: dump.sql SSWTestBundle.rar  Description  I tried to create inheritance entities with save policy table per class. Simple fileds was created normally, but a field with ManyToOne type was lost. I had found a solution. In Doctrine\ORM\Tools\SchemaTool ... private function _gatherRelationsSql($class, $table,$schema) { foreach ($class->associationMappings as$fieldName => $mapping) { // if (isset($mapping['inherited'])) { // - old version /** * SSW * It's the solution */ if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass() ) { continue; }$foreignClass = $this->_em->getClassMetadata($mapping['targetEntity']); ...  But it was enough. In DQL query a simple query was made wrong. I had found a solution again. In Doctrine\ORM\Query\SqlWalker ... public function walkSelectExpression($selectExpression) ... // original => if (isset($mapping['inherited'])){ // It's the solution if (isset($mapping['inherited']) && !$class->isInheritanceTypeNone() && !$class->isInheritanceTypeTablePerClass()) {$tableName = $this->_em->getClassMetadata($mapping['inherited'])->table['name']; } else { $tableName =$class->table['name']; } ...  This problems are topical for inheritance type: INHERITANCE_TYPE_NONE and INHERITANCE_TYPE_TABLE_PER_CLASS. I don't know, may be my solutions are wrong. But some programmers want to correctly work with INHERITANCE_TYPE_TABLE_PER_CLASS. Sorry for my english.

 Comment by Fabio B. Silva [ 05/Nov/12 ] Hi SergSW Could you try to write a failing test case ? Thanks Comment by SergSW [ 06/Nov/12 ] SSW/TestBundle with the problem Comment by SergSW [ 07/Nov/12 ] I install the Symfony v2.0.18. and made small TestBundle. I made schema database, by CLI "console doctrine:schema:update --force" Result: Database schema updated successfully! But I saw that I lost a field 'user_id' in a table 'AttachTree' (see Attach) Comment by SergSW [ 07/Nov/12 ] MySQL dump Comment by Benjamin Eberlei [ 12/Nov/12 ] Adjusted example formatting, don't apologize for your English, thanks for the report! Comment by Benjamin Eberlei [ 24/Dec/12 ] What version of 2.1 are you using? We don't actually support 2.1 anymore. Inheritance has always worked as used in hundrets of unit-tests, this changes look quite major a bug to have been missed before. I can't really explain whats happening here. Comment by Marco Pivetta [ 23/Jan/13 ] SergSW news?

### [DDC-2401] INDEX BY not working on multiple columns Created: 16/Apr/13  Updated: 18/Apr/13

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

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

 Attachments: Testcase.zip

 Description
 According to the docs on this page: http://docs.doctrine-project.org/en/latest/reference/dql-doctrine-query-language.html#using-index-by The following "multi-dimensional index" should be perfectly possible, with a default hydration mode: SELECT b as business, p as product FROM Businesses b INDEX BY b.id JOIN Products p WITH b.id = p.businessid INDEX BY p.id However, b.id is completely ignored (it is a numeric primary key). I tried to go further, giving 2 products a matching barcode and indexing by barcode and then a (unique, numeric) productid. Only the barcode worked as a key and only one of the products with a matching barcode was selected. I used this query to test: SELECT p FROM Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id I also flagged the docs, because I don't think a userid should/could be starting from 0.

 Comment by Fabio B. Silva [ 18/Apr/13 ] Hi Quintenvk Could you please try to write a failing test case ? Thanks Comment by Quintenvk [ 18/Apr/13 ] I added a testcase. Please note that the database settings are to be configured in Core/simplys/simplys.php, and that the dump is in dummy.sql. Apart from that all should run well immediately. Comment by Quintenvk [ 18/Apr/13 ] Fabio, Please check the zip I just attached. I hope this helps you in finding the problem. Thanks, Quinten Comment by Fabio B. Silva [ 18/Apr/13 ] Thanks Quintenvk, SELECT p.barcode, p.id, p.name FROM \core\Simplys\Entity\Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id In this DQL you are trying to index by scalar values, I think we does not support that, and a single dimensional array is the expected result in this case. Also the INDEX BY documentations seems wrong to me. The given DQL :  SELECT u.id, u.status, upper(u.name) nameUpper FROM User u INDEX BY u.idJOIN u.phonenumbers p INDEX BY p.phonenumber  Show the following result : array 0 => array 1 => object(stdClass)[299] public '__CLASS__' => string 'Doctrine\Tests\Models\CMS\CmsUser' (length=33) public 'id' => int 1 .. 'nameUpper' => string 'ROMANB' (length=6) 1 => array 2 => object(stdClass)[298] public '__CLASS__' => string 'Doctrine\Tests\Models\CMS\CmsUser' (length=33) public 'id' => int 2 ... 'nameUpper' => string 'JWAGE' (length=5)  Which IMHO represents another DQL, something like :  SELECT u, p , upper(u.name) nameUpper FROM User u INDEX BY u.id JOIN u.phonenumbers p INDEX BY p.phonenumber Comment by Quintenvk [ 18/Apr/13 ] Thanks for your reply Fabio. Do you think there could be alternatives (apart from a foreach-loop) to achieve the expected result? Thanks, Quinten Comment by Fabio B. Silva [ 18/Apr/13 ] Not sure if it's exactly the result you need but you can try Something like : SELECT p, b FROM \core\Simplys\Entity\Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id or something like : SELECT PARTIAL p.{id, barcode, name}, b.{id, attributesYouNeed} FROM \core\Simplys\Entity\Products p INDEX BY p.barcode JOIN p.businessid b INDEX BY p.id And than : $result =$query->getArrayResult();  Comment by Quintenvk [ 18/Apr/13 ] Both produce the same result as the query I had. I think i'll move on to loops after a bit more research, too bad it can't be done (at least for now) though... Would've been nice. Thanks for your help though!

### [DDC-2405] Changing strategy generates bad query. Created: 19/Apr/13  Updated: 21/Apr/13

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

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

 Description

### [DDC-2167] [GH-522] [DDC-2166] Refactor identity hash generation Created: 25/Nov/12  Updated: 01/May/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: 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 beberlei: Message: This work prepares for the merge of GH-232, allowing more complex and robust identifier hash generation.

### [DDC-2254] Exporting and restoring a query. Created: 23/Jan/13  Updated: 04/May/13

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

 Type: Improvement Priority: Major Reporter: Dries De Peuter Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: dql, rebuild, restore, save Environment: OSX

 Description
 When you have a queryBuilder and you want to break it down using getDQLParts, You can't restore it by looping over the parts and adding them. This is what I am doing: $parts =$qb->getDQLParts(); // save the parts and use them in a different environment. $newQb =$em->createQueryBuilder(); foreach ($parts as$name => $part) {$newQb->add($name,$part); } 

 Comment by Dries De Peuter [ 23/Jan/13 ] I wrote a test showing the issue. https://github.com/NoUseFreak/doctrine2/commit/8574b79fd3d245532bbe7e310c5cbe083892057a Comment by Benjamin Eberlei [ 04/May/13 ] This is not a bug, because restoring queries is not yet a feature of the QueryBuilder. Marking as possible improvement for future.

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

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

 Type: Bug Priority: Major Reporter: Bruno Jacquet Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Mysql 5.1.66 / Symfony 2.2.1

 Description
 For a parent class: /** * @ORM\Entity * @ORM\Table(name="Base") * @ORM\InheritanceType("JOINED") * @ORM\DiscriminatorColumn(name="discr", type="string") * @ORM\DiscriminatorMap({"child1" = "Child1", "child2" = "Child2"}) */  and simple Child1 & Child2 entities. With another entity (let's call it ExternalEntity) having a bidirectional OneToOne relation owned by Child1: class Child1 extends Base { /** * @ORM\OneToOne(targetEntity="ExternalEntity", inversedBy="xxx") * @ORM\JoinColumn(onDelete="CASCADE", nullable=false) */ private theForeignKey; }  Enough for the context. The symptoms: $em->remove(instanceOfExternalEntity); removes the ExternalEntity row and the Child1 row. But a dangling row in the Base table is still there for the now inexistent Child1 instance. Though, a manual delete of either the associated Child1 OR Base row and then the ExternalEntity works. The problem with the cascading deletion of the parent seems to be only present when deleting through a MYSQL cascading delete from another row which has a foreign key on a child. (Not tested with a foreign key on the parent though)  Comments  Comment by Benjamin Eberlei [ 04/May/13 ] Can you show the CREATE TABLE and FOREIGN KEY statements of all the tables involved? It seems the cascade of the foreign keys is not propagated between multiple tables? Comment by Bruno Jacquet [ 06/May/13 ] CREATE TABLE Base (id INT AUTO_INCREMENT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; CREATE TABLE Child1 (id INT NOT NULL, foreignKey INT NOT NULL, UNIQUE INDEX UNIQ_179B6E88E992F5A (foreignKey), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB; ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E88E992F5A FOREIGN KEY (foreignKey) REFERENCES ExternalEntity (id) ON DELETE CASCADE; ALTER TABLE Child1 ADD CONSTRAINT FK_179B6E8BF396750 FOREIGN KEY (id) REFERENCES Base (id) ON DELETE CASCADE; Comment by Bruno Jacquet [ 06/May/13 ] The problem is that, the SQL model never explicitely tells the DB to delete the corresponding Base when Child1 gets removed. It looks like it is handled by the doctrine entity manager layer and not the actual DB engine (Base has no on delete cascade nor foreign key to its children). So only doctrine can add the logic here because it knows the entity schema. But in this case, when it is deleted from another table, it looks like the special treatment is not triggered. Comment by Bruno Jacquet [ 06/May/13 ] Maybe using cascade={"remove"} , instead of onDelete="CASCADE" to force the cascading process to be handled by doctrine would workaround the bug... But I prefer to have my DB do the logic work as much as possible. ### [DDC-2147] Custom annotation in MappedSuperclass Created: 15/Nov/12 Updated: 07/May/13 Status: Awaiting Feedback Project: Doctrine 2 - ORM Component/s: Mapping Drivers, ORM Affects Version/s: 2.2.1 Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: kluk Assignee: Marco Pivetta Resolution: Unresolved Votes: 0 Labels: None Environment: Linux 3.6.6-1.fc17.x86_64  Attachments: error.log  Description  When you try use custom annotation in mappedsuperclass like here http://pastebin.com/YMxKvcLk and then i try get metadata for class i get this error Undefined index: fieldName ClassMetadataInfo.php function addInheritedFieldMapping Problem is that custom annotation doesnt have fieldName. Quick fix is add condition to test if fieldName isset.  Comments  Comment by kluk [ 15/Nov/12 ] error log from orm:validate-schema Comment by Marco Pivetta [ 23/Jan/13 ] Copying from pastebin: use \Doctrine\ORM\Mapping as ORM; use \xxx\Doctrine\Annotation\Entity as re; use \xxx\Doctrine\Annotation\Forms as rf; use \Doctrine\Common\Collections; /** * @ORM\Entity */ class EventPicture extends \Picture { /** * @ORM\ManyToOne(targetEntity="Event", inversedBy="eventPicture") * @ORM\JoinColumn(name="FK_Event", referencedColumnName="id") */ protected$event; }  use \Doctrine\ORM\Mapping as ORM; use \xxx\Doctrine\Annotation\Entity as re; use \xxx\Doctrine\Annotation\Forms as rf; use \Doctrine\Common\Collections; /** @ORM\MappedSuperclass */ class Picture extends \xxx\Doctrine\Entity\BaseEntity { /** * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="IDENTITY") * @var type */ protected $id; /** * @ORM\Column(type="string",unique=true, nullable=false) * @rf\FileUpload(fileSize="php",uploadType="local",fieldName="link",formControl="FileUploadField",image=true) * */ protected$link; }  kluk does this happen also with any other simple custom annotation? For example following: /** * @Annotation * @Target({"PROPERTY","ANNOTATION"}) */ final class Entity implements Annotation { /** * @var string */ public $value; }  Comment by kluk [ 30/Jan/13 ] the same error when using simple annotation.  fieldMappings[$fieldMapping['fieldName']] = $fieldMapping;$this->columnNames[$fieldMapping['fieldName']] =$fieldMapping['columnName']; $this->fieldNames[$fieldMapping['columnName']] = $fieldMapping['fieldName']; } }  But i dont know if this fix can break another part of doctrine. Comment by Benjamin Eberlei [ 04/May/13 ] Can you put the code of your annotations online? I can't seem to understand why this happens. Comment by kluk [ 07/May/13 ] Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml namespace libs\Doctrine\Annotation\Entity; use Doctrine\Common\Annotations\Annotation; /** @Annotation */ class CustomMapping extends Annotation { /** * * @var string */ public$className; /** * * * @var IQueryable| string */ public $dataSource; }  ### [DDC-2411] Null values get reset when rehydrating an already managed entity Created: 23/Apr/13 Updated: 09/May/13 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.3 Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Simon Garner Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: hydration  Description  Scenario: 1) You have an entity with a ManyToOne relation (and probably other kinds too, but this is all I have tested) to another entity which is nullable. For example, let's say you have a Book entity which has an "illustrator" field which refers to a Person entity, representing the person who illustrated the book. If the book is not illustrated then you set the field to null. 2) You fetch a Book (by ID) which has its illustrator set to a particular Person. 3) You set that Book's illustrator to null. 4) Without flushing, you fetch the Book again, using different criteria: for example, by title. Because entities are Identity Mapped, this will run a query but then locate the same instance in memory, and try to hydrate that instance with the old data it just fetched. 5) Any fields on the instance that have modified values retain their new values (for example, if we changed the illustrator to a different Person, this would be retained), BUT any fields on the instance which are null get overwritten with the old data (so if we previously set the illustrator to null, without flushing, it would now be reset to the Person value that it had before). There seems to be a mistaken assumption here that null values are fields that have not been hydrated, when this is not necessarily the case. Is this the intended behaviour? The code that causes this behaviour is here: https://github.com/doctrine/doctrine2/blob/e561f47cb2205565eb873f0643637477bfcfc2ff/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php#L471 If you are wondering why anybody would want to fetch the entity again in step 4, my use case for this is the Symfony Validator (but I presume there could be others). If there are any unique constraints (Symfony ones, not Doctrine ones) on the entity, e.g. if we had a unique constraint on the Book title field, then when validating the Book the Symfony Validator would check if there are already any Book entities with the same title as the Book we're validating. It will find the Book that we are working with, and because entities are identity mapped, it will act upon the same instance, and the situation above occurs. Code example: setName('John Smith');$jane = new Person(); $jane->setName('Jane Jones');$joe = new Person(); $joe->setName('Joe Bloggs');$book = new Book(); $book->setId(123);$book->setTitle('Book Title'); $book->setIllustrator($john); $book->setAuthor($jane); $em->persist($john); $em->persist($jane); $em->persist($joe); $em->persist($book); $em->flush(); // Now let's try modifying the book$book = $bookRepository->find(123);$book->getIllustrator(); // returns Person "John Smith" $book->getAuthor(); // returns Person "Jane Jones" // make some changes$book->setIllustrator(null); // illustrator is now null $book->setAuthor($joe); // author is now "Joe Bloggs" // now validate our changes with Symfony Validator // note: the same effect can also be observed with // $test =$bookRepository->findBy('title', 'Book Title'); $validator->validate($book); // what happened to our book?? $book->getIllustrator(); // returns Person "John Smith" <- should be null$book->getAuthor(); // returns Person "Joe Bloggs" <- correctly retains the new value

 Comment by Fabio B. Silva [ 24/Apr/13 ] Hi Simon, Could you please try to write a failing test case or paste your entities ? Cheers Comment by Benjamin Eberlei [ 09/May/13 ] Verified by code review that this issue exists, but it will be very tricky to fix, because the null check is there for other reasons as well.

### [DDC-2190] findBy() support finding by a single DateTime but not by multiple DateTime Created: 06/Dec/12  Updated: 09/May/13

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

 Attachments: DDC2190Test.php

 Description
 The following code works: $repository->findBy(array('date' => new \DateTime())) but the following code fails as it does not apply the conversion of the date type for each element: $repository->findBy(array('date' => array(new \DateTime(), new \DateTime('tomorrow')))

 Comment by Benjamin Eberlei [ 06/Jan/13 ] This is actually very hard to implement, the problem is that we only have ARRAY constants for PDO::PARAM_INT and PDO::PARAM_STR - all the other types would require special handling. Comment by Benjamin Eberlei [ 09/May/13 ] Attaching failing testcase. The idea is to have something like "datetime[]" as type and detect this in the SQLParserUtils of DBAL. Another approach would be to convert the values in the ORM already, before passing to the DBAL.

### [DDC-2339] [GH-605] DDC-2338 Added failing test for composite foreign key persistance Created: 07/Mar/13  Updated: 09/May/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: 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 alex88: Message: I've added this test regarding ticket DDC-2338

 Comment by Benjamin Eberlei [ 09/May/13 ] This is documented behavior and would just be an improvement

### [DDC-1970] DiscriminatorMap recursion when using self-reference Created: 06/Aug/12  Updated: 10/May/13

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

 Type: New Feature Priority: Major Reporter: Krzysztof Kolasiak Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: None

 Description
 I've ran into a problem with self-referencing entity. When fetching an entity, recursion occurs, fetching every related entity defined by ManyToOne relation (in this example $sponsor), ignoring LAZY or EXTRA_LAZY fetch mode - it executes numerous queries. /** * @ORM\Entity(repositoryClass="Acme\Bundle\UserBundle\Entity\Repository\UserRepository") * @ORM\Table(name="f_user") * @ORM\InheritanceType("JOINED") * @ORM\DiscriminatorColumn(name="type", type="string") * @ORM\DiscriminatorMap({"user_person" = "UserPerson", "user_company" = "UserCompany"}) */ abstract class UserBase extends FOSUser /* .... */ /** * @var UserBase * * @ORM\OneToMany(targetEntity="UserBase", mappedBy="sponsor") */ protected$referrals; /** * @ORM\ManyToOne(targetEntity="UserBase", inversedBy="referrals") * @ORM\JoinColumn(name="sponsor_id", referencedColumnName="id") */ protected $sponsor; `  Comments  Comment by Alexander [ 14/Aug/12 ] I have changed this into a feature request because you have hit the limitations of using inheritance and self referencing entities. Doctrine2 cannot currently lazy load UserBase#$sponsor because we don't know which proxy we have to insert. It can either be UserPerson or UserCompany. In order to know this Doctrine2 has to query the actual object to determine its type. The current strategy is then to load the actual entity because we have all data anyway. In order to implement this feature we need to insert a proxy instead of the actual entity. If we do that there should be no recursion happening. Comment by Marco Pivetta [ 21/Feb/13 ]