### [DDC-530] Create tests and documentation for possibilities of mixing inheritance mapping strategies Created: 19/Apr/10  Updated: 19/Apr/10

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

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

 Description
 It is (theoretically) possible to use different inheritance mapping strategies in the same class hierarchy as long as the different subtrees that use different mapping strategies do not have a common ancestor entity. We should add some tests for that and mention it in the docs about inheritance mapping in a new subsection "Mixing Inheritance Mapping Strategies".

### [DDC-473] Inadequate description for @MappedSuperclass in Annotations Reference Created: 25/Mar/10  Updated: 26/Aug/10

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

 Type: Improvement Priority: Minor Reporter: David Abdemoulaie Assignee: Jonathan H. Wage Resolution: Unresolved Votes: 0 Labels: None

 Description
 @MappedSuperclass An mapped superclass is an abstract or concrete class that provides persistent entity state and mapping information for its subclasses, but which is not itself an entity. This annotation is specified on the Class docblock and has no additional attributes. This doesn't adequately communicate how to use it. It took me several minutes of failing before I downloaded the PDF and did a search for @MappedSuperclass to find an example of how it's used. Specifically the following were unclear: Is this defined on the superclass or on the children classes? If it's defined on the child classes, does it take parameters? The name of the super class? It was not at all apparent to me that it was mutually exclusive with the @Entity tag

 Comment by David Abdemoulaie [ 25/Mar/10 ] Apparently it's also incompatible with several other tag as well. I thought it made sense to try the following and see if the @InheritanceType and @Discriminator___ tags would apply to the children classes: /** * @MappedSuperclass * @InheritanceType("SINGLE_TABLE") * @DiscriminatorColumn(name="type", type="string") * @DiscriminatorMap({"User" = "User", "Group" = "Group"}) */ abstract class Principal  But apparently this flags D2 to treat it as an Entity anyway, resulting in the following error: PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'sentact5.principal'  Comment by Benjamin Eberlei [ 28/Mar/10 ] I updated the documentation, the question is if we should check for the mapped superclass attribute and throw exceptions if other entity level annotations are specified. Comment by Roman S. Borschel [ 15/Apr/10 ] A mapped superclass has not many restrictions and these are mentioned in the docs (i.e. only unidirectional associations), what David mentions above should work, if it doesnt its a bug, I think DDC-511 looks like that same issue. Comment by Roman S. Borschel [ 15/Apr/10 ] David, @"Is this defined on the superclass or on the children classes?" It doesnt matter. A @MappedSuperclass can be anywhere in an inheritance hierarchy and it always does the same thing, inherit its mapping information to subclasses (but its not itself an entity). The docs say: Mapped superclasses, just as regular, non-mapped classes, can appear in the middle of an otherwise mapped inheritance hierarchy (through Single Table Inheritance or Class Table Inheritance).  as well as Entities support inheritance, polymorphic associations, and polymorphic queries. Both abstract and concrete classes can be entities. Entities may extend non-entity classes as well as entity classes, and non-entity classes may extend entity classes.  So entities, mapped superclasses and plain non-mapped classes can appear mixed in an inheritance hierarchy. Nevertheless all the classes in a hierarchy that are entities must use 1 inheritance strategy, you can not mix inheritance mapping strategies in a single class hierarchy. @"If it's defined on the child classes, does it take parameters? The name of the super class?" No, it doesnt. The docs dont mention any parameters either which is correct. @"It was not at all apparent to me that it was mutually exclusive with the @Entity tag" OK, that needs to be made clearer in the docs then.

### [DDC-1695] SQLs for PostgreSQL case sensite tables/fields are wrongly generated Created: 09/Mar/12  Updated: 06/Aug/14

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

 Type: Bug Priority: Major Reporter: Ignacio Larranaga Assignee: Marco Pivetta Resolution: Unresolved Votes: 0 Labels: None Environment: PostgreSQL 9.x, Symfony 2

 Attachments: doctrine-2.1.6.patch     SqlWalker.patch

 Description
 The SQLs for case sensitive schemas in postgreSQL are wronly generated. Example: Schema: CREATE TABLE "News" ( "IdNews" serial NOT NULL, "IdUser" bigint NOT NULL, "IdLanguage" integer NOT NULL, "IdCondition" integer, "IdHealthProvider" integer, "IdSpeciality" integer, "IdMedicineType" integer, "IdTreatment" integer, "Title" character varying, "SmallText" character varying, "LongText" character varying, "PublishDate" timestamp with time zone, "IdxNews" tsvector, "Highlight" boolean NOT NULL DEFAULT false, "Order" integer NOT NULL DEFAULT 0, "Deleted" boolean NOT NULL DEFAULT false, "Active" boolean NOT NULL DEFAULT false, "UpdateToHighlighted" boolean DEFAULT false, CONSTRAINT "News_pkey" PRIMARY KEY ("IdNews" ));  Object (I added quotes trying to generate the SQLs quoted.: 

### [DDC-1450] UnitOfWork Transaction Rollback Support Created: 24/Oct/11  Updated: 20/Dec/11

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

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

 Description
 The UnitOfWork does not handle the case very well where a rollback is necessary. Can this be optimized?

 Comment by Guilherme Blanco [ 20/Dec/11 ] Updating fix version

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

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

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

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

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

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

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

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

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

### [DDC-1445] Improve error messages Created: 22/Oct/11  Updated: 20/Dec/11

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

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

 Description
 Error messages throughout ClassMetadata validation and UnitOfWork cycles can be significantly improved. Work is being done on: https://github.com/doctrine/doctrine2/tree/ImproveErrorMessages

 Comment by Guilherme Blanco [ 20/Dec/11 ] Updating fix version

### [DDC-1320] Ship Immutable date time with Doctrine Common, use in ORM - Should implement __toString() Created: 06/Aug/11  Updated: 31/Oct/11

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

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

 Dependency depends on DDC-1316 Insert statement for joined subclass ... Resolved

 Comment by Benjamin Eberlei [ 31/Oct/11 ] Has to be pushed back as immutable date time cannot be implemented in userland that well.

### [DDC-1308] Add cache for transient information and invalidation for ClassMetadata Created: 31/Jul/11  Updated: 20/Dec/11

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

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

 Description
 Two different things have to be improved in the caching: 1. The information isTransient() has to be moved to the ClassMetadataFactory and cached there. 2. The information getAllClassMetadataNames() can be cached 3. A debug/development mode should be introduced, leading to filemtime caching and checks so that you can use ApcCache and such in development.

 Comment by Guilherme Blanco [ 20/Dec/11 ] Updating fix version

### [DDC-1264] Add more math related DQL funcs (trig, round, stuff?) Created: 09/Jul/11  Updated: 09/Jul/11

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

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

### [DDC-1262] Have proxies copy docblocks aswell Created: 09/Jul/11  Updated: 09/Jul/11

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

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

 Description
 Whenever a Proxy is generated it does not copy the docblocks. This means when you do something like "$refl = new ReflectionObject($proxy)" you might be in trouble. However if we add docblocks then we have to make sure that proxies do not magically appear as entities by throwing an exception in the AnnotationDriver.

### [DDC-1229] generate entity interactive dialog: id column Created: 27/Jun/11  Updated: 28/Jun/11

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

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

 Description
 according to Stof, this bug https://github.com/sensio/SensioGeneratorBundle/issues/21 comes from the doctrine tools implementation: in the dialog, i first specified that i want a field id of type integer. the result was [Doctrine\ORM\Mapping\MappingException] Duplicate definition of column 'id' on entity 'Liip\DemoBundle\Entity\Event' in a field or discriminator column mapping. and no file was created. The dialog should tell me i can not create a field named id. (Or better ask first if i want my id column named id or something else.) It would be nice if it would write some file even if its not valid, with a warning on top. As it is, i lost all my work of specifying fields. (Luckily was just playing around)

 Comment by Benjamin Eberlei [ 28/Jun/11 ] not a bug, its a feature (though a dumb one). Improvement in a next version.

### [DDC-1219] Remove dependancy on Collection interface in Domain Objects Created: 21/Jun/11  Updated: 04/Jul/11

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

 Type: Improvement Priority: Major Reporter: André R. Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None

 Description
 Short: This issue is all about being able to use doctrine with naked domain objects without any use of doctrine classes. I 'm not talking about PersistentCollection here, fully aware of that being tied into Doctrine, but those are injected, this is all about code dependency on ArrayCollection. Seems like some of the UnitOfWork code is cable of handling other types of arrays, like:  // If $actualData[$name] is not a Collection then use an ArrayCollection. if ( ! $actualData[$name] instanceof Collection) { $actualData[$name] = new ArrayCollection($actualData[$name]); }  But in __cascade* functions this is not the case in all but two:  if ($relatedEntities instanceof Collection) { if ($relatedEntities instanceof PersistentCollection) { // Unwrap so that foreach() does not initialize  2 however have:  if (($relatedEntities instanceof Collection || is_array($relatedEntities))) { if ($relatedEntities instanceof PersistentCollection) { // Unwrap so that foreach() does not initialize  Would it be an idea to do "instanceof Traversable" instead of " instanceof Collection"?  Comments  Comment by André R. [ 21/Jun/11 ] Note: If the fist code block is always performed before the last 2 blocks then there is no issue here, just a need to make it more clear in Doc that this is possible but that you should not rely custom implementation as PersistentCollection will be injected when loaded from db. ### [DDC-1178] Have access to "original" metadata in events subscribed to loadClassMetadata Created: 27/May/11 Updated: 27/May/11 Status: Open Project: Doctrine 2 - ORM Component/s: Mapping Drivers Affects Version/s: 2.x Fix Version/s: 2.x Security Level: All  Type: New Feature Priority: Major Reporter: Miha Vrhovnik Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  If you subscribe to loadClassMetadata you will usually modify the metadata for some classes. The problem is, that that data has to be loaded from somewhere. But later down the chain you can't get to it. Now data specific to what you need in your loadClassMetadata would ideally reside in the same location. If we take for example a file, than all data for a specific entity is in the same file. My proposal would be to add function get(Original|Raw)MappingData into interface Doctrine\ORM\Mapping\Driver\Driver which would either return raw data or data in a object specific for that Driver or null if it doesn't make sense for that driver. Please note, that when loading from e.g XmlDriver we should return simplexmlnode or dom node as loadClassMetadata should be in its own namespace and not pollute the Doctrine one.  Comments  Comment by Gediminas Morkevicius [ 27/May/11 ] Sounds logic, each driver would expect NULL or data (wrapped specifically for the driver used) ### [DDC-947] Optmize Code-Generation Strategies Created: 24/Dec/10 Updated: 29/Mar/11 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: None Fix Version/s: 2.x Security Level: All  Type: Improvement Priority: Major Reporter: Benjamin Eberlei Assignee: Jonathan H. Wage Resolution: Unresolved Votes: 0 Labels: None  Description  We should optimize code-generation somehow.  Comments  Comment by Benjamin Eberlei [ 29/Mar/11 ] Descheduled to 2.x ### [DDC-896] Use PDepend for Code-Generation Created: 27/Nov/10 Updated: 27/Nov/10 Status: Open Project: Doctrine 2 - ORM Component/s: Tools Affects Version/s: None Fix Version/s: 2.x Security Level: All  Type: Improvement Priority: Major Reporter: Benjamin Eberlei Assignee: Jonathan H. Wage Resolution: Unresolved Votes: 0 Labels: None  Description  Our current code-generation tool has many shortcomings and due to its hard to test nature also many (known and unknown) bugs, as well as high maintenance. Since people are overusing this tool and I am sort of annoyed by how much time goes into this we should rewrite this in a two-step procedure: 1. Move code into Common so we can share it between ORM, Mongo and CouchDB. 2. Use PDepend to read an entities source file (it generates an AST) and modify the AST with the required changes. This gives us the advantage of having to maintaining less code for this stuff. ### [DDC-810] Issue with detaching entities and updating when using change notification Created: 17/Sep/10 Updated: 04/Jul/11 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: 2.0-BETA4 Fix Version/s: 2.x Security Level: All  Type: Improvement Priority: Major Reporter: Jonathan H. Wage Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None  Attachments: DDC810Test.php  Description  More information coming soon. Attaching a test case  Comments  Comment by Benjamin Eberlei [ 20/Sep/10 ] From reading the issue i know what the bug is, indeed this sucks. Comment by Roman S. Borschel [ 28/Sep/10 ] @Jon: Any more information coming? @Benjamin: Can you summarize the essence of the issue shortly? Comment by Benjamin Eberlei [ 29/Sep/10 ] @Roman: The UnitOfWork (may) still be pushed as a listener into that entity, and still recieve noticies of update. Which may throw notices because the oid hashes are removed everywhere. Additionally you cant serialize the thing because you still got the UoW inside there. Comment by Jonathan H. Wage [ 04/Oct/10 ] I don't have anymore information currently. The issue was relayed to me. I will try and find some more information and report back. Comment by Benjamin Eberlei [ 03/Apr/11 ] There is no way to "fix" this issue, i am turning it into a feature request. There needs to be a "postDetach" event that is triggered where the developer can detach the change notification objects. ### [DDC-763] Cascade merge on associated entities can insert too many rows through "Persistence by Reachability" Created: 23/Aug/10 Updated: 04/Jul/11 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: None Fix Version/s: 2.x Security Level: All  Type: Improvement Priority: Major Reporter: Dave Keen Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 2 Labels: None  Attachments: 0149-DDC-763.patch DDC763Test.php multipleaddmerge.diff  Description  I think that the UnitOfWork needs to maintain a map of spl_object_hash($newEntity)->$managedEntity for entities that were persisted via reachability during a merge. doMerge should then only call persistNew if the original entity has not already been persisted (if it has already been persisted it should merge the managed entity from the map). The map should be maintained until a flush() or until the UnitOfWork is cleared. The reasoning is as follows. Imagine we have a simple doctor object with no associations: $doctor = new Doctor(); $em->persist($doctor); $em->persist($doctor); $em->flush();  After the first persist()$doctor is MANAGED so the second persist has no effect and this results in a single Doctor row. If we do the same thing using merge and persistence by reachability: $doctor = new Doctor();$em->merge($doctor);$em->merge($doctor);$em->flush();  we get 2 Doctor rows being added. Obviously in this particular case we should use the return value from the first merge() as the parameter of the second merge which would give correct behaviour. However, now imagine one Doctor has many Patients and many Patients have one Doctor, all the associations have cascade merge enabled, and further assume that $d1 (Doctor id=1) is already in the database. We now attempt to create two patients and assign them to the existing doctor: $d1= new Doctor(); $d1->id = 1; // This is a DETACHED entity$p1 = new Patient(); $p2 = new Patient();$d1->patients->add($p1);$p1->doctor = $d1;$d1->patients->add($p2);$p2->doctor = $d1;$em->merge($p1);$em->merge($p2);$em->flush();  This actually results in 4 rows being added to the 'patients' table instead of 2, I think because $p1 and$p2 are getting persisted both as the root objects and then again from the patient->doctor->patients array. Since the cascade merging happens internally we can't replace the array contents with the managed return values without walking through the object graph (in which case there is no point in using cascade merge in the first place). Maintaining a map in UnitOfWork will allow doMerge to ensure it doesn't persist the same entities twice. I'm not sure, but this might be relevant for cascade persist too. P.S. Another bug report on this can be found at http://code.google.com/p/flextrine2/issues/detail?id=32 (it basically says the same thing with different entities).

 Comment by Benjamin Eberlei [ 29/Aug/10 ] @Roman A possible fix for this in my opinion is another map in UnitOfWork $mergedEntities = array(); and a patch like this: diff --git a/lib/Doctrine/ORM/UnitOfWork.php b/lib/Doctrine/ORM/UnitOfWork.php index 242d84b..1d0d8b3 100644 --- a/lib/Doctrine/ORM/UnitOfWork.php +++ b/lib/Doctrine/ORM/UnitOfWork.php @@ -1340,6 +1340,10 @@ class UnitOfWork implements PropertyChangedListener return; // Prevent infinite recursion } + if (isset($this->mergedEntities[$oid])) { + return$this->mergedEntities[$oid]; + } +$visited[$oid] =$entity; // mark visited $class =$this->em->getClassMetadata(get_class($entity)); @@ -1468,6 +1472,8 @@ class UnitOfWork implements PropertyChangedListener$this->cascadeMerge($entity,$managedCopy, $visited); +$this->mergedEntities[$oid] =$managedCopy; + return $managedCopy; }  Comment by Dave Keen [ 29/Aug/10 ] I have tested this patch with my application and it fixes the problem in all my relevant test cases apart from one. The test case that's failing is one that persists a bi-directional many to many relationship, so the associations interweave with each other (if you know what I mean). I wonder if perhaps doMerge need to continue cascading even if it finds an item in$this->mergedEntities This is the Flextrine code that fails - it results in no entries in movie_artist. This might also be related to DDC-758? m1 = new Movie(); m1.title = "Movie 1"; m2 = new Movie(); m2.title = "Movie 2"; a1 = new Artist(); a1.name = "Artist 1"; a2 = new Artist(); a2.name = "Artist 2"; m1.artists.addItem(a1); a1.movies.addItem(m1); m1.artists.addItem(a2); a2.movies.addItem(m1); m2.artists.addItem(a1); a1.movies.addItem(m2); m2.artists.addItem(a2); a2.movies.addItem(m2); // These translate to cascade merges on the server em.persist(m1); em.persist(m2); em.persist(a1); em.persist(a2); // Now flush em.flush(); Comment by Dave Keen [ 29/Aug/10 ] P.S. This test passes if I translate em.persist() to $em->persist() (not cascading) on the server instead of translating it to a cascade merge; not sure if that helps Comment by Roman S. Borschel [ 30/Aug/10 ] I'd really like to avoid introducing an additional instance variable just to solve this issue but I did not find the time yet to really look into it. Does someone have a unit test for this already and can attach it to the issue? Comment by Roman S. Borschel [ 31/Aug/10 ] Rescheduling for RC1. Comment by Dave Keen [ 13/Sep/10 ] Here is a functional test case containing three tests: testMultiMerge tests basic merging of two new entities, checking that only a single entity ends up in the database. This passes with Benjamin's patch. testMultiCascadeMerge tests the more complex case of merging a OneToMany association. This also passes with Benjamin's patch. testManyToManyPersistByReachability tests the ManyToMany case described above and this fails with Benjamin's patch, probably because doMerge doesn't cascade down entities that it has already merged and some ManyToMany associations are being ignored. Its a bit hard to be certain what is causing this as even without Benjamin's patch this test would fail due to DDC-758. Comment by Benjamin Eberlei [ 15/Sep/10 ] @Roman i thought about this issue, its not possible without that additional map of merged entities. There is no way we can get that information from other sources. Problem is rather that the use-case probably only applies in mass-merging scenarios and client-server serialization. Comment by Dave Keen [ 21/Sep/10 ] Added another failing test case - adding the same entity from different ends of a many to many bi-directional association to check that there isn't an integrity constraint violation caused by Doctrine trying to add the same row twice. Comment by Dave Keen [ 21/Sep/10 ] Attached a patch for this issue. Comment by Benjamin Eberlei [ 22/Sep/10 ] can you comment why all the additionall stuff is necessary compared to my patch? Comment by Dave Keen [ 22/Sep/10 ] It fixes the two additional test cases - testManyToManyPersistByReachability and testManyToManyDuplicatePersistByReachability. testManyToManyPersistByReachability was failing with your original patch because there are ManyToMany cases where an entity may have already been merged, but its still necessary to add it to an association and continue to cascade. Running the following with the original patch will miss out some of the associations. $m1 = new Movie(); $m1->title = "Movie 1";$m2 = new Movie(); $m2->title = "Movie 2";$a1 = new Artist(); $a1->name = "Artist 1";$a2 = new Artist(); $a2->name = "Artist 2";$m1->artists->add($a1);$a1->movies->add($m1);$m1->artists->add($a2);$a2->movies->add($m1);$m2->artists->add($a1);$a1->movies->add($m2);$m2->artists->add($a2);$a2->movies->add($m2);$em->merge($a1);$em->merge($a2);$em->flush();  The other change in my patch is to protect against this case. It ensures that the following code doesn't add the same entity twice to a collection. $em->merge($m1); $em->merge($m2); $em->merge($a2); $em->merge($a2); $em->flush();  Comment by Benjamin Eberlei [ 31/Oct/10 ] I am not sure if the issue here is rather multiple calls to merge that contain different parts of the same object-graph. There should be a very simple fix for this, call ->clear() after each merge. I am not sure if this patch drags us into a blackhole of issues with merging. Comment by Dave Keen [ 31/Oct/10 ] Calling ->clear() and ->flush() after each merge is a workaround for the simple case, but unless I am misunderstanding I don't think its a solution for cases where the merging is happening automatically in cascadeMerge. I've actually encountered this issue in another project and scenario to do with creating REST APIs and merging JSON objects into entities, and applying the patch fixed it so a) I think this issue might be a more common that we first thought and b) the patch basically seems to work (plus it doesn't introduce any failing cases in the existing test suite). I can actually still find one edge case to do with cascading merging interlinked many to many associations that this doesn't fix, but I was planning to open that as a new ticket after this My feeling is that the current merge already has issues and this definitely improves it. Comment by Benjamin Eberlei [ 01/Nov/10 ] It cannot happen inside a single merge, single merges use the$visited to avoid infinite recursions, each entity can only be merged once inside a single merge operation. Comment by Benjamin Eberlei [ 10/Nov/10 ] Added a note into the documentation about using EntityManager#clear between merging of entities which share subgraphs and cascade merge. Handling this issue in UnitOfwork will be declared an improvement, not a bug anymore and be scheduled for later releases. The required changes to the core are to dangerous and big. Comment by Dave Keen [ 11/Nov/10 ] Where in the docs is that? Just to summarize, the equivalent operation to having multiple merges and a single flush is to call merge followed by flush each time, with the whole thing surrounded by a transaction? Does this have a big impact on performance? Comment by Dave Keen [ 11/Nov/10 ] Ben - even given the decision not to implement this (and I do understand your thinking, as it is a major change), is there any reason not to implement the bit that ensures that the same entity isn't added to a collection twice during a merge? I can't think of a situation where this should be allowed, and I have a use case where I get 'DUPLICATE KEY' errors if this isn't there. Please see attached patch. Comment by Benjamin Eberlei [ 11/Nov/10 ] What bit of that huge patch is that? Can you extract it into another ticket if thats possible? Comment by Benjamin Eberlei [ 11/Nov/10 ] I added it to "Working with Objects" and the descripton of Merge. Its not yet live on the site. Using this current workaround has a performance impact, since more SELECT statements have to be issued against the database. Comment by Dave Keen [ 11/Nov/10 ] Apologies for not being clear - only the 3rd patch (multipleaddmerge.diff) is relevant to the 'DUPLICATE KEY' error I am now talking about, but I'll put it in a nother ticket if you prefer. Comment by Benjamin Eberlei [ 11/Nov/10 ] please add a new ticket, patch looks good. Comment by Dave Keen [ 11/Nov/10 ] Created as DDC-875

### [DDC-676] Find a way to test serialize/unserialize of all ClassMetadata properties in isolation Created: 10/Jul/10  Updated: 29/Aug/10

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

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

 Description
 We should find a way, using PHPUnit Data Providers or anything else, to check the serialize/unserialize of every property in the ClassMetadata instance, since errors here can be very subtle but dangerous.

### [DDC-667] Lock Timeout Query Hint for DQL Queries Created: 04/Jul/10  Updated: 16/Sep/10

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

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

 Description
 After the implementation of DDC-178 there is now only outstanding the support for locking queries based on a given timeout. This will be a DQL query feature only and be available via a query hint: $query->setHint(Query::LOCK_TIMEOUT,$timeoutMs);  It will be only working on Oracle.

 Comment by Roman S. Borschel [ 30/Aug/10 ] If this is to be implemented for 2.0, it needs to happen for RC1, therefore rescheduling to RC1. Feel free to reschedule to 2.x if necessary. Comment by Benjamin Eberlei [ 16/Sep/10 ] Only oracle supports lock timeouts and no other vendor seems to plan to support it. I move to 2.x, but i guess this would rather be an issue of user extension.

### [DDC-668] add upsert support Created: 04/Jul/10  Updated: 20/Dec/11

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

 Type: New Feature Priority: Major Reporter: Lukas Kahwe Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 4 Labels: None

 Description
 Didnt find anything in the docs on this. Is D2 capable of doing an UPSERT [1] in case I am trying to persist an object that may or may not have been saved previously. Different RDBMS support different syntax for this case. Like MySQL has INSERT .. ON DUPLICATE KEY UPDATE (or even INSERT IGNORE) while the SQL standard defines a MERGE syntax which seems to be gaining support. Of course you can always fallback to a SELECT FOR UPDATE (or if you want to be hacky an INSERT which catches duplicate key violations .. but probably not a good idea since many RDBMS rollback on a failure inside a transaction). See also http://opensource.atlassian.com/projects/hibernate/browse/HHH-3011 asking for MERGE support Ideally there would be a way to define on a model or model instance level if merge logic should be applied.

 Comment by Robert Burkhead [ 09/Jul/10 ] Doctrine_Record defines a replace() method. In the MySQL Doctrine implementation, however, it is not the same as INSERT .. ON DUPLICATE KEY UPDATE. The replace() method implemented in Doctrine_Connection_Mysql uses the REPLACE INTO syntax, which is a DELETE and then INSERT when the key exists. This is fine, except for tables that use auto-increment fields. The delete-then-insert operation yields a new auto-incremented value, whereas INSERT .. ON DUPLICTATE KEY UPDATE would not. Comment by Lukas Kahwe [ 09/Jul/10 ] MySQL (and SQLite) REPLACE is a no go. It causes way too much disc I/O and worse yet totally screws up the on disk data structures because of the deleting. Comment by Benjamin Eberlei [ 31/Jul/11 ] Scheduled for 2.2 Comment by Benjamin Eberlei [ 31/Jul/11 ] Evaluating this makes me sad, except MySQL support for this is rather non-existant, and the oracle merge is aiming at batch operations. Comment by Benjamin Eberlei [ 22/Oct/11 ] Should this be done with 1. Select first, then insert 2. Catch and evaluate exception then update I am leaning towards 1. Comment by Guilherme Blanco [ 20/Dec/11 ] Updating fix version

Allow @Id on @ManyToOne fields (DDC-117)

### [DDC-658] Reverse engineering with Oracle (DBDriver and Associations as Identifier) Created: 27/Jun/10  Updated: 11/Dec/11

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

 Type: Sub-task Priority: Major Reporter: Mickael Perraud Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: None Environment: Ubuntu 10.04 + Oracle 11g Entreprise + PHP 5.3.2 + Doctrine2 Git (up-to-date)

 Description
 I am playing with reverse engineering with Oracle and I have some problems: My schema: drop table PHONE_NUMBER; drop table CUSTOMER; create table CUSTOMER ( CUSTOMER_ID NUMBER(4) not null, CUSTOMER_LASTNAME VARCHAR2(50) not null, CUSTOMER_MODIFIED DATE, constraint PK_CUSTOMER primary key (CUSTOMER_ID) using index tablespace TBS_INDEX storage ( initial 100K next 100K ) ) storage ( initial 100K next 100K ) tablespace TBS_DATA; create table PHONE_NUMBER ( PHONE_NUMBER_ID NUMBER(4) not null, CUSTOMER_ID NUMBER(4) not null, PHONE_NUMBER VARCHAR2(50) not null, PHONE_NUMBERMODIFIED DATE, constraint PK_PHONE_NUMBER primary key (PHONE_NUMBER_ID, CUSTOMER_ID) using index tablespace TBS_INDEX storage ( initial 100K next 100K ) ) storage ( initial 100K next 100K ) tablespace TBS_DATA; alter table PHONE_NUMBER add constraint PHONE_NUMBER__CUSTOMER foreign key (CUSTOMER_ID) references CUSTOMER (CUSTOMER_ID);  I obtain "Fatal error: Uncaught exception 'Doctrine\ORM\Mapping\MappingException' with message 'Property "customerId" in "PhoneNumber" was already declared, but it must be declared only once'" It's because a foreign key is a component of the primary key.

 Comment by Mickael Perraud [ 28/Jun/10 ] This is the continuation of http://www.doctrine-project.org/jira/browse/DDC-616. Only the schema is different. Comment by Benjamin Eberlei [ 28/Jun/10 ] just for understanding this scenario: Is this a One-To-One relation and the TABLE_TEST2 "inherits" the primary key from its parent TABLE_TEST1? If yes, this construct is not yet supported by Doctrine 2, we still need to include an ID-Generator that supports this kind of schema. Comment by Mickael Perraud [ 28/Jun/10 ] Change for a more understandable use case. Note that it's not my real use case and that I work on legacy database on which I can't change the structure. Comment by Benjamin Eberlei [ 01/Jan/11 ] updated the issue topic to get a better grasp of what needs to be done here. Comment by waldo [ 09/Jun/11 ] I have the same error with Mysql whit the same condition. Comment by Benjamin Eberlei [ 28/Nov/11 ] More details on the work to be done: The relevant code is in Doctrine/ORM/Mapping/Driver/DatabaseDriver.php only. The idea is currently many-to-many tables are detected by checking that the table has foreign keys on all the primary key columns (no additional columns!) Now with the 2.1 feature of foreign key/primary key entities this is not necessarily true anymore. You can have the primary keys being foreign keys BUT have additional columns that are not part of the primary key. This has to be detected. If a foreign key-primary-key entity is found that has additional columns a ClassMetadata has to be created and the associations have to be created with the "id" => true flag in mapManyToOne(). Comment by Scott Steffens [ 11/Dec/11 ] For what it's worth, I'm getting this error when I have a PK that is a single column and not a FK. PRIMARY KEY (id), UNIQUE KEY cycle_station_id (cycle,station_id), KEY station_id_idx (station_id), KEY readings (readings), KEY source (source), KEY temperature_min_max (temperature_max,temperature_min), KEY station_id_cycle (station_id,cycle,updated_at), CONSTRAINT compiled_1_station_id_stations_id FOREIGN KEY (station_id) REFERENCES stations (id), CONSTRAINT compiled_1_station_id_stations_id_1 FOREIGN KEY (station_id) REFERENCES stations (id) ON DELETE CASCADE ) ENGINE=InnoDB AUTO_INCREMENT=160833690 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

### [DDC-298] Allow Entity to hold a collection of a single primitive type Created: 02/Feb/10  Updated: 20/Dec/13

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

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

 Duplicate is duplicated by DDC-2806 @ElementCollection does work as expected Resolved

 Description
 Sometimes you want to save arbitrary information for an entity using a key -> value array-structure. JPA supports this by means of the @ElementCollection annotation with allows to specify HashMaps for example. I propose a new AssocationMapping called "ElementMapping" / "ElementCollection" and annotations (options): ElementCollection + elementTable + keyType + keyLength + keyColumnDefinition + valueType + valueLength + valueColumnDefinition  The key and value definitions are necessary for converting and schema generation. The implementation would make use of the PersistentCollection at all times and work as any other persistent collection just with primitive types. Restrictions for a first implementation: Only available as a Lazy-Load Collection, no hydration with the source entity Can't be used in queries alike "entity.colname.key = ?1" Use-Case: $entity->options['foo'] = 'bar';$entity->options['bar'] = 'baz';  This could be done for 2.0 imho, adding the necessary changes and optimizations could then be scheduled for 2.1

 Comment by Benjamin Eberlei [ 02/Feb/10 ] In this implementation Schema-Tool would generate a table: elementTable (entity_id-1, ..., entity_id-n, key, value) and using the Platform Type Generation of keyType and valueType Comment by Benjamin Eberlei [ 02/Feb/10 ] Column Names should be Change-able also since there could be people who name their primary keys "key" and "value" o_O Comment by Benjamin Eberlei [ 02/Feb/10 ] Ordering could be implemented on top of this using the @OrderColumn JPA implementation by adding another column to the table with a numeric order that will be "order by"'d on select time. Comment by Benjamin Eberlei [ 24/Dec/10 ] Pushed back Comment by Richard Michael Coo [ 10/Oct/13 ] Any news on this? It has been almost 3 years since its last update =)

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

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

 Reference is referenced by DDC-546 New fetch mode EXTRA_LAZY for collect... Resolved

 Description
 A problem when working with collection-valued associations is that almost all operations except add($obj) require the collection to become initialized in order for the operation to be performed properly. While this is all correct and beautiful OO-wise it may be problematic at times with regards to performance. Hence we might want to consider to provide some convenient methods along the lines of link/unlink (name suggestions?) which allow more direct, less OO collection manipulation. Such methods obviously would bypass the normal object lifecycle and the changes done through these methods will not be reflected in the in-memory objects and collections, unless the user keeps them in-synch himself.  Comments  Comment by Benjamin Eberlei [ 11/Dec/09 ] Questions I suppose link and unlinked entities would then handled by UnitOfwork commit also? Since the collection is not initialized, one does not know upfront if the action will be successful, what happens if: an entity is linked with a collection, although they are already connected. an entity is unlinked from a collection it is not in. Regarding the naming, i like link/unlink. Comment by Roman S. Borschel [ 17/Dec/09 ] What do you mean by "handled by UnitOfWork commit" ? Whether the SQL is "scheduled" or executed immediately? Interesting question. Scheduling would probably be better but also more difficult. As far as usage is concerned, I currently imagine it as follows: // EntityManager#link($sourceObj, $field,$targetObj) $user =$em->getReference($userId); //$userId probably from request parameters $address =$em->getReference($addressId); //$addressId probably from request parameters $em->link($user, 'addresses', $address);  "What happens if: an entity is linked with a collection, although they are already connected." Probably an SQL error which results in an exception from the driver. Depends on the database constraints though. "What happens if: an entity is unlinked from a collection it is not in" Probably nothing, at least not from the SQL side. An exception could be thrown from Doctrine itself if the update affected 0 rows. Thanks for these initial questions. Thats definitely food for thought. Keep it coming. Comment by Roman S. Borschel [ 26/Aug/10 ] Pushed back. ### [DDC-1200] Derived Id Generator Created: 09/Jun/11 Updated: 09/Nov/11 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: Git Master Fix Version/s: 2.x Security Level: All  Type: Improvement Priority: Major Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 5 Labels: None Issue Links:  Duplicate is duplicated by DDC-1315 ORM\Id\AssignedGenerator doesn't work... Resolved  Description  For usage with the foreign key as primary key features described in DDC-117 a derived id generator would be tons of useful. It is essentially a post generate id generator (sort of late pre insert though) assigned generator.  Comments  Comment by Daniel Lima [ 09/Nov/11 ] When this will be fixed? I think this is related to http://groups.google.com/group/doctrine-user/browse_thread/thread/7e1cfa9c4c99af31 ### [DDC-585] Create a coding standards document Created: 13/May/10 Updated: 17/Apr/14 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: None Fix Version/s: 2.x Security Level: All  Type: Documentation Priority: Major Reporter: Roman S. Borschel Assignee: Jonathan H. Wage Resolution: Unresolved Votes: 0 Labels: None  Description  We need a new coding standards document for Doctrine 2.  Comments  Comment by Benjamin Morel [ 29/Jan/13 ] Has there been any work on a coding standards document yet? I'm currently working on fixing documentation on this project, and it might be a good time to define a standard. I've started compiling a few recommendations based on various feedbacks I've got in my pull requests, and I can post them here. Please let me know if there have been previous attempts so far! Comment by Marco Pivetta [ 29/Jan/13 ] Benjamin Morel Guilherme Blanco may have a CS ruleset, but it's not ready yet. Perfect timing btw, we really need to automate this to avoid having all these useless CS fix comments in pull requests Comment by Benjamin Morel [ 29/Jan/13 ] Ok, I'll post my document here once ready, and Guilherme Blanco will be able to compare it with his ruleset! Comment by Benjamin Morel [ 30/Jan/13 ] Here is a first draft: https://gist.github.com/4676670 Please comment! Comment by Benjamin Morel [ 11/Feb/13 ] Guilherme Blanco, if you don't have time to compare your ruleset with my draft, maybe you could publish your current ruleset so that others can have a look? Comment by Benjamin Morel [ 02/Aug/13 ] Any update guys? I'm willing to spend some time on this work, but if no one answers, we won't be going forward Comment by Marco Pivetta [ 02/Aug/13 ] Benjamin Morel I think a pull request against the doctrine website (https://github.com/doctrine/doctrine-website-sphinx) would be fine... Comment by Steve Müller [ 17/Apr/14 ] This should go into https://github.com/doctrine/coding-standard repo (long term). ### [DDC-624] Partial object query that leaves out an association to avoid loading it fetches the association anyway. Created: 03/Jun/10 Updated: 14/Oct/14 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: 2.0-BETA1 Fix Version/s: 2.x Security Level: All  Type: Bug Priority: Major Reporter: Roman S. Borschel Assignee: Guilherme Blanco Resolution: Unresolved Votes: 2 Labels: None Issue Links:  Duplicate is duplicated by DDC-1465 Fetching partial objects doesn't work... Open  Description  Assuming: Customer Cart where Cart is the owning side. Since the association from Customer to Cart can not be lazy, it would make sense to leave out the association in a query to avoid loading the carts like this: select partial c.{id,name, ... anything except cart} from Customer c"  But this is ignored and the carts of all customers are fetched anyway. Query::HINT_FORCE_PARTIAL_LOAD is an alternative solution, however it has the disadvantage that it disables lazy-loading for all queried objects. If partial querying would honor associations this would allow more fine-grained control.  Comments  Comment by Roman S. Borschel [ 26/Aug/10 ] Might need to be pushed back to a 2.0.x / 2.x.x bugfix release. Not clear yet. ### [DDC-1543] Support for Mapping Files on Traits Created: 17/Dec/11 Updated: 17/Dec/11 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: None Fix Version/s: 2.x Security Level: All  Type: New Feature Priority: Major Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  With PHP 5.4 and traits coming we should find a way where you can add xml and yml configurations for a trait and upon loading an entity X, it also loads the trait configuration of this entity. ### [DDC-1852] Doctrine\ORM\Tools\SchemaValidator should check validity of lifecycle callbacks Created: 04/Jun/12 Updated: 17/Jan/15 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: Git Master Fix Version/s: 2.x Security Level: All  Type: Improvement Priority: Major Reporter: Marco Pivetta Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  The schema validator should analyze mapped lifecycle callbacks and: a) if some lifecycle callbacks were defined, but no @HasLifecycleCallbacks annotation/mapping was set, warn the user b) if some lifecycle callbacks were defined, but methods are not public, warn the user  Comments  Comment by Marco Pivetta [ 04/Jun/12 ] Existing PR at https://github.com/doctrine/doctrine2/pull/361 ### [DDC-1373] Map file with specific class Created: 13/Sep/11 Updated: 14/Feb/12 Status: Open Project: Doctrine 2 - ORM Component/s: Mapping Drivers Affects Version/s: 2.1.1 Fix Version/s: 2.x Security Level: All  Type: Improvement Priority: Minor Reporter: Thomas Tourlourat - Armetiz Assignee: Fabio B. Silva Resolution: Unresolved Votes: 0 Labels: None Environment: Debian LAMP - PHP5.3 - Apache 2  Description  Hi there, AbsractFileDriver is using the filename to know the managed class. It's a cool feature because it's allow loading on-demand. The problem is, that the filename must be the name of the Class. It should be great to be able to manually map XML/YAML File description to a Class, like :$drivers->addMappingFile ( array ( "filename" => "class", "filename2" => "class2") ); This feature is simple to implement, just add a new array inside AbsractFileDriver to know the mapping. When using the current method with addPaths, parse the folder to get traditional XML/YAML file where filename corresponding to classname and add it to the mapping array. AbsractFileDriver->getAllClassNames () just return value of mapping array. The mapping array is store inside cache. With this new feature, it allow developers to create a pretty folder that contains entities mapping. Armetiz.

 Comment by Guilherme Blanco [ 20/Dec/11 ] Updating fix version

### [DDC-1370] preInsert, postInsert, prePersist, postPersist, preUpdate, postUpdate code and documentation of events Created: 09/Sep/11  Updated: 26/Feb/14

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

 Type: Improvement Priority: Minor Reporter: Guilherme Blanco Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: None

 Description
 Currently we have a set of Lifecycle events, but they seem to be misleading both in actual implementation and documentation. One good example is prePersist and postPersist, which is only fired when you're creating new entities. It should be renamed to preInsert and postInsert. As of preUpdate and postUpdate, they seem quite valid. But if we rename prePersist and postPersist to (pre|post)Insert, we may have a situation where you wanna cover both insert and update. For this, (pre|post)Persist should be reinstated, but acting differently from what it does currently.

 Comment by Rafael Dohms [ 09/Sep/11 ] Also, documentation for post* methods is broken at the website: "Changes in here are not relevant to the persistence in the database, but you can use this events to" It cuts off in mid-sentence. Comment by Guilherme Blanco [ 09/Dec/11 ] RDohms, this paragraph was already sorted out. The actual ticket is still valid here. Comment by Guilherme Blanco [ 20/Dec/11 ] Updating fix version Comment by Matt McNeill [ 26/Feb/14 ] Commenting here to say that this caused a lot of headaches for our project until we got it sorted out what these events really do. The problem is that the term 'persist' is ambiguous - it means both persist and update in the context of the persist() function call, but only means INSERT in the context of the event system.

### [DDC-838] SchemaTool - ignores the attribute uniq in relations Created: 13/Oct/10  Updated: 29/Oct/10

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

 Type: Improvement Priority: Minor Reporter: gektor Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None Environment: Ubuntu, PHP 5.3.2, MySQL

 Description
 Mapper   SQL CREATE TABLE test (id INT AUTO_INCREMENT NOT NULL, users_id INT DEFAULT NULL, blabla TINYINT(1) NOT NULL, UNIQUE INDEX test_users_id_uniq (users_id), PRIMARY KEY(id)) ENGINE = InnoDB; ALTER TABLE test ADD FOREIGN KEY (users_id) REFERENCES users(id) ON UPDATE CASCADE ON DELETE CASCADE;  Actual: UNIQUE INDEX test_users_id_uniq (users_id) Expected: INDEX test_users_id (users_id)

 Comment by Benjamin Eberlei [ 14/Oct/10 ] Verified, i just don't understand why you are using a one-to-one relation and then "deactivate" the database constraint for this. You could easily use Many-To-One Comment by gektor [ 14/Oct/10 ] You are right. It's not a bug, it's feature. Comment by Benjamin Eberlei [ 29/Oct/10 ] This might still be a good improvement to allow the flexibility, but its not a bug. Updating to "Minor Improvmenet for 2.x"

### [DDC-691] doctrine.readOnly query hint Created: 15/Jul/10  Updated: 31/May/12

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

 Type: Sub-task Priority: Minor Reporter: Roman S. Borschel Assignee: Roman S. Borschel Resolution: Unresolved Votes: 6 Labels: None

 Description
 Setting such a query hint to TRUE should result in all entities being retrieved by that query to be read-only for the purposes of change-tracking. Note that the entities themselves need not necessarily be read-only in general. This feature is a flush performance tweak that can be used to query for objects but not let the returned objects run through change-tracking on flush. Any other managed objects are tracked as usual so you can do a read-only query for 100 entities and persist a new entity in the same unit of work with optimal flushing performance.

 Comment by Konstantin [ 26/Dec/11 ] Any news? Why query hint? What about temporary switching like fetch mode changing via query object? Comment by Gigi Largeanus [ 31/May/12 ] Any news on this? I think this is a must have feature. Thanks for all your work.

### [DDC-445] Evaluate possible ways in which stored procedures can be used Created: 19/Mar/10  Updated: 24/Dec/10

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

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

 Reference relates to DDC-391 Allow to specifiy custom Entity and C... In Progress

 Description
 We should evaluate the current situation of stored procedure support as well as where we want to go with it / how far we want to support it, if at all.

 Comment by Benjamin Eberlei [ 19/Mar/10 ] I think this relates to the usage of Custom Persisters

### [DDC-17] Ability to skip the operation from a pre-operation event handler Created: 20/Sep/09  Updated: 26/Aug/10

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

 Type: New Feature Priority: Minor Reporter: Ismo Toijala Assignee: Roman S. Borschel Resolution: Unresolved Votes: 0 Labels: None

 Description
 In Doctrine 1.1 it is possible to skip the operation in the event handlers in Doctrine_Record_Listener using Doctrine_Event::skipOperation. This no longer seems to be possible in Doctrine 2.0 Alpha 1, for example when handling a preRemove event to implement soft-delete behaviour. Perhaps a method could be added to \Doctrine\Common\EventArgs\LifecycleEventArgs to skip the operation, at least before the operation. Without this implementing soft-delete would require the user to update deleted_at and deleted_by himself and then save the record. It could no longer be done automatically when removing a record because the record is then removed.

 Comment by Roman S. Borschel [ 20/Sep/09 ] The problem is, full support for soft-delete throughout the system is not feasible and very fragile. Simple soft-delete through skipping the delete operation is the easiest part. Then you will probably want to modify all DQL queries so that they adhere to it automatically and then there will always be still queries that do NOT go through DQL, like even internal lazy-load queries or native queries or others, which would need to be modified also. To sum it up, implementing soft-delete "inside" doctrine is absolutely not worth the effort and imho a bad idea and I'm certainly not willing to make lots of adjustments to the core that have a negative impact on performance just to make this soft-delete possible. I really recommend handling "soft" deletes yourself, the normal way, by simply abstracting entity retrieval and persistence through a DAO/repository layer. As a nice side-effect you get less magic and it still works when you swap out doctrine for another persistence provider. I am willing to add support for skipping deletes and maybe some other operations through events but I'm not willing to go any further, as explained above.

### [DDC-4] Implement support for Concrete Table Inheritance Created: 09/Sep/09  Updated: 24/Dec/10

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

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

 Description
 A first implementation could probably live without support for polymorphic queries (requires SQL UNIONs to be generated).

### [DDC-391] Allow to specifiy custom Entity and Collection Persister classes Created: 06/Mar/10  Updated: 08/Sep/13

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

 Type: New Feature Priority: Minor Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 9 Labels: None

 Reference is referenced by DDC-2637 [GH-769] Add Custom Persisters Open is referenced by DDC-445 Evaluate possible ways in which store... Open is referenced by DDC-699 ProxyFactory: allow to overwrite $_pr... Resolved  Description  It should be allowed to overwrite the default persisters for collections and entities. This should go along the lines of Hibernate which allows to set the custom implementations like: XML:   Annotation /** * @Entity(persister="persisterClass") * @OneToMany(persister="persisterClass") */   Comments  Comment by Roman S. Borschel [ 19/May/10 ] Rescheduling for beta3. Comment by Roman S. Borschel [ 07/Jul/10 ] Pushing back to beta4. Comment by Roman S. Borschel [ 12/Jul/10 ] Moved to 2.1 due to lack of time for any larger new features for 2.0. Comment by Benjamin Eberlei [ 13/Oct/10 ] implemented this in a feature branch for now, it really doesnt touch any other runtime code so maybe we can still merge this before RC1 http://github.com/doctrine/doctrine2/tree/OverridePersisters Comment by Gediminas Morkevicius [ 25/Feb/11 ] Is this forgotten? you should merge it since it does not affect any other parts of ORM, this is a great feature Comment by Benjamin Eberlei [ 26/Feb/11 ] This has not been forgotten, but the Persister is due for a heavy refactoring for 2.2 probably, when we will make it use the SQL Query object that we are working on. So I cannot merge this, because the API will probably break big time. Comment by Jonas Wouters [ 16/Mar/11 ] Does that mean we will not see this feature before 2.2? Comment by Benjamin Eberlei [ 16/Mar/11 ] Yes, that is correct. I dont want to add it as experimental/undocumented feature because people will take it for granted and make us responsible for possible bc breaks. I will update the target version accordingly. Sorry for disappointing you, but this feature is fundamentally important at the core of the library. That means we have to get it right and not rush into it. Comment by Gediminas Morkevicius [ 17/Mar/11 ] Just as I thought that first you will want to make a query builder object for all persisters. since now they use plain sql. Thanks for all your work on this Comment by Adam Brodziak [ 11/Jan/12 ] I might be mistaken, but AFAICS mentioned Persister heavy refactoring did not made through to 2.2 version. Is there any plan to have it in 2.3 or at any later stage? Comment by Guilherme Blanco [ 13/Jan/12 ] @Adam I refactored all Persisters optimizing their code, but I could not complete the move from SQL string generation to Doctrine\DBAL\Query. We missed it, yes. I may reschedule for 2.3 Comment by Thomas Rothe [ 05/Sep/12 ] Why is it still missing in 2.3? I would require this for an extension that uses its own overridden entity persister and using a custom persister is the solution that you guys recomend for not overriding the entity manager. Comment by sebastiaan stok [ 23/Sep/12 ] Any change seeing this soon? I really need this for a security feature. What is making this so hard? just adding an setEntityPersister($entityName, $object) should do the trick. I don't need any fancy stuff, just a way to limit the fields in the SELECT list. Edit: OK, I'm shot I CAN NOT overwrite the entity manager as the UnitOfWork is private! Got any other idea? Comment by Stefan Kögel [ 24/Sep/12 ] Any chance you could add this quickly? I need this feature urgently to complete an extension using a custom persister. Thanks in advance. Comment by Lennart Weijl [ 09/Jul/13 ] What's the status on this issue? ### [DDC-2570] Doctrine CLI Tools - Clear All Cache Created: 24/Jul/13 Updated: 17/Jan/15 Status: Open Project: Doctrine 2 - ORM Component/s: ORM, Tools Affects Version/s: 2.3.4 Fix Version/s: 2.x  Type: Improvement Priority: Minor Reporter: Frederick Marcoux Assignee: Marco Pivetta Resolution: Unresolved Votes: 0 Labels: Cli, cache, orm  Description  It would be nice to be able to clear all cache one shot instead of clearing them one after one... Like this: root$ ./doctrine orm:clear-cache:all Instead of: root$./doctrine orm:clear-cache:metadata root$ ./doctrine orm:clear-cache:result root$./doctrine orm:clear-cache:query ### [DDC-3212] Remove ArrayHydrator logic Created: 14/Jul/14 Updated: 13/Oct/14 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.5 Fix Version/s: 3.0 Security Level: All  Type: Improvement Priority: Critical Reporter: Marco Pivetta Assignee: Marco Pivetta Resolution: Unresolved Votes: 0 Labels: hydration, hydrator  Description  The Doctrine\ORM\Internal\Hydration\ArrayHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php ) is currently very messy and complicated due to the lack of actual Doctrine\ORM\UnitOfWork references when working with it, since we are not dealing with objects. In order to reduce the amount of bugs and code duplication when working with array hydration, I would simply suggest making use of the Doctrine\ORM\Internal\Hydration\ObjectHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php ) and its siblings, and then extracting data coming from the results in it as an array. This could be a simple reflection-based extraction (pseudo): class ArrayHydrator { public function hydrateAllData() { foreach ($this->objectHydrator->hydrateAllData() as $object) { yield$this->extractData($object); } } }  The point here is that array-based hydration is not the primary focus of the ORM, and users should probably rely on SQL only when they want array hydration.  Comments  Comment by Marco Pivetta [ 14/Jul/14 ] Note: performance is one of our biggest requirements, and array hydration is meant to achieve that. As I stated above, plain SQL is probably better for this sort of operation, so the issue is more about deprecating the ArrayHydrator completely, providing utilities to manipulate SQL resultsets instead. ### [DDC-3512] Redesign ClassMetadata API as ValueObject based (for type-safety and self-documentation) Created: 17/Jan/15 Updated: 18/Jan/15 Status: Open Project: Doctrine 2 - ORM Component/s: Mapping Drivers, ORM Affects Version/s: None Fix Version/s: 3.0 Security Level: All  Type: Improvement Priority: Critical Reporter: Marco Pivetta Assignee: Marco Pivetta Resolution: Unresolved Votes: 0 Labels: classmetadatafactory, cleanup, metadata, performance, type-safety Issue Links:  Reference relates to DDC-3503 [GH-1257] Resolve target entity also ... Resolved  Description  The current ClassMetadata API is based on a lot of array juggling (for performance reasons). While that was understandable with PHP 5.3, all the array access operations are currently: slowing things down making the code very hard to read/understand I suggest re-coding the ClassMetadata internals (public properties and such) so that well-described properties are defined. Additionally, as a bonus, we'd get a performance boost by just moving all the class-alias and type resolution logic from the runtime into the ClassMetadataFactory (or similar) API, saving tons of performance at every run. In pseudo-logic, what I'd like to achieve with DDC-3512 is: base metadata is loaded from the mapping driver onLoadMetadata event is fired for each loaded metadata instance metadata is completed by the ClassMetadataFactory logic onCompleteMetadata event is fired for each loaded metadata instance This would make metadata manipulation from events a bit messier (user needs to know which value to change during which event), but would allow using better constrained metadata structures in future, and that would disallow mistakes during event listeners execution as well (internal validation). ### [DDC-536] Remove the _ prefix from private and protected members Created: 23/Apr/10 Updated: 16/Apr/14 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: None Fix Version/s: 3.0 Security Level: All  Type: Improvement Priority: Major Reporter: Roman S. Borschel Assignee: Guilherme Blanco Resolution: Unresolved Votes: 1 Labels: None  Description  The reasoning is simple: The prefix "_" is usually either used for easier distinction of instance variables from other, i.e. local variables, instead of always using "this." (often seen in C#), or it is used to signal that a member is not meant to be accessed from outside of the class when the language does not have visibility modifiers (PHP4). Since you always have to use "$this->" in PHP5+ when accessing instance members and there are visibility modifiers, the "_" is largely superfluous and just makes the verbose OO code even more verbose. Maybe the following find/replace steps will do the job almost completely: "private $_" => "private$" "protected $_" => "protected$" "$this->_" => "$this->" 

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

### [DDC-3183] Add JsonSerializable to Collections Created: 22/Jun/14  Updated: 22/Jun/14

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

 Type: New Feature Priority: Major Reporter: Gabriel Bull Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: collection, orm

 Description
 Implement this: http://www.php.net/manual/fr/class.jsonserializable.php Can't really make this claim if Doctrine is not implementing basic interfaces for collections: > The missing (SPL) Collection/Array/OrderedMap interface.

### [DDC-274] Class and namespace naming inconsistency Created: 24/Jan/10  Updated: 26/Jun/14

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

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

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

### [DDC-2133] Issue with Query::iterate and query mixed results Created: 09/Nov/12  Updated: 01/May/13

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

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

 Duplicate is duplicated by DDC-1314 DQL permits partial select using SQL Resolved

 Description
 Consider this code: $dql = " SELECT Page, Product.name FROM Dlayer\\Entity\\Page Page INNER JOIN Page.Product Product ";$q = ($em->createQuery($dql)); foreach ($q->iterate() as$entry) { $page =$entry[0][0]; $name =$entry[0]['name']; }  This results with undefined index: 'name' for the second entry. First result keys are (notice just one array element with index 0): 0 array(2) { [0] => int(0) [1] => string(4) "name" }  but all others are different (notice two array elements with index 0 and the other one that is incrementing): the second one: 0 array(1) { [0] => int(0) } 1 array(1) { [0] => string(4) "name" } the third one: 0 array(1) { [0] => int(0) } 2 array(1) { [0] => string(4) "name" }  What's wrong with this approach? Is it a bug or mixed results should not be used with the iterate method?

 Comment by Benjamin Eberlei [ 12/Nov/12 ] This is a known issue that we don't have found a BC fix for and as I understand Guilherme Blanco requires considerable refactoring.

### [DDC-2089] Modify OneToMany to allow unidirectional associations without the need of a JoinTable Created: 19/Oct/12  Updated: 13/Oct/14

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

 Type: Improvement Priority: Major Reporter: Enea Bette Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: onetomany, persister, unidirectional Environment: Debian Wheezy, Mysql 5.1, Apache2, PHP 5.4

 Description
 As I sayd in the title, it would be nice if the ORM layer could permit to map a 1:n association in the db as an unidirectional OneToMany in the classes, without using a JoinTable in the database. This would permit us to get rid of the unnecessary database JoinTable, which creates disorder and decreases performance for no valuable reason. Is it possible?

 Comment by Enea Bette [ 16/Dec/12 ] A little up... for inspiration from JPA http://en.wikibooks.org/wiki/Java_Persistence/OneToMany#Undirectional_OneToMany.2C_No_Inverse_ManyToOne.2C_No_Join_Table_.28JPA_2.0_ONLY.29 Comment by Daniel Pitts [ 07/Oct/14 ] This is also a big issue for Symfony2 forms. It's very difficult to make a form type for a collection of "things", where the "things" are fully owned by the parent object.

### [DDC-213] Persist order of collections Created: 15/Dec/09  Updated: 27/Jun/14

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

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

 Duplicate is duplicated by DDC-181 Order of many-to-many relationship Resolved Reference is referenced by DDC-250 ArrayCollection Key Column @indexBy Resolved

 Description
 A Collection is like a php array, an ordered map. Hence there should be the possibility to persist this order.

 Comment by Christian Heinrich [ 21/May/10 ] Roman, I'd like to do this one as I have currently a use case for this. Do you have any idea of how to do this? What I'm wondering is whether it is possible to implement this without user intervention. (This would simply mean "store the entities as they were added"). But this would need another column in DB that we'd have to add within oneToMany / manyToMany relationships, but in this case one could save a serialized array holding "entityId => position" key / value pairs. Afterwards, one could easily rebuild / reorder the collection via $collection->set($entity, $order[$entity->identifier]); If you've got another thought about this, please don't hesitate to point me into the right direction! Comment by Benjamin Eberlei [ 22/May/10 ] this won't be implemented until 2.1, since its a pretty complex feature. Changes are probably required in: 1. CollectionPersister - Add a new collection persister that takes the position into account 2. SchemaTool - Add a 'col_position' column to either the many-to-many or the one-to-many tables. 3. EntityPersister - Use and extend current order-by support to make the sorting happen You can implement this already though with some performance hit in update scenarios. If you use the ORDER BY support and implement an API around your entity that abstracts those changes and always sets a "position" field on the many entity that is supposed to be sorted. Comment by Roman S. Borschel [ 22/May/10 ] I don't think we necessarily need a new collection persister. Simply adjusting the ManyToManyPersister to be able to deal with it might be sufficient. For OneToMany, that is always persisted from the "many" side, thus there is no collection persister, we would need to adjust the normal persisters. They key element for the user should be a new annotation (or corresponding xml/yaml element) @OrderColumn. By default the order should not be persistent, only when an @OrderColumn annotation is present. The name of the order column can have a default, i.e. "position". Thus this enhancement of persisting the order should be fully backwards compatible. Comment by Roman S. Borschel [ 22/May/10 ] On another note, the getInsertDiff/getDeleteDiff methods of PersistentCollection should already be "ready" for this. That is, when an element in the collection changed only its position, this is already tracked as a change. However the ManyToManyPersister issues no "UPDATE" queries, it simply deletes and inserts. A position change may be more effectively persisted with an UPDATE. Comment by Benjamin Eberlei [ 30/Sep/10 ] From a mailinglist entry, required check/changepoints: 1. ClassMetadata of Many-To-Many associations have to be extended to publish the required datastructure to the ORM. 2. All Metadata Mapping Drivers have to be extended 3. Persisters\ManyToManyCollectionPersister has to be extended to save the key in the many to many table if desired by the user. 4. Schema-Tool has to be extended to create the additional column. 5. PersistentCollection has to be extended so that lazy loading of collections with additional key works. 6. Array- and ObjectHydrator have to be extended to allow fetch join of collections with key column. 7. Discuss wheather to support this for One-To-Many also with the key-column on the many side. This is much more tricky internally though. Comment by Benjamin Eberlei [ 24/Dec/10 ] Push back to 2.x, we will have support for DDC-250 first and for this at a later release. Comment by Thomas Tourlourat - Armetiz [ 07/Feb/12 ] Hi there, I'm looking for this feature. Benjamin Eberlei said that : "You can implement this already", but I don't understand the "how to". Also, The problem should be solve if RDBMS had a "natural" order. An order based on item position inside table. To get this feature without any change on Doctrine, I have remplace the PK defined by the target & mapped field identifier. The new PK is a new field with type "integer" and with auto-increment enable. In this configuration, Doctrine use the "natural" order of the RDBMS. And I can change order of my item inside Collection and persist it. It's an very bad solution, but It work before an official support. Waiting for advices, and solutions, Thomas. Comment by Thomas Tourlourat - Armetiz [ 08/Feb/12 ] Answering to Benjamin Eberlei on the "7. Discuss wheather to support this for One-To-Many also with the key-column on the many side. This is much more tricky internally though.". I think that for One-To-Many relations, if user want to store the collection order, Doctrine can store the One-To-Many as Many-To-Many with a "model" limitation. In that case, if storing order collection for Many-To-Many work, it should work for One-To-Many. What do you think about it ? Comment by Nicolas [ 29/Feb/12 ] I think that it must be possible to have two keys ordering : the order isn't obligatory reversible. For exemple with user and group : You can order groups for one user : with preference by exemple, or importance. And with a different order, users for a group : rank by example. And maybe more, if you decide to add multi-order : an user show group by his rank in it, if his rank is identical, the order is make by love preference, and after by the importance given by the user (not necessary a number, if we imagine filter on them). So a default order can be choice with parametized fields and could be :  @ManyToMany(targetEntity="Group") ... @JoinFields ( rank: { type: int} , preference:{type:int}, importance:{type: string, length: 40} ) @OrderByJoinFields({"rank" = "ASC", "preference"="ASC", "importance"="ASC" } )  In this case the order must be optional and would be clean if another order appears in the same scope (DQL...). And manytomany became virtual entities act as other entities except they don't appears permetting in the same time a better conception. So if the solution take in DDC-181 will become the only solution. This would a good idea to document this. Because, this seems to me a very important point. My last point is even an unique ordering field created in the join table will be a big and usefull improvement. Thank a lot for your beautiful work. Comment by Thomas Tourlourat - Armetiz [ 29/Feb/12 ] In my point of view, a collection can be order in a single way only. If you want to add more than one order between User & Group, it's a new collection, a new relation. Like : User.memberOf() : Group[] Group.members() : User[] Group.importantMembers() : User[] And it's your role to keep a consistency between members & importantMembers array. Because ManyToMany join table is the reflection of a state of an ArrayCollection. It's not a usefull feature to be able to store all of the state of an ArrayCollection, even the order of this Array. It's just a normal feature that is really missing Thomas. Comment by Nicolas [ 29/Feb/12 ] I don't think: If you have three collection, you duplicate one relation 3 times and it's easy in consequence to lost the data integrity and unicity. By example : Thomas have rank 10 in Admin Thomas think the admin group has importance noted 3 on all of his groups. If a responsable of admin group decide to delete Thomas from it. Thomas, in his ordered list of groups, think always to be in group admin. So in my idea, the many to many relation isn't just an array collection, but should be an virtual entity. In UML or in Merise method this is a common problem to have a parametized relation. I think an orm should just implement this. Comment by Thomas Tourlourat - Armetiz [ 29/Feb/12 ] Hum, I agree with you.. In a SQL Schema, it's a good choice to add many fields in a ManyToMany join table to description "order". Comment by Thomas Tourlourat - Armetiz [ 07/Mar/12 ] I just want to add a piece of Doctrine ORM Document : "When working with collections, keep in mind that a Collection is essentially an ordered map (just like a PHP array). That is why the remove operation accepts an index/key. removeElement is a separate method that has O ( n) complexity using array_search, where n is the size of the map." Comment by Thomas Tourlourat - Armetiz [ 23/Mar/12 ] Hi there, After several discussions. on IRC, I have changed my point of view. Doctrine Documentation says : "When working with collections, keep in mind that a Collection is essentially an ordered map (just like a PHP array)". So, I think that Doctrine have to be able to store or not the order of a Collection. By adding a new field on the Joined table to store the position of each elements. But I not agree with @Nicolas. Because in his case, he's talking about Association Class : http://etutorials.org/Programming/UML/Chapter+6.+Class+Diagrams+Advanced+Concepts/Association+Class/ Because he's talking of a business logic, he's talking of a dedicated Entity class. What do you think about it ? Thomas; Comment by Thomas Tourlourat - Armetiz [ 31/Aug/12 ] Any news ? Comment by Matthieu Napoli [ 16/Oct/12 ] Hi, any news on this? If I may add any info to this feature request, maybe something like JPA/Hibernate could be a good start? The idea in Hibernate is that you persist the order of the list in an extra column. This column is not a field of the entity however. Comment by Albert Casademont [ 27/Jun/14 ] +1, this would be indeed a very nice thing. We are using the @OrderBy annotation as a workaround but it's not quite the same thing Comment by Marco Pivetta [ 27/Jun/14 ] Moved to 3.x

### [DDC-2390] Remove Parser and SQLWalker dependency on Query Created: 04/Apr/13  Updated: 17/Jan/15

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

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

 Description
 Query is too powerful to be available in Parser and SQLWalker, because it may lead to accessing data that changes on subsequent runs of a query that is cached. Idea is to introduce a MetadataBag that contains only the values that are allowed to be accessed.

### [DDC-1599] OnFlush event in transaction Created: 14/Jan/12  Updated: 17/Jan/15

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

 Type: Improvement Priority: Major Reporter: Gediminas Morkevicius Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 3 Labels: None

 Description
 Is there any particular reason why onFlush event is not triggered when the transaction is allready open? https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/UnitOfWork.php#L290 It would help a lot developing listeners since this event is the mostly used one and since theres preFlush now it seems a logical solution if onFlush would be a start of transaction in general

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

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

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

Attachments: ArrayHydrator.php     Array_Hydrator_4.2.php     Array_hydrator_4.2_bugfix.php
 Dependency depends on DDC-2955 [GH-933] [WIP] DDC-2953 Resolved

 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.

### [DDC-3083] Persist/Flush silently fails when CTI is applied on an existing table Created: 12/Apr/14  Updated: 13/Apr/14

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

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

 Description
 Given an existing table (= parent table) the integration of a new parent-child relationship with Class Table Inheritance (CTI) leads to a update problem. First of all a child table is created with a foreign key to the parent table. Next, the discriminator column is added to the parent table. The discriminator map will be auto-generated. The problem arises when trying to perform persist() and flush() on a child entity. Initially the child table is logically empty. However, the UnitOfWork triggers updateTable() which will fail since there is nothing to update. Instead, an upsert should be performed. Another sneaky thing is that the repository will return the child class with the updated data after calling flush() on the same request. On the next request the child class is returned with the data loaded from the persister. Of course, the updated data is missing.

 Comment by Marco Pivetta [ 13/Apr/14 ] Frank Liepert do I understand this correctly if I say that you are trying to (pseudo) upcast an entity to a more specific subtype? That is unsupported by the ORM. Could you make just an example snippet of what you described in the issue? Comment by Frank Liepert [ 13/Apr/14 ] Marco Pivetta: You have understood really well. If you say that's not supported by the ORM then this is the answer. Still I think that upsert could solve solve the "problem" and I know that there are/have been discussions about upsert. Right now I will continue to manually insert the missing rows in the child table. After this necessary step the ORM works as expected. Nevertheless the real bug is that after persist() and flush() the entity manager returns the child object with the "persisted" data of the child table although there are in fact no rows in the child table. $parentRepository =$em->getRepository('Parent'); $child =$parentRepository ->find(1); $child->setChildPropertyA('foo');$em->persist($child);$em->flush(); $child =$parentRepository ->find(1); var_dump($child->getChildPropertyA()); // string(3) "foo" // But: There is no 'foo' in the child table! /** * NEW REQUEST */$parentRepository = $em->getRepository('Parent');$child = $parentRepository ->find(1); var_dump($child->getChildPropertyA()); // NULL  Comment by Marco Pivetta [ 13/Apr/14 ] Frank Liepert why are $child in the first request and$child in the second request different here? Are you manually changing the data at SQL level? Comment by Frank Liepert [ 13/Apr/14 ] Marco Pivetta as I have explained the persist() and flush() in the first request trigger an UPDATE command (Because there is already a row in the parent table?). Given that the child table was manually created before there are no rows on that table at that time and therefore nothing can be updated. Nevertheless the ORM triggers no error and $child looks like having been persisted. In the second request you'll notice that there haven't been persisted any of the data belonging to the child table. ### [DDC-2983] TCI association not getting hydrated into sql statement Created: 14/Feb/14 Updated: 23/Mar/14 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.5 Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Machete Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: orm Environment: MySQL, using DoctrineORMModule (zf2 integration)  Description   /** * @ORM\Entity * @ORM\Table(name="base") * @ORM\InheritanceType("JOINED") * @ORM\DiscriminatorColumn(name="discriminator", type="string") * @ORM\DiscriminatorMap({ * "a" = "A", * "b" = "B", * }) */ class Base { /** * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="AUTO") */ protected$id; } /** * @ORM\Entity **/ class A extends Base { /** * @ORM\ManyToOne(targetEntity="B", inversedBy="as") */ protected $b; /** * @ORM\OneToMany(targetEntity="C", cascade={"persist"}) */ protected$cs; } /** * @ORM\Entity **/ class B Extends Base { /** * @ORM\OneToMany(targetEntity="A", mappedBy="b") */ protected $as; } /** * @ORM\Entity **/ class C { // ... }  Doing this: $a = new A(); $b = new B();$a->setB($b);$b->addA($a); var_dump($a->getB()); // outputs B (b not null!) var_dump($b->getAs()) // outputs A (private$_elements => [0] class B) $em->persist($a); $em->persist($b); $em->flush();  Leads to integrity constraint violation, b_id can not be null aka INSERT INTO a (id, b_id), (123, null); I have no idea why this happens. This works: $a = new A(); $b = new B();$a->setB($b);$b->addA($a); var_dump($a->getB()); // outputs B (b not null!) var_dump($b->getAs()) // outputs A (private$_elements => [0] class B) $em->persist($a); $em->flush();$em->persist($b);$em->flush(); 

 Comment by Benjamin Eberlei [ 23/Mar/14 ] This most likely happens because the UnitOfWork tries to set the owner and reverse incorrectly due to an ordering issue.

### [DDC-2954] Paginator loses items Created: 05/Feb/14  Updated: 12/Feb/14

Status: Awaiting Feedback
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: Major Reporter: Mariusz Jaskółka Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: Pagination, Paginator Environment: Linux and Windows, PHP 5, Oracle(OCI8)

 Attachments: LimitSubqueryOutputWalker.php     LimitSubqueryOutputWalker_bugfix.php

 Description
 Sometimes when when I use Paginator (Doctrine\ORM\Tools\Pagination\Paginator) with query contains orderBy with $fetchJoinCollection = true lot of joins with toMany associations there are too few items in result (no, it is not the end of list). There two situations: 1. I have four items on page 1 and two items on page 2 (pageLimit is 5). It is no so bad 2. I have four items on page 1 and there is no page 2 (while there should be 5 all items). This is very bad because I lose one item. ------------------------------------------------------------------ EDIT: In function Paginator::getIterator there is variable$ids. In my situation it contains five numbers [34,26,34,15,12]. There is duplicated value 34 but ids of top-level entities should be distinct (as far as we do not use CROSS JOIN, or maybe I am wrong). The Paginator::count function works correctly, it does not count duplicated values twice. Statement that gets $ids is like following: SELECT a.* FROM (SELECT DISTINCT ID2, BEGINTIME70 FROM (...) dctrn_result ORDER BY BEGINTIME70 DESC) a WHERE ROWNUM <= 5 ------------------------------------------------------------------ EDIT 2 - Bugfix description: The result items of the query is not unique because of "SELECT DISTINCT col_with_id, order_by_column (...) ORDER BY order_by_column". If we had items like following: (1,A) (1,B) (1,B) (2,C) After DISTINCT operation the result would be: (1,A) (1,B) (2,C) But we want to have unique firs column, not pairs. That's why we should do "ORDER BY" before "DISTINCT" - not in the same time. Please confirm if the solution is correct.  Comments  Comment by Marco Pivetta [ 05/Feb/14 ] Mariusz Jaskółka this needs more details Comment by Mariusz Jaskółka [ 06/Feb/14 ] OK, I will try to find out where the problem is. Comment by Mariusz Jaskółka [ 06/Feb/14 ] I have edited description, maybe additional information will help. Comment by Mariusz Jaskółka [ 07/Feb/14 ] I send the bugfix in attachment. I will describe it soon. Comment by Mariusz Jaskółka [ 07/Feb/14 ] Bugfix version 2 - previously I did not notice that oracle loses order after DISTINCT operation. Thus I used GROUP BY. Comment by Mariusz Jaskółka [ 11/Feb/14 ] I do not know if I can change status of this issue from "Awaiting Feedback". I can not see such option ### [DDC-2918] get statements from ORM Created: 15/Jan/14 Updated: 15/Jan/14 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: Flip Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  When doing persist() and then flush() the statements are not accessible anymore after the operation is done. The EntityManager uses an EntityPersister. When looking at the BasicEntityPersister->executeInserts() a new statement is created but it's not saved as part of another object. https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php#L260 Benefit: When having access to the statements afterwards, all the following methods would be available: http://www.php.net/manual/en/class.pdostatement.php Most interesting are rowCount and error related methods.  Comments  Comment by Steve Müller [ 15/Jan/14 ] Flip AFAIK you can use an SQL Logger for this which has to be set in the connection. The ORM testsuite makes use of this, too. See this example: https://github.com/doctrine/doctrine2/blob/master/tests/Doctrine/Tests/ORM/Functional/OneToOneEagerLoadingTest.php#L155 Comment by Flip [ 15/Jan/14 ] Yes sure, but using a logger will be a strange way to pipe it back into business logic. For example it's possible to do remove() on a proxy so you don't know if the row was present or not. or another situation .. when dealing with concurrency .. somebody else might have deleted the row already .. ### [DDC-2891] Impossible to pass a limit to a subquery Created: 07/Jan/14 Updated: 08/Jan/14 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: 2.4.2 Fix Version/s: None Security Level: All  Type: Improvement Priority: Major Reporter: alex Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  It seems that passing the limit to a subquery is not working $subquery = $em->createQueryBuilder()->from('...')->where('...')->setMaxResults(5);$query = $em->createQueryBuilder()->from('...')->where($qb->expr()->in('p.id', $subquery->getDQL()) );$query->getQuery()->getResult();  The query works but the is no specified limit in the resulting SQL. I am aware that DQL does not support the limits and offsets, so i guess there should be another way to get this working?

 Comment by Steve Müller [ 08/Jan/14 ] Can you please tell which database platform you are using? Because limiting results heavily depends on the platform used. Comment by alex [ 08/Jan/14 ] MySql Comment by Steve Müller [ 08/Jan/14 ] Hmmm I am not quite sure if the limit/offset is invoked for subqueries but I don't see why it shouldn't. Also I think this is not a DBAL issue because the limit/offset support for MySQL is the easiest we have on all platform. See: https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php#L51-L63 The query doesn't have to be modified but instead only the limit clause is appended to the query. Can you maybe provide the generated SQL for that query? Comment by alex [ 08/Jan/14 ] I think if you try to build any query with QueryBuilder, set a limit to it with setMaxResults then call getDQL method, you should see that the output contains no info about limit. So if you look at my code example , at $qb->expr()>in('p.id',$subquery>getDQL()), then you will see that the getDQL passes to the IN expression a query which already DOES NOT have limit. So this is the place where any info about limits and offsets gets lost. So I fail to see what it has to do with any specific db engine,however I can provide the mysql resulting query if you want,though it looked perfectly normal to me,just lacks the LIMIT part.

### [DDC-2870] Doctrine error when using SUM(a.id=1) as ìdentifier: Expected Doctrine\ORM\Query\Lexer::T_CLOSE_PARENTHESIS, got '=' Created: 22/Dec/13  Updated: 06/Jan/14

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

 Type: Bug Priority: Major Reporter: Maxim Geerinck Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: dql Environment: Symfony2 bundle

 Description
 Doctrine error when using SUM(a.id=1) as ìdentifier: Expected Doctrine\ORM\Query\Lexer::T_CLOSE_PARENTHESIS, got '=' I am trying to execute a query in doctrine that contains something like this SUM(a.id = 1) as 1 for some reasons it always gives me the following error: [Syntax Error] line 0, col 15: Error: Expected Doctrine\ORM\Query\Lexer::T_CLOSE_PARENTHESIS, got '=' This is the code i am using $result =$em->getRepository('MyBundle:PlayerAction') ->createQueryBuilder('pa') ->select(array( 'SUM(a.id=1) as 1, SUM(a.id=2) as 2, SUM(a.id=3) as 3, p.playerName, pa.timestamp' )) ->innerJoin('pa.action', 'a') ->innerJoin('pa.player', 'p') ->where('pa.timestamp > ?1') ->groupBy('p') ->setParameter(1, time() - $time) ->orderBy('p.playerName', 'ASC'); ### [DDC-2851] Allow set custom collection initializer at runtime Created: 12/Dec/13 Updated: 12/Dec/13 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.4.1 Fix Version/s: None  Type: Improvement Priority: Major Reporter: Konstantin Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None  Description  Use case: Company, Category, CompanyCategory entities. We are loading set of companies and should initialize Company.companyCategories collection with joined categories, which ordered by Company.title. I cann't do it via Criteria API, it doesn't supports joins. + I should return same PersistentCollection instance (Company.companyCategories used in Symfony2 forms). Current workaround:  public function loadCompanyCategoriesCollectionForCompany(Company$company) { $companyCategories =$this->_em->createQueryBuilder() ->select('cc') ->from('OloloCompaniesBundle:CompanyCategory', 'cc') ->join('cc.category', 'c') ->addSelect('c') ->orderBy('c.title') ->where('cc.company = :company') ->setParameter('company', $company) ->getQuery() ->getResult() ;$coll = $company->getCompanyCategories(); foreach ($companyCategories as $companyCategory) { /* @var$coll \Doctrine\ORM\PersistentCollection */ $coll->hydrateAdd($companyCategory); } $coll->setInitialized(true); }  What would be nice: native API for setting custom initializers. ### [DDC-2852] Enclose subquery with parenthesis in from clause (QueryBuilder) Created: 12/Dec/13 Updated: 12/Dec/13 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: Matthieu Pécro Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: from, orm, parenthesis, querybuilder,, subquery  Description  Hi In QueryBuilder from clause, when argument is a QueryBuilder (not a string like a table), there are not parenthesis enclosure on the subquery. Ex:$subqb->select('myfield')->from('mytable'); $qb->from($sub, 'myalias) DQL is : SELECT myfield FROM SELECT myField FROM mytable myalias. This is not working on MySQL. It should be : SELECT myfield FROM (SELECT myField FROM mytable) myalias.

 Comment by Christophe Coevoet [ 12/Dec/13 ] I don't understand your statement This is not working on MySQL. after giving a DQL statement. MySQL does not support any DQL. It runs SQL. And DQL does not support using a subselect in the FROM clause

### [DDC-2841] Preload data for association Created: 06/Dec/13  Updated: 06/Dec/13

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

 Description

### [DDC-2744] Inheritance - Empty value for discriminatorColumn in query Created: 16/Oct/13  Updated: 16/Oct/13

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

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

 Description
 Hello, I have an inheritance problem with the following classes getRepository('ProjMyBundle:ClassSubOne')->findAll()  the query builded SELECT field, field2 FROM CLASSTOP WHERE AVAL IN ()  The value for the discriminator column is not passed Thanks for your help

### [DDC-2742] 2 ManyToMany relations to the same target entity make the schema update fail by default Created: 15/Oct/13  Updated: 15/Oct/13

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

 Type: Bug Priority: Major Reporter: Christophe Coevoet Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: mapping, schematool

 Description
 At some point in the Doctrine releases (I don't remember which version it was), the default naming of the join table of a ManyToMany relation changed from using the property name to using the name of the target entity. This makes it impossible to use multiple ManyToMany relations to the same target entity in a class without naming join tables explicitly. A SchemaException is thrown by the SchemaTool when trying to update the schema. Note that this issue is not caught by the SchemaValidator. It will display us that the mapping files are correct (before throwing the above exception in the second step when trying to compare it to the existing database)

pager produces wrong results on postgresql (DDC-1958)

### [DDC-2729] Same bug affects SQLServer2008Platform Created: 07/Oct/13  Updated: 07/Oct/13

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

 Type: Sub-task Priority: Major Reporter: Rafi Adnan Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: paginator Environment: SQL Server 10.50.1617 unixODBC 2.2.14 PHP 5.4.19

 Description
 If the class is patched with the following: if ($this->platform instanceof SQLServer2008Platform) {$this->preserveSqlOrdering($AST,$sqlIdentifier, $innerSql,$sql); } It fixes the issue.

### [DDC-2746] When generating DQL query entities with "Class Table Inheritance" is a SQL generated inconsistent Created: 16/Oct/13  Updated: 18/Oct/13

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

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

 Attachments: DDC2746Test.php     DDC2746Test_original.php

 Description
 When I run the query DQL involving entities "Class Table Inheritance" is a SQL generated inconsistent see this gist: https://gist.github.com/hugohenrique/b322e8d998c870265177

 Comment by Hugo Henrique [ 17/Oct/13 ] An example of incoherent generation of SQL: https://gist.github.com/hugohenrique/b322e8d998c870265177

### [DDC-2727] "Expression" or "Update" API, similar to the Criteria API Created: 07/Oct/13  Updated: 07/Oct/13

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

 Description
 I created a discussion in the mailing list (https://groups.google.com/forum/#!topic/doctrine-dev/7HfEqOwhkDk) but no answer, so I'm moving the discussion here. The Criteria API provides an abstraction to filter collections/repositories, may they be in memory (filtering in PHP) or in a database (filtering using a SQL query). I was thinking about an "Expression" API which would work like array_map to apply changes in bulk to entities. For example, if you have a collection where entities have a $position field, if I insert an item in the list, I have to increment the position of all the following items. For this, I have 2 options: PHP: loading the entities in memory, iterate over them and increment$position SQL: run a UPDATE position=position + 1 WHERE … The second option is much more efficient, but it breaks the abstraction of the model because I have some behavior written explicitely in SQL. Furthermore, the objects loaded in memory will note be updated with the SQL query. So the "Expression" API would work like the Criteria API: interface Updatable { public function apply(Expression $e); }$expression = new Expression(); // For each item after position "10" $expression->criteria->where(Criteria::expr()->gt('position', 10)); // Increment the position$expression->set('position', 'position + 1'); $collection->map($expression);  The expression here would be applied: in memory if the collection is already loaded else in database using SQL The expression could be applied to a Collection and to a Repository (like the Criteria). About the API offered by the Expression class, there are several options: // Option 1 // More powerful, but needs to parse and evaluate the string class Expression { public $criteria; public function set($field, $value); }$expression->set('position', 'position + 1'); // Option 2 // Easier to implement, more limited class Expression { public $criteria; public function setValue($field, $value); public function setValueFromField($targetField, $sourceField); public function add($field, $number); public function multiply($field, $number); public function divide($field, $number); } // Option 3 // Like option 2 but more extensible class Expression { public$criteria; public function set($field, Operation$operation); }  I think I like the third one better because we have full control over the supported operations, and adding support to new kinds of operation is easy. The first one would require defining a whole language of allowed expressions... What do you think of all that?

 Comment by Matthieu Napoli [ 07/Oct/13 ] Added option 3 after trying to write a POC Comment by Matthieu Napoli [ 07/Oct/13 ] Here is a POC on the doctrine/collections side: https://github.com/mnapoli/collections/compare/master...feature;Updatable works with ArrayCollection I'm looking at the ORM side. Feedback welcome, especially with the class/namespace/method names.

### [DDC-2709] Defining Columns as "Updatable" or "Insertable" Created: 27/Sep/13  Updated: 27/Sep/13

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

 Description
 With Hibernate I can define a column as Updatable/Insertable or non-Updatable/non-Insertable so that this field is considered read-only and is not part of any update/insert statement. I'd like to have the same possibility in Doctrine. In my use case a value is generated and maintained by database triggers. In my application I only want to read this value but the application should never try to insert or update the column. Updatable/Insertable in the Hibernate documentation: http://docs.jboss.org/hibernate/annotations/3.5/reference/en/html_single/#entity-mapping-property-column

### [DDC-2691] Test Suite: Drop other connections before dropping database PostgreSQL Created: 19/Sep/13  Updated: 19/Sep/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: Flip Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Windows 7 Professional 64 bits PHP 5.4.11 (cli) (built: Jan 16 2013 20:26:26) Doctrine dev-master from 18-9-2013 PostgreSQL 9.2.4 build 1600, 64-bits

 Description
 The test suite is trying to run the command DROP DATABASE doctrine_tests  This fails, together with lots of tests when another user is connected (for example through the pgAdmin program). It would be nice if the test suite had an option to drop existing connections, which can be done with the following command: SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'doctrine_tests'; 

### [DDC-2697] ObjectHydrator::hydrateRowData fails to hydrate first fetch joined entity Created: 20/Sep/13  Updated: 06/Dec/13

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

 Type: Bug Priority: Major Reporter: Austin Morris Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: orm Environment: All

 Description
 Let's say I have accounts, contacts, and contact types. Any given contact can have be any kind of contact type to any account. This is all managed through an account_contacts table with a 3-way composite PK of the contact_id, account_id, and type_id. All of this translates to 4 entities, the account, contact, type, and accountContact entity. The id of the accountContact entity is the three other entities which is holds. When I use query builder to retrieve the accountContacts based on some condition, and also fetch join contacts, accounts, and types so that they are eagerly loaded, the ObjectHydrator fails to load the first accountContact returned. This is because the first time through hydrateRowData, the fetch joined entities are hydrated first. The problem is $this->_rsm->parentAliasMap[$dqlAlias] does not contain an entry for the accountContact (root entity). Not until an accountContact is hydrated does that get set. In the mean time, the other three entities were set to null because there is no parent alias yet (in version 2.4, this is line 405. Subsequent loops through hydrateRowData work because by this time the parent alias is set. But that first row returned is always an accountContact containing three null objects.

 Comment by Benjamin Eberlei [ 26/Oct/13 ] Austin Morris Can you show the QueryBuilder select clause you are using? Have you tried sorting the accountContacts first? $qb->select('accountContacts, contact, account, type')  This way it should definately work, and then there is also some attempts to resort this way if you dont have that, but its not always working. Comment by Austin Morris [ 06/Dec/13 ] Sorry, I don't have the original select clause. I ended up doing something different and can't seem to find my original code. Comment by Benjamin Eberlei [ 06/Dec/13 ] I have another person that reported a simliiar bug with reproducable test case. I hope to investigate this very soon. ### [DDC-2694] Hydrating with entities with the NEW operator Created: 19/Sep/13 Updated: 21/Jan/14 Status: Open Project: Doctrine 2 - ORM Component/s: None Affects Version/s: Git Master Fix Version/s: None Security Level: All  Type: New Feature Priority: Major Reporter: Flip Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 3 Labels: None Issue Links:  Duplicate is duplicated by DDC-2899 Allow the NEW operator to construct o... Resolved  Description  It would be nice if the new function accepted objects as parameters, like this: new Country(country, some_extra_stuff)  Alternatively another keyword could be introduced that constructs the object with the parameter and afterwards hydrates it. ### [DDC-2672] Using fetchAll() in Hydration can improve TCP Wait Created: 11/Sep/13 Updated: 13/Dec/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  Hydration currently fetches the rows and hydrates them by interleaving both operations. This can cause an increased TCP wait time, because the PHP processing takes a bit of time. We should investigate weather changing to fetchAll() improves the overall performance.  Comments  Comment by Benjamin Eberlei [ 13/Dec/13 ] We can introduce a new query hint to allow us to support both: 'DBAL_FETCH_ALL'. If that is set, use fetchAll(), otherwise fetchRow(). ### [DDC-2659] Notice: Undefined index: sourceToTargetKeyColumns in /doctrine/orm/lib/Doctrine/ORM/Persisters/BasicEntityPersister .php line 1180 Created: 08/Sep/13 Updated: 08/Sep/13 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: Git Master Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Taylor Kaplan Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: orm Environment: Symfony2 With PHP 5.5 on Ubuntu 12.04 LTS using Apache 2  Attachments: Client.php ClientFixtures.php User.php UserFixtures.php  Description  I am getting this error:  Notice: Undefined index: sourceToTargetKeyColumns  When I try to load my data fixture. There are two ordered fixtures that I'm dealing with: Clients and Users. The client datafixture looks like:  /** * {@inheritDoc} */ public function load(ObjectManager$manager) { for($index = 0;$index < 224; $index ++) {$client = new Client(); $manager->persist($client); $this->addReference($index . 'Client', $client); }$manager->flush(); $manager->clear(); } public function getOrder() { return 0; }  While the user data fixture looks like: $user = New User(); $client =$this->getReference($index . 'Client'); // This line is causing the problem$client->setUser($user);  For whatever reason, I don't seem to be having issues with any of my other fixtures. Just this one. I've doubled check the entity relationships which are shown bellow. My Client.php entity:  /** * @ORM\ OneToOne(targetEntity="User", mappedBy="clientAccount") */ protected$user;  My User.php entity:  /** * @ORM\ OneToOne(targetEntity="Client", inversedBy="user") */ protected $clientAccount;  There seems to be a bug with the return value of getAssociationMapping() for special conditions when implemented in BasicEntityPersister. The files for my fixtures and entities for this project have been attached. ### [DDC-2671] YAML mapping: entity generation with inheritance does work Created: 11/Sep/13 Updated: 11/Sep/13 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: Major Reporter: Peter Tulala Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: inheritance, mapping, yaml  Description  Entities inherited from parent entities should be defined as class Foo extends Bar. However YAML driver ignores inheritance hierarchy and does not use "extends" keyword at all. ### [DDC-2649] Hydration in bidirectional, OneToOne relationship, PK as FK for owning side, is problematic Created: 04/Sep/13 Updated: 04/Sep/13 Status: Open Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.3.4 Fix Version/s: None  Type: Bug Priority: Major Reporter: Jérôme Viveret Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: FK, OneToOne, PK, bidirectional  Description  I am referring to this situation https://gist.github.com/anonymous/6435032 The following problem occur: When using HardCover as the root entity of a query, the ObjectHydrator fails to properly register the first [HardCover of the resultset]'s Book. Only the first. The following HardCover have their Books correctly linked. The inverse situation (using Book as the root entity) works fine. When some other entity (say WoodenPart) is linked to HardCover via a ManyToOne association, using WoodenPart as a query root results in no WoodenPart have their HardCover registered. ### [DDC-2642] GROUP BY with inherited entity (which is also in SELECT clause) does not list columns from inheriting entities Created: 30/Aug/13 Updated: 30/Aug/13 Status: Open Project: Doctrine 2 - ORM Component/s: DQL, ORM Affects Version/s: 2.3.4 Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Ondřej Mirtes Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: PostgreSQL  Description  The summary pretty much sums it up. Code example: https://gist.github.com/ondrejmirtes/6388434 ### [DDC-2637] [GH-769] Add Custom Persisters Created: 28/Aug/13 Updated: 15/Apr/14 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: Doctrine Bot Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Issue Links:  Duplicate is duplicated by DDC-2629 [GH-768] DDC-391: Add support to conf... Resolved Reference relates to DDC-391 Allow to specifiy custom Entity and C... In Progress  Description  This issue is created automatically through a Github pull request on behalf of guilhermeblanco: Message: Adding support for custom persisters as defined by DDC-391. Implementing both Entity and Collection based Persisters  Comments  Comment by Doctrine Bot [ 02/Jan/14 ] A related Github Pull-Request [GH-768] was closed: https://github.com/doctrine/doctrine2/pull/768 Comment by Doctrine Bot [ 15/Apr/14 ] A related Github Pull-Request [GH-769] was closed: https://github.com/doctrine/doctrine2/pull/769 ### [DDC-2635] Problems with Filtering SQL Queries based on schema Created: 27/Aug/13 Updated: 27/Aug/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  The filtering in Schema Tool based on current database schema is not extendable very easily. We need a way to allow creating all, or only a subset of schemas in both supporting and non supporting databases. ### [DDC-2631] Replacing object in a OneToOne with OrphanRemoval=true isn't working as expected Created: 23/Aug/13 Updated: 26/Nov/13 Status: Awaiting Feedback Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.4 Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Felipe Guaycuru Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: orm Environment: PHP 5.4  Description  So I have a class defined like this: class PhoneSettings { [...] /** @OneToOne(targetEntity="Medium", cascade= {"persist", "remove"} , orphanRemoval=true) @JoinColumn(name="medium_id", referencedColumnName="medium_id", nullable=true, onDelete="SET NULL") **/ protected$medium = null; [...] } And class Medium has no reference to the class Settings. Now suppose I have a $Settings object that is already persisted and has been correctly loaded. Also suppose that the$Settings object has a $medium (that is,$Settings->medium = $OldMedium) Now suppose I do:$Settings->medium = $NewMedium; Where$NewMedium is a different Medium object. When I persist $Settings, Doctrine does delete$OldMedium from the DB, but the problem is that it also deletes $NewMedium ... I have tried removing onDelete="SET NULL", but then I receive a "cannot delete, constraint failed" error... ### [DDC-2630] Filters with joined inheritance Created: 22/Aug/13 Updated: 09/Jan/14 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: Florian Vilpoix Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: inheritance, sql-walker, sqlfilter  Description  Hello, I'm trying to use SQLFilter with a Joined Inheritance, and the sql Walker never applies filters on the sub-class, even if I make my SELECT on the sub-class or the root. In the SqlWalker, the methods 'generateFilterConditionSQL' says : // The classes in the inheritance will be added to the query one by one, // but only the root node is getting filtered I don't understand why, and I would like to know if there is any way to apply filters to subclasses in joined-inheritance. Thanks a lot  Comments  Comment by Menno Holtkamp [ 09/Jan/14 ] Are you sure you apply the filter on the root Entity? This discussion might be usefull: https://groups.google.com/forum/#!topic/doctrine-user/e1cPZOorfaQ ### [DDC-2617] OneToMany annotation should not work with MappedSuperclass Created: 18/Aug/13 Updated: 08/Sep/13 Status: Open Project: Doctrine 2 - ORM Component/s: Mapping Drivers Affects Version/s: None Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: jonathan bensaid Assignee: Fabio B. Silva Resolution: Unresolved Votes: 0 Labels: None  Description  Using annotations in my model mapped to "mapped superclass" I can use one to many relations et every bidirectional relation I want. Using yaml or xml it suddenly doesn't work and throw me an error. Annotations should work the same way and should not authorize one to many or any bidirectional relation.  Comments  Comment by Benjamin Eberlei [ 08/Sep/13 ] Its actually the other way around, yml and xml need to allow this, because it works with association overrides. Comment by Benjamin Eberlei [ 08/Sep/13 ] Assigning Fabio ### [DDC-2605] Console command generates entity stubs that break type hinting contracts. Created: 09/Aug/13 Updated: 12/Aug/13 Status: Open Project: Doctrine 2 - ORM Component/s: Tools Affects Version/s: 2.3 Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Alex Parker Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: cli, orm, stubs, tools, type-hinting Environment: Debian Linux (crunchbang) PHP 5.4.4-14+deb7u2 (cli) MySQL Server version: 5.5.31-0+wheezy1 (Debian)  Attachments: thcontract.png  Description  I've found that the doctrine cli tool seems to break PHP's type hinting contracts in the scenario outlined in the attached diagram, following a process outlined in my stack overflow post here: http://stackoverflow.com/questions/18098552/using-symfony-2-cli-tools-how-can-i-generate-getters-and-setters-with-correct-t The result is code that throws E_STRICT notices which we are loathe to suppress for CI reasons, e.g: Runtime Notice: Declaration of ... should be compatible with ... in ... line ... As mentioned I have asked on Stack Overflow to no avail, as well as the FreeNode IRC channels starting with #symfony. The response from #symfony is that this is a doctrine issue, with suggestions being made that my problem is that I am using the CLI tools. I don't think it would be too difficult to fix this issue. I had a quick look at the Doctrine\ORM\Tools\EntityGenerator class and Doctrine\ORM\Tools\Console\Command\GenerateEntitiesCommand and it looks like it should be possible to find the eldest ancestor definition of a function and honour its type hints. I am open to this being an implementation issue on my end, but I do feel this may be either a bug or an opportunity to improve the CLI tools as for most other purposes they have been a huge benefit to automating my workflow. Thanks for your time and consideration. ### [DDC-2590] Class inheritance - left join between child and parent entities Created: 06/Aug/13 Updated: 25/Mar/14 Status: Awaiting Feedback Project: Doctrine 2 - ORM Component/s: ORM Affects Version/s: 2.3.1, 2.3.2, 2.3.3, 2.3.4 Fix Version/s: None Security Level: All  Type: Bug Priority: Major Reporter: Tomáš Ďuračka Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: inheritance, joins, orm, sql-walker  Description  The piece of code given under creates wrong sql to me. Module is parent entity for BusinessModule entity. Category is joined with BusinessModule. Module entity is only left joined to its child entity and that's the problem because it contains a field "name" used for filtering. So even if there is no module having the name, categories are still included. I need the parent entity to be inner joined to child entity not left joined. File doctrine2/lib/Doctrine/ORM/Query/SqlWalker.php line 353: // If this is a joined association we must use left joins to preserve the correct result.$sql .= isset($this->queryComponents[$dqlAlias]['relation']) ? ' LEFT ' : ' INNER ';  $qb->select('c') ->from('Category', 'c') ->join('c.module', 'm', 'WITH', 'm.name = :moduleName') ->setParameter('moduleName',$moduleName);  SELECT c0_.category_id AS category_id0, c0_.title AS title1, c0_.h1 AS h12, c0_.alias AS alias3, c0_.insertion_fee AS insertion_fee4, c0_.description AS description5, c0_.parent_category_id AS parent_category_id6, c0_.module_id AS module_id7 FROM category c0_ INNER JOIN business_module b1_ ON c0_.module_id = b1_.module_id LEFT JOIN module m2_ ON b1_.module_id = m2_.module_id AND (m2_.name = ?) 

 Comment by Marek Štípek [ 06/Nov/13 ] I am experiencing the same issue. The workarround could be to use LEFT JOIN with IS NOT NULL condition... But it also doesnt work after this commit https://github.com/doctrine/doctrine2/commit/d9c1782a4f6d46f66e9deb2c375830f9192d4482 (i had to revert to dev-master#13c1efb240dd0af25ad0abe230df98ec895892c7)

### [DDC-2595] UoW is not supposed to trigger the post-load event for uninitialized proxies. Created: 06/Aug/13  Updated: 06/Aug/13

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

 Type: Bug Priority: Major Reporter: Juti Noppornpitak Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 1 Labels: None

 Description
 When one entity have multiple nested levels and associated to 700+ other entities, the ORM exhausts a large amount of memory and execution time which exceeds either the memory limit or the maximum execution time. Prerequisite: 1. generate an entity, named "Mr. G", with 4 nested levels of association. 2. ensure that the generated entity associating to 700+ entities. 3. create a post-load event listener which may or may not be restricted to uninitialized proxies. How to Reproduce: 1. have a code to load the "Mr. G" entity. X. (Done) Notes: The initial investigation indicates that UnitOfWork should not trigger the post-load event for uninitialized proxies. One thing worth-mentioning is that if the event listener ignores all proxies, we will not have this problem. However, some properties (e.g., ones of type TEXT/BLOB) are not loaded into normal entities but they are loaded into the proxies.

### [DDC-2596] With Access to ResultSetMapping, Paginator can decide on fetchJoinCollection and useoutputWalker Created: 07/Aug/13  Updated: 07/Aug/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

### [DDC-2567] auto generated index name cannot be overriden with annotation Created: 23/Jul/13  Updated: 23/Jul/13

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

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

 Description
 Hi, I have an unexpected behaviour when generating SQL from an entity using annotation. The default indexes name (generated by _generateIdentifierName) are automatically overwriting the name I have specified in my entity. I have patched the following file https://github.com/doctrine/dbal/blob/master/lib/Doctrine/DBAL/Schema/Table.php with: // check for duplicates foreach ($this->_indexes as$idxKey => $existingIndex) { if ($indexCandidate->isFullfilledBy($existingIndex)) { //return$this; // old implementation unset($this->_indexes[$idxKey]); } } but I don't think this is the correct way forward. Let me know if you require more information Thanks

### [DDC-2560] Schema tool invalid DDL syntax for default values Created: 19/Jul/13  Updated: 19/Jul/13

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

 Type: Bug Priority: Major Reporter: Ben Davies Assignee: Marco Pivetta Resolution: Unresolved Votes: 0 Labels: schematool Environment: Postgresql

 Description
 Not sure if this is Postgresql specific or not, but here are the reproduction steps: Have a table with a column setup like so: ALTER TABLE usr ADD COLUMN contact_count integer; ALTER TABLE usr ALTER COLUMN contact_count SET NOT NULL; ALTER TABLE usr ALTER COLUMN contact_count SET DEFAULT 0;  Have a Entity Column Definition like so:  /** * @var integer $contactCount * * @ORM\Column(name="contact_count", type="integer", nullable=false) */ private$contactCount = 0;  orm:schema-tool:update will generate the following SQL: ALTER TABLE usr ALTER contact_count SET ;  adding options={"default":0}  to the column definition results in no sql being generated (correctly I assume)

 Comment by Marco Pivetta [ 19/Jul/13 ] The ORM doesn't support default column values. That's fine-tuning you can do on the column definitions. Your "workaround" is actually the correct way of dealing with this kind of DDL change. Comment by Ben Davies [ 19/Jul/13 ] I realise the ORM doesn't support default values, but the point is that the schematool picks up a diff in the columns, tries to generate a diff, and generates an invalid sql statement. Surely that is a bug? Comment by Marco Pivetta [ 19/Jul/13 ] Ben Davies the DBAL is responsible for generating this wrong DDL... Are you able to reproduce this in DBAL only? Comment by Ben Davies [ 19/Jul/13 ] Happy to try. Comment by Ben Davies [ 19/Jul/13 ]

### [DDC-2528] Extracting entities through DQL query resets the previous associations Created: 24/Jun/13  Updated: 25/Jun/13

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

 Type: Bug Priority: Major Reporter: Koustubh Sinhal Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: None Environment: Windows 8

 Description

### [DDC-2495] Partial objects not working with STI Created: 10/Jun/13  Updated: 11/Jun/13

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

 Type: Bug Priority: Major Reporter: Radoslaw Ejsmont Assignee: Benjamin Eberlei Resolution: Unresolved Votes: 0 Labels: STI, dql, orm, partial Environment: Symfony2 project, Doctrine ORM with MySQL database backend

 Attachments: CrossVial.php     Entity.php     InjectionVial.php     Stock.php     StockVial.php     Vial.php

 Description
 When I try to create a query retrieving partial objects of a root class in single table inheritance hierarchy, the resulting SQL includes all fields from the whole class hierarchy. DQL: SELECT partial v. {id, setupDate, flipDate} FROM VIB\FliesBundle\Entity\Vial v WHERE v.id IN (1,2,3,4,5,6,7,8,9,10) SQL: SELECT v0_.setupDate AS setupDate0, v0_.flipDate AS flipDate1, v0_.id AS id2, v0_.type AS type3, v0_.parent_id AS parent_id4, v0_.position_id AS position_id5, v0_.prevPosition_id AS prevPosition_id6, v0_.incubator_id AS incubator_id7, v0_.stock_id AS stock_id8, v0_.male_id AS male_id9, v0_.virgin_id AS virgin_id10, v0_.targetStock_id AS targetStock_id11, v0_.targetStockVial_id AS targetStockVial_id12 FROM Vial v0_ WHERE (v0_.id IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)) AND v0_.type IN ('vial', 'stock', 'cross', 'injection')

### [DDC-2452] Additional WITH` condition in joins between JTI roots cause invalid SQL to be produced Created: 16/May/13  Updated: 27/Mar/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
Affects Version/s: G