[DDC-3843] indexBy collection loses index key after calling a ->matching(criteria) on it Created: 22/Jul/15  Updated: 22/Jul/15

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

Type: Bug Priority: Minor
Reporter: Matteo Orefice Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, orm
Environment:

Linux Debian (7.8) NGINX (1.8.0) PHP (5.5.25-1~dotdeb) MySQL (5.6.24-72.2)



 Description   

When I retrieve a filtered collection of entities which has indexBy attribute it loses index keys in the result. Before calling matching() method i tried to call toArray() and It solved the problem, I don't know if it is a bug .

class Entity {
/**
     * @var ArrayCollection
     * @ORM\OneToMany(targetEntity="Entity\Arcansel\BasketItem",mappedBy="userSession",indexBy="id",cascade={"persist","remove","merge"})
     */
    protected $basketItems;


// Some comments here
public function getBasketItems()
    {
        $date = DateTime::newDateTimeUniversal();
        $criteria = Criteria::create()->where(Criteria::expr()->gt("addTime",$date));
        // next line of code prevents returned collection to lose indexBy keys
        $a = $this->basketItems->toArray();
        return $this->basketItems->matching($criteria);
    }
}





[DDC-3814] counting inverse column of in dql Created: 08/Jul/15  Updated: 08/Jul/15

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

Type: Bug Priority: Major
Reporter: Maximilian Bosch Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: collection, dql, mysql, orm

Attachments: PNG File doctrine-query.PNG     PNG File dql-fail.PNG    

 Description   

I have a self-referenced bidirectional relation in order to show users and their followers. Now I'd like to show the users with the most followers.
But when executing the unit test, doctrine2 tells me that the inverse column user.followers is not valid.

On the first attachement you can see the code. This fetches the user entity and the amount of followers hidden (the followers column is not the owning side, but the inversed column).
On the second picture you can see the complete error message and the call stack






[DDC-3699] [GH-1387] Fix skipping properties if they are listed after a not loaded relation. Created: 17/Apr/15  Updated: 15/Jul/15  Resolved: 15/Jul/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.5, 2.4.7
Fix Version/s: 2.5.1, 2.6.0
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, inheritance, lazy-loading, merge, persistent-collection, properties, proxy


 Description   

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

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

Message:

This issue fixes an issue that occurs when merging entites, when the entity that is being merged has some other properties after a association type field.

Fixes the following scenario :
Your entity extends a parent entity and when it is merged by the entity manager first its fields are computed, this is done correctly bby `ReflectionPropertiesGetter::getProperties()`, but in the `mergeEntityStateIntoManagedCopy` method the iteration is stopped when it gets to a field that is a relationship and it is Proxy and was not loaded yet.
The order in which the fields are computed is : current class properties and then the parent properties, so if the current class has a lazy loaded relationship then the properties of the parent are not merged.

So the fix doesn't stop the iteration it just skips the current property that is not loaded yet and goes to the next property.



 Comments   
Comment by Doctrine Bot [ 18/Apr/15 ]

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

Comment by Doctrine Bot [ 15/Jul/15 ]

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





[DDC-3690] PersistentCollection uses private property Created: 14/Apr/15  Updated: 16/Jun/15  Resolved: 16/Jun/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Lazy Loading, ORM
Affects Version/s: 2.5
Fix Version/s: 2.5.1
Security Level: All

Type: Bug Priority: Blocker
Reporter: Roel Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: collection, persistent-collection, release


 Description   

1. PersistentCollection in Doctrine 2.5 makes uses of the $initialized property defined in the AbstractLazyCollection of doctrine\collection (https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/PersistentCollection.php#L113)
2. Doctrine 2.5 depends on version ~1.2 of doctrine\collection that marks the $initialized property as private https://github.com/doctrine/collections/blob/v1.2/lib/Doctrine/Common/Collections/AbstractLazyCollection.php
3. Hence writing to the initialized variable fails. And thus code related to initialization fails.

A fix is already applied to doctrine\orm https://github.com/doctrine/collections/commit/e2eef4629349fd847c8e080b8f729ab33e81e10f but is not tagged. Possible fix would be to release a new version of doctrine\collection as 1.2.1.



 Comments   
Comment by Roel [ 14/Apr/15 ]

Due to this several tests fail in our code-base.

Comment by Marco Pivetta [ 14/Apr/15 ]

This is a bug caused by the fact that ORM 2.5 should depend on Collections 1.3.0 - I'll look into it ASAP.

Comment by Marco Pivetta [ 15/Apr/15 ]

Collections 1.3.0 was released, but I'll keep this open until ORM 2.5.1 is out.

Comment by Benjamin Eberlei [ 16/Jun/15 ]

I pushed v1.2.1 with changing $initialized to protected already.





[DDC-3678] [GH-1376] add missing property initialized to PersistentCollection Created: 08/Apr/15  Updated: 08/Apr/15  Resolved: 08/Apr/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: collection, initialized, persistent-collection


 Description   

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

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

Message:

This property is accessed from various methods in PersistentCollection, but not declared prior to __construct()



 Comments   
Comment by Doctrine Bot [ 08/Apr/15 ]

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

Comment by Doctrine Bot [ 08/Apr/15 ]

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





[DDC-3667] Fetch-joining a collection that has a field with a default value of `array` causes a fatal error Created: 05/Apr/15  Updated: 05/Apr/15  Resolved: 05/Apr/15

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

Type: Bug Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, default-value, dql, fetch-join, hydrator, persistent-collection


 Description   

With a class like:

class Foo { private $bar = []; }

Fetch-joining like following (with fetch-joined results) will cause a fatal error:

SELECT f, b FROM Foo f JOIN f.bar b





[DDC-3618] Refactor PersistentCollection Created: 16/Mar/15  Updated: 16/Mar/15

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

Type: Improvement Priority: Major
Reporter: Varga Bence Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: collection, orm


 Description   

PersistentCollection - a final class - contains all the metadata, used to speed up updates (through $snapshot). This information should be removed from the collection object and stored elsewhere, loosely coupled.

Doctrine2 uses the data mapper pattern (instead of Doctrine1's active record approach). This tells me that the designers see the importance of freedom which comes with loose coupling. Entities don't have to extend fixed base classes, why do collections?

Use case: I would like to use a wrapper around Collection (my current environment requires collections to have a certain functionality). This is possible in theory, but as I do the first step I'm losing all the advantages coming with PersistentColelction. Since it is a final class and logically an interface by itself (see the sniffing in ObjectHydrator#initRelatedCollection) it is impossible to create a wrapper which exposes the same functionality.

A short-term solution would be to extract an interface from PersistentColelction. A long-term one would be to manage the persisted state (currently PersistentCollection#snapshot) elsewhere (accessed through the EntityManager maybe).






[DDC-3544] [GH-1288] Hotfix - #1169 - extra lazy one to many must be no-op when not doing orphan removal Created: 27/Jan/15  Updated: 28/Jan/15  Resolved: 28/Jan/15

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

Type: Bug Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, extra-lazy, lazy-loading, onetomany, orphanRemoval

Issue Links:
Dependency
is required for DDC-3343 `PersistentCollection::removeElement`... Resolved
is required for DDC-3536 [GH-1281] Hotfix/#1169 extra lazy one... Resolved

 Description   

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

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

Message:

See https://github.com/doctrine/doctrine2/pull/1281#issuecomment-71403668



 Comments   
Comment by Doctrine Bot [ 28/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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

Comment by Doctrine Bot [ 28/Jan/15 ]

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





[DDC-3534] [GH-1280] [DDC-3346] #1277 find one with eager loads is failing Created: 23/Jan/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, eager, fetch, hydrator, lazy-loading, many-to-many, onetomany, persister

Issue Links:
Dependency
is required for DDC-3346 findOneBy returns an object with part... Resolved
is required for DDC-3531 [GH-1277] [DDC-3346] Failing test for... Resolved

 Description   

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

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

Message:

Ping @scaytrase

Note that this is a first revision and needs refactoring, so please consider helping out with that if you can.

Ping @guilhermeblanco: please check the `CachedPersisterContext` stuff: it's dirty as heck, but that's because the persister internal generated SQL caching is inconsistent as heck too.

Resolution path for 2.4.x will be to throw an exception if there is an offset or a limit.



 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DDC-3531] [GH-1277] [DDC-3346] Failing test for issue (bad findOneBy behaviour with eager fetch) Created: 22/Jan/15  Updated: 25/Jan/15  Resolved: 23/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: collection, eager, fetch, hydration, many-to-many, onetomany, persister

Issue Links:
Dependency
depends on DDC-3534 [GH-1280] [DDC-3346] #1277 find one w... Resolved
is required for DDC-3346 findOneBy returns an object with part... Resolved

 Description   

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

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

Message:

Here is the test for DDC-3346(http://www.doctrine-project.org/jira/browse/DDC-3346) issue



 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DDC-3528] [GH-1274] PersistentCollection now extends AbstractLazyCollection. Created: 21/Jan/15  Updated: 17/Mar/15  Resolved: 17/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, persistent-collection


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 22/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 01/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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





[DDC-3492] [GH-1249] Support for extra lazy get for both owning and inverse side on many to many associations. Created: 13/Jan/15  Updated: 15/Jan/15  Resolved: 15/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, extra-lazy, many-to-many

Issue Links:
Duplicate
is duplicated by DDC-2535 [GH-712] Extra lazy get for inverse s... Resolved

 Description   

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

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

Message:

Addresses #710 and #712



 Comments   
Comment by Doctrine Bot [ 15/Jan/15 ]

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

Comment by Doctrine Bot [ 15/Jan/15 ]

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





[DDC-3487] [GH-1246] [WIP] Moved delete() and update() to proper locations. Created: 12/Jan/15  Updated: 13/Jan/15  Resolved: 13/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, criteria, persister, refactoring


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 13/Jan/15 ]

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

Comment by Doctrine Bot [ 13/Jan/15 ]

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





[DDC-3430] [GH-1206] matching should not change critera Created: 04/Dec/14  Updated: 17/Jan/15  Resolved: 17/Jan/15

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Lazy Loading, ORM
Affects Version/s: Git Master, 2.4.7
Fix Version/s: 2.5
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, criteria, matching, mutability, persistent-collection


 Description   

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

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

Message:

The matching should behave like in ArrayCollection, where it is not changed.
The criteria should be cloned so that it could be used for more than one matching operation.



 Comments   
Comment by Doctrine Bot [ 15/Jan/15 ]

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

Comment by Doctrine Bot [ 17/Jan/15 ]

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





[DDC-3395] matching(Criteria::create()->orderBy()) is sorting in case insensitive manner Created: 17/Nov/14  Updated: 17/Nov/14

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

Type: Bug Priority: Minor
Reporter: Dona Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: case-sensitivity, collation, collection, criteria, sorting


 Description   

for example if we have two strings "IT" and "innovation" after sort by ASC , "IT" is coming before "Innovation".
I was expecting the arrayCollection to do a natural sort.



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

Dona this behavior may change depending on server-side collation anyway.





[DDC-3372] PersistentCollection clear function takes snapshot when the collection is cleared Created: 06/Nov/14  Updated: 27/May/15

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

Type: Bug Priority: Minor
Reporter: Ward Peeters Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: collection, orm
Environment:

Symfony 2.5.6



 Description   

I'm not sure if it's a bug or you guys have a reason why you do it. The problem occurs when you do a $coll->clear() he will clear the collection and whenever it's cleared the takeSnapshot is ran as well so our snapshot is empty so we lose the prevous state of the collection.

public function clear()
    {
        if ($this->initialized && $this->isEmpty()) {
            return;
        }

        $uow = $this->em->getUnitOfWork();

        if ($this->association['type'] & ClassMetadata::TO_MANY &&
            $this->association['orphanRemoval'] &&
            $this->owner) {
            // we need to initialize here, as orphan removal acts like implicit cascadeRemove,
            // hence for event listeners we need the objects in memory.
            $this->initialize();

            foreach ($this->coll as $element) {
                $uow->scheduleOrphanRemoval($element);
            }
        }

        $this->coll->clear();

        $this->initialized = true; // direct call, {@link initialize()} is too expensive

        if ($this->association['isOwningSide'] && $this->owner) {
            $this->changed();

            $uow->scheduleCollectionDeletion($this);

            $this->takeSnapshot();
        }
    }


 Comments   
Comment by Marco Pivetta [ 07/Nov/14 ]

Can you please abstract your problem into a test case?

Comment by Ward Peeters [ 07/Nov/14 ]

if that helps yes. The problem is that i'm not sure it's a bug. It might be the way you guys wanted it to be.
I'll create a test case might be better to understand.

Comment by Marco Pivetta [ 07/Nov/14 ]

It looks like a bug to me: the snapshot should be taken only when no snapshot was there upfront, as far as I know.

Comment by Oleg Namaka [ 27/May/15 ]

I just got bitten by the same issue. I need to have access to all elements being cleared in a collection before it gets actually cleared, but because its internal collection gets cleared before PersistentCollection is able to take a snapshot, all these elements are lost.

Comment by Oleg Namaka [ 27/May/15 ]

@Ward Peeters, have you ever created the test case in question?

Comment by Ward Peeters [ 27/May/15 ]

No i haven't will make one today if you're not doing it. I made workaround for now.





[DDC-3366] [GH-1170] Added prev to collections Created: 26/Oct/14  Updated: 13/Nov/14  Resolved: 13/Nov/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Can't Fix Votes: 0
Labels: collection, interface, iterator


 Description   

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

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

Message:

Added prev() to array collections. This is needed when you want to cycle through the array in reverse order.



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

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

Comment by Doctrine Bot [ 13/Nov/14 ]

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

Comment by Marco Pivetta [ 13/Nov/14 ]

Can't be done in 2.x





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

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

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


 Description   

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

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

Here is an example:

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

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

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

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

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

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

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

Documentation states that

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

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



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

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

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

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





[DDC-3346] findOneBy returns an object with partial collection for the properties with mapping oneToMany/Fetch Eager Created: 10/Oct/14  Updated: 28/Jan/15  Resolved: 25/Jan/15

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

Type: Bug Priority: Critical
Reporter: Adrien Russo Assignee: Marco Pivetta
Resolution: Fixed Votes: 2
Labels: collection, eager, fetch, lazy-loading, many-to-many, onetomany, persister

Issue Links:
Dependency
depends on DDC-3531 [GH-1277] [DDC-3346] Failing test for... Resolved
depends on DDC-3534 [GH-1280] [DDC-3346] #1277 find one w... Resolved

 Description   

findOneBy returns an object with partial collection for the properties with mapping oneToMany/Fetch Eager. This bug appear only for entities without inheritance.

Mapping
       
Test\Bar:
    type: entity
    table: bar
    fields:
        code:
            type: string
    oneToMany:
        posts:
            targetEntity: Test\Post
            fetch: EAGER
            mappedBy: bar
            cascade: ['all']
    
Test\Post:
    type: entity
    table: post
    fields:
        content:
            type: text
    manyToOne:
        bar:
            targetEntity: Test\Bar
            cascade: []
            joinColumn:
                name: bar_id
                referencedColumnName: id
Data
    
$bar = new \Test\Bar('foo');
$bar->addPost(
  new Test\Post('toto')
);
$bar->addPost(
  new Test\Post('tata')
);
 
$bar->getPosts()->count(); #value is 2
$manager->persist($bar);
$manager->flush();
FindOneBy with fetch eager
$bar = $repository->findOneBy(['code' => 'foo']);
$bar->getPosts()->count(); #value is 1
FindOneBy with fetch Lazy
$bar = $repository->findOneBy(['code' => 'foo']);
$bar->getPosts()->count(); #value is 2

I think this bug is due to the LIMIT 1 clause happening on findOneBy which also applies on joins generated here.

For instance, the generated SQL statement generated might look like

Sql Statement
SELECT
	t0. ID AS id_1,
	t0.code AS code_2,
	t1. ID AS id_3,
	t1.content AS content_4,
	t1.bar_id AS bar_id_5
FROM
	bar t0
LEFT JOIN post t1 ON t1.bar_id = t0. ID
WHERE
	t0. code = 'foo'
LIMIT 1


 Comments   
Comment by Pavel Batanov [ 22/Jan/15 ]

Still expiriencing it at 2.5.0-alpha (b889e18a9a15c36eac7349b06cb4b0f955a9da57). findOneBy cuts many-to-many association with fetch eager by 'LIMIT 1'

Comment by Marco Pivetta [ 22/Jan/15 ]

Pavel Batanov yeah, we don't have a fix for it yet: I suggest providing a PR with the failing test first, and if we can't get to it, trying to patch it yourself, or at least find out which code bit affects this behavior.

Comment by Pavel Batanov [ 22/Jan/15 ]

I'm finishing such PR now. Will supply it to github soon

Comment by Pavel Batanov [ 22/Jan/15 ]

here it is
https://github.com/doctrine/doctrine2/pull/1277
http://www.doctrine-project.org/jira/browse/DDC-3531

Here is the failed travis build
https://travis-ci.org/scaytrase/doctrine2/jobs/47921568

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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

Comment by Marco Pivetta [ 25/Jan/15 ]

Handled in DDC-3534

Comment by Matteo Beccati [ 28/Jan/15 ]

FYI the test is failing on: https://revive.beccati.com/bamboo/browse/PHP-DOCTR-PHP54-249/test/case/18357533

As far as I can tell from https://www.sqlite.org/lang_select.html SQLite doesn't support OFFSET w/o LIMIT.

Doctrine\Tests\ORM\Functional\Ticket\DDC3346Test::testFindWithEagerFetchAndOffsetWillNotHydrateLimitedCollection
Exception: [Doctrine\DBAL\Exception\SyntaxErrorException] An exception occurred while executing 'SELECT t0.id AS id_1, t0.username AS username_2 FROM ddc3346_users t0 WHERE t0.username = ? OFFSET 0' with params ["bwoogy"]:

SQLSTATE[HY000]: General error: 1 near "OFFSET": syntax error

With queries:
6. SQL: '"COMMIT"' Params: 
5. SQL: 'INSERT INTO ddc3346_articles (user_id) VALUES (?)' Params: '1'
4. SQL: 'INSERT INTO ddc3346_articles (user_id) VALUES (?)' Params: '1'
3. SQL: 'INSERT INTO ddc3346_users (username) VALUES (?)' Params: 'bwoogy'
2. SQL: '"START TRANSACTION"' Params: 

Trace:
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:116
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:838
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php:875
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/lib/Doctrine/ORM/EntityRepository.php:181
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC3346Test.php:53
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestCase.php:860
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestCase.php:737
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestResult.php:609
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestCase.php:693
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestSuite.php:716
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/Framework/TestSuite.php:716
/home/atlassian/bamboo/xml-data/build-dir/PHP-DOCTR-PHP54/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:398
phar:///home/atlassian/bin/phpunit.phar/phpunit/TextUI/Command.php:179
phar:///home/atlassian/bin/phpunit.phar/phpunit/TextUI/Command.php:132
/home/atlassian/bin/phpunit.phar:584
Comment by Steve Müller [ 28/Jan/15 ]

Matteo Beccati I believe this is fixed already by https://github.com/doctrine/dbal/pull/782

Comment by Matteo Beccati [ 28/Jan/15 ]

My mistake. The build wasn't cleaning up the vendor dir before running composer update, so it was still using an old dbal.





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

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

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

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



 Description   

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

The scenario is the following: I have 3 entities:

User.php
<?php

namespace Entity;

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

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

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

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

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

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

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

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

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

		return $result;
	}

}
FieldWorker.php
<?php

namespace Entity;

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

use Zend\Stdlib\Hydrator;

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

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

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

namespace Obra\Entity;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

		return $result;
	}
}

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

For example:

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

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

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

The database tables are as following:

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

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


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


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

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

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

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

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

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



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

The same problem occurs with QueryBuilder. For example:

StageRepository.php
<?php

namespace Entity;

use Doctrine\ORM\EntityRepository;

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

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

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

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

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

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

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

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

Hi Marco,

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

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

Thanks for you support

Comment by Marco Pivetta [ 31/Jul/14 ]

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

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

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

Comment by Marco Pivetta [ 31/Jul/14 ]

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

For running the test suite:

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

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

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

Thanks to all for the support





[DDC-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: 1
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-3062] [GH-997] [FIX] Allow to use ManyToMany with all operators Created: 31/Mar/14  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: collection, criteria, many-to-many, persister


 Description   

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

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

Message:

Hi,

ping @guillhermoblanco : I think this may be blocking for 2.5

I introduced not so long ago support for ManyToMany for Criteria. However, I realized my implementation was really incomplete, because I hard-coded the "=" operator (https://github.com/doctrine/doctrine2/pull/885/files#diff-982b7374bbe9d5f4b6b71f4869a446eaR575). This means that it fails in a lot of cases when you use something different than "eq" for Criteria.

This PR fixes that, however it's a bit hacky. The SqlExpressionVisitor was made by type hinting for a BasicEntityPersister, preventing us from using us for a collection persister. Therefore I added a new interface to keep BC.

There is also a lot of code duplication (the whole "getSelectConditionSQL" was copied from the BasicEntityPersister), but without trait or BC, I have no idea about how to solve it.

All tests pass, test were added for other operators.



 Comments   
Comment by Doctrine Bot [ 13/Jan/15 ]

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

Comment by Doctrine Bot [ 13/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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





[DDC-2865] [GH-882] Efficient counting on Criteria Created: 19/Dec/13  Updated: 18/Jan/15  Resolved: 16/May/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: collection, lazy-criteria-collection, lazy-loading

Issue Links:
Reference
is referenced by DDC-2217 Return a lazy collection from Persist... Resolved

 Description   

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

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

Message:

Hi,

This is an attempt to solve this very annoying issue: http://www.doctrine-project.org/jira/browse/DDC-2217

I'm not sure about my solution as I'm not really into Doctrine internals.

  1. Use case

I have a library that is based exclusively on Criteria API. A Paginator adapter uses an empty Criteria to count how many elements are in the collection. However, EntityRepository's matching method always initialize the whole collection into an ArrayCollection. This is unusable in most cases and make the API unusable for my use case.

  1. Solution

I've created a new LazyCollectionCriteria that implements an efficient count. I think the cleanest solution would be to add a method to the Selectable interface: with a count method. But I think this is not possible now, unfortunately.

If the solution seems nice to you, I'll write the tests.

ping @ocramius, @mac_nibblet and @thinkscape (this should make ZfrRest usable )



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

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





[DDC-2826] Add support for mapping collections of embeddable objects Created: 28/Nov/13  Updated: 08/Feb/14

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

Type: New Feature Priority: Major
Reporter: songoko songowan Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 2
Labels: collection, orm, value-objects


 Description   

In Hibernate we can do something like this:

    @Entity
    public class User {
       [...]
       public String getLastname() { ...}
    
       @ElementCollection
       @CollectionTable(name="Addresses", joinColumns=@JoinColumn(name="user_id"))
       @AttributeOverrides({
          @AttributeOverride(name="street1", column=@Column(name="fld_street"))
       })
       public Set<Address> getAddresses() { ... } 
    }
    
    @Embeddable
    public class Address {
       public String getStreet1() {...}
       [...]
    }

Basically a collection of value objects is mapped to a new table. Currently Doctrine2 is on its way to support value objects

However, this implementation won't support mapping a collection of objects to a new table and the only way to circumvent this issue is to treat the address an an entity and use an one-to-many unidirectional relationship through a many-to-many join table



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

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





[DDC-2552] [GH-722] Support for order by association (for 2.3 branch) Created: 15/Jul/13  Updated: 08/Nov/14  Resolved: 15/Jul/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: collection, orm
Environment:

Symfony 2.3



 Description   

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

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

Message:

I need to `@OrderBy` an association, which does not work in `2.3` but I found the pull request https://github.com/doctrine/doctrine2/pull/549 by @FabioBatSilva who has implemented this in branch `2.4`.

I have copied the code, adjusted it for `2.3` and tested it in a real life application

The original pull request is related to Doctrine Issue #2241(http://www.doctrine-project.org/jira/browse/DDC-2241).
The ordering of associations has been implemented in Doctrine Issue #195(http://www.doctrine-project.org/jira/browse/DDC-195).

Please integrate this into `2.3` because `2.4` is not stable until now and thus it is not usable for many people.



 Comments   
Comment by Doctrine Bot [ 15/Jul/13 ]

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

Comment by Christian S. [ 15/Jul/13 ]

Can be closed (see https://github.com/doctrine/doctrine2/pull/722#issuecomment-20960237)

Comment by Doctrine Bot [ 08/Nov/14 ]

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

Comment by Doctrine Bot [ 08/Nov/14 ]

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





[DDC-2535] [GH-712] Extra lazy get for inverse side of many-to-many Created: 01/Jul/13  Updated: 14/Jan/15  Resolved: 14/Jan/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: collection, extra-lazy, many-to-many

Issue Links:
Duplicate
duplicates DDC-3492 [GH-1249] Support for extra lazy get ... Resolved
Reference
relates to DDC-3130 [GH-1033] [WIP] Lazy criteria for Man... Open

 Description   

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

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

Message:

This is the cange requested by @stof and @beberlei in PR #710. It implements an extra lazy get on the working side of the relationship. As mentioned in #710 the unit tests fails for reasons I don't quite understand. The error I get is:

```
1) Doctrine\Tests\ORM\Functional\ExtraLazyCollectionTest::testGetIndexByManyToMany
Exception: [PHPUnit_Framework_Error_Notice] Undefined index: joinColumns

Trace:
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1665
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1610
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1701
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:1115
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php:746
/home/sander/src/doctrine2/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:55
/home/sander/src/doctrine2/lib/Doctrine/ORM/PersistentCollection.php:529
/home/sander/src/doctrine2/tests/Doctrine/Tests/ORM/Functional/ExtraLazyCollectionTest.php:578
```

If someone with a little more understanding of the Doctrine internals can help me fix this, then we could restore some of the functionality that PR #710 had to remove.



 Comments   
Comment by Doctrine Bot [ 05/Nov/14 ]

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

Comment by Doctrine Bot [ 13/Jan/15 ]

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

Comment by Marco Pivetta [ 14/Jan/15 ]

To be handled in DDC-3492





[DDC-2504] [GH-696] extra lazy joined test Created: 14/Jun/13  Updated: 12/Jan/15  Resolved: 12/Jan/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, extra-lazy, jti, onetomany

Issue Links:
Dependency
depends on DDC-3486 [GH-1245] Implemented support for one... Resolved

 Description   

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

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

Message:

Hi,

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

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

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



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

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

Comment by Doctrine Bot [ 19/Oct/14 ]

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

Comment by Doctrine Bot [ 12/Jan/15 ]

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

Comment by Doctrine Bot [ 12/Jan/15 ]

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

Comment by Marco Pivetta [ 12/Jan/15 ]

Handled in DDC-3486





[DDC-2303] @param wrong in Doctrine\ORM\PersistentCollection::__constructor Edit Created: 18/Feb/13  Updated: 26/Feb/13  Resolved: 26/Feb/13

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

Type: Bug Priority: Major
Reporter: Torsten Granek Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: collection

Attachments: JPEG File screenshot-1.jpg    

 Description   

When i try to generate a new PersistentCollection like this:
###############################################
$collection = new ArrayCollection();
new \Doctrine\ORM\PersistentCollection(
$this->getEntityManager(),
new ClassMetadata(''),
$collection
);
###############################################
i get an typ hinting error like
"Expected array, got "Doctrine\Common\Collections\ArrayCollection"

This could be fixed by changing the type hinting for the Doctrine\ORM\PersistentCollection::__constructor
_From:_
###############################################
/**

  • Creates a new persistent collection.
    *
  • @param EntityManager $em The EntityManager the collection will be associated with.
  • @param ClassMetadata $class The class descriptor of the entity type of this collection.
  • @param array $coll The collection elements.
    */
    public function __construct(EntityManager $em, $class, $coll)
    {
                                                                                              1. _To:_
                                                                                                ###############################################
                                                                                                /**

  • Creates a new persistent collection.
    *
  • @param EntityManager $em The EntityManager the collection will be associated with.
  • @param ClassMetadata $class The class descriptor of the entity type of this collection.
  • @param \ArrayAccess $coll The collection elements.
    */
    public function __construct(EntityManager $em, $class, $coll)
    {
    ###############################################


 Comments   
Comment by Torsten Granek [ 18/Feb/13 ]

When i try to generate a new PersistentCollection like this:


     $collection = new ArrayCollection();
     new \Doctrine\ORM\PersistentCollection(
				$this->getEntityManager(),
				new ClassMetadata(''),
				 $collection
			);

I get an typ hinting error like
"Expected array, got "Doctrine\Common\Collections\ArrayCollection"

This could be fixed by changing the type hinting for the Doctrine\ORM\PersistentCollection::__constructor
_From:_

     /**
     * Creates a new persistent collection.
     *
     * @param EntityManager $em    The EntityManager the collection will be associated with.
     * @param ClassMetadata $class The class descriptor of the entity type of this collection.
     * @param array       $coll  The collection elements.
     */
    public function __construct(EntityManager $em, $class, $coll)
    {

_To:_

     /**
     * Creates a new persistent collection.
     *
     * @param EntityManager $em    The EntityManager the collection will be associated with.
     * @param ClassMetadata $class The class descriptor of the entity type of this collection.
     * @param \ArrayAccess $coll  The collection elements.
     */
    public function __construct(EntityManager $em, $class, $coll)
    {

Comment by Christophe Coevoet [ 18/Feb/13 ]

There is no typehint in the PersistentCollection constructor. So the issue cannot come from this place (the phpdoc is wrong btw, it expects a Collection, not an array)

Please give the full error, i.e. the message and the location so that we can know where it happens.

Comment by Torsten Granek [ 20/Feb/13 ]

There error is not in the function declaration, it is in the @param in the doc block of the constructor.

Using PHPStorm as IDE i got this error thrown by the IDE it self, not php. (Screenshot will be attached)

Using ZF2 the error is on line 121 at:
vendor/doctrine/orm/lib/Doctrine/ORM/PersistentCollection.php

Comment by Torsten Granek [ 20/Feb/13 ]

Using PHPStorm as IDE i got "Expected array, got "Doctrine\Common\Collections\ArrayCollection" thrown by the IDE it self, not php.

Comment by Torsten Granek [ 20/Feb/13 ]

Using PHPStorm as IDE i got "Expected array, got "Doctrine\Common\Collections\ArrayCollection" thrown by the IDE it self, not php.

Comment by Marco Pivetta [ 26/Feb/13 ]

The correct type hint here is `Doctrine\Common\Collections\Collection`.

I'm closing this as invalid, since you shouldn't instantiate a persistent collection on your own. Consider opening a pull request at https://github.com/doctrine/doctrine2 instead if you want to fix the typehint.





[DDC-2255] [Doctrine-Bridge][Console] Entity, Getters and Setters Generating Bug detected in Symfony 2 Framework Created: 24/Jan/13  Updated: 24/Jan/13  Resolved: 24/Jan/13

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

Type: Bug Priority: Major
Reporter: Ala Eddine Khefifi Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: collection


 Description   

Bug found when generation the Entity, Getters and Setters by using the Command:

> php app/console doctrine:generate:entities YourBundleBundle:YourEntity 

In the situation you have a OneToMany relation in the Entity and you did implement the __construct(), then the Console Wont generate the ArrayCollection() !
In the case you did not implement the __construct(), then everything will goes fine when generating them,
Example:

/**
 * @ORM\OneToMany(targetEntity=" YourBundleBundle \Entity\ YourEntity ", mappedBy=" YourEntity ")
 */
private $YourAttribut;

public function __construct()
{
  $this-> YourAttribut = new \Doctrine\Common\Collections\ArrayCollection();
} 
// But in the case you did implement the __construct() before using the Command, let say like this:

public function __construct()
{
  $this-> YourOtherAttribut = a_value;
} 

In this case, when using the Command to generate Entity, Getters and Setters, the Console Wont generate the ArrayCollection() of the OneToMany relations in the __construct() !



 Comments   
Comment by Marco Pivetta [ 24/Jan/13 ]

Ala Eddine Khefifi This is expected behavior, since the generator should not change already existing methods

Comment by Ala Eddine Khefifi [ 24/Jan/13 ]

but it could override them and add missing instruction that should be added within the code, otherwise it leads to a dis-function and non stable relations !!

Comment by Marco Pivetta [ 24/Jan/13 ]

No, that is not up to the generator. Entity generation and fixing your broken existing code are different things. You should not rely on the generator to handle this kind of problems, the generator just gives you a kick-start, but after that, you are on your own.





[DDC-2220] Add joins to Collection Filtering API Created: 03/Jan/13  Updated: 11/Sep/13  Resolved: 11/Sep/13

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

Type: Improvement Priority: Major
Reporter: Oleg Namaka Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 2
Labels: api, collection, filtering


 Description   

The recently added collection filtering API only goes half way in achieving a full fledged solution to filter huge collections. It still lacks joins. Look at the next two snippets:

    $criteria = Criteria::create()
        ->where(Criteria::expr()->eq('storeId', $store->getId()))
        ->andWhere(Criteria::expr()->eq('Category', 20))
        ->orderBy(array('popularity' => 'DESC'));
    return $this->BrandCategories->matching($criteria);

This piece of code works but what if there is a need to filter the BrandCategories collection by Categories with some extra criteria:

    $criteria = Criteria::create()
        ->where(Criteria::expr()->eq('storeId', $store->getId()))
        ->andWhere(Criteria::expr()->eq('Category', 20))
        ->andWhere(Criteria::expr()->eq('Category.name', 'Electronics'))
        ->orderBy(array('popularity' => 'DESC'));
    return $this->BrandCategories->matching($criteria);

That would not work.

Ideally we should have a possibility to join other entities, the Category entity in our case here:

    $criteria = Criteria::create()
        ->where(Criteria::expr()->eq('storeId', $store->getId()))
        ->andWhere(Criteria::expr()->eq('Category', 20))
        ->innerJoin(Criteria::expr()->field('Category', 'Category'))
        ->andWhere(Criteria::expr()->eq('Category.name', 'Electronics'))
        ->orderBy(array('popularity' => 'DESC'));
    return $this->BrandCategories->matching($criteria);

What do you think about it, does it make sense to add such functionality?



 Comments   
Comment by Benjamin Eberlei [ 11/Sep/13 ]

This is not a good idea, because the API has to be small to allow many different implementations, for example the in memory implementation on ArrayCollection, or the implementaiton on MongoDB ODM.





[DDC-2217] Return a lazy collection from PersistentCollection::match($criteria) Created: 31/Dec/12  Updated: 18/Jan/15  Resolved: 16/May/14

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

Type: Improvement Priority: Major
Reporter: Christophe Coevoet Assignee: Guilherme Blanco
Resolution: Fixed Votes: 8
Labels: collection, lazy-criteria-collection, lazy-loading

Issue Links:
Reference
relates to DDC-2865 [GH-882] Efficient counting on Criteria Resolved

 Description   

In 2.3, PersistentCollection::match() has been implemented by doing the query directly. But sometimes, the only meaningful information about the matched collection would be its length. In this case, it would be great to handle it in the same way than extra lazy collections are handled: the matched collection would be initialized lazily, and could do the count in an extra lazy way (if the original collection was extra lazy).
This would of course not change anything in the case where the original collection was already initialized.



 Comments   
Comment by Maciej Klemarczyk [ 20/Sep/13 ]

It will be very usefull, for example to compute count of rows.

In 300 rows, you do not want fetch data from database to compute length of this.

Function matching(Criteria $criteria) fetch too many data for just compute count of rows.

Comment by Christophe Coevoet [ 21/Sep/13 ]

This is exactly the use case I add in mind actually

Comment by Michaël Gallego [ 12/Oct/13 ]

+1 on this one! This is absolutely needed when we use the Selectable API as the abstraction for some libraries.





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

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

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


 Description   

Available documentation is a bit thin regarding the "WITH" clause on JOIN expressions. Only a single example is provided in

http://docs.doctrine-project.org/en/2.1/reference/dql-doctrine-query-language.html#dql-select-examples

WITH seems to allow to only "partially" load a collection, so the collection in memory does not fully represent the associations available in the database.

The resulting collection is marked as "initialized" and it seems there is no way to tell later on whether/how (with which expression) the collection has been initialized.

When using the collection filtering API, the "initialized" flag on the collection will lead to in-memory processing. If a collection has been loaded WITH a restricting clause and another filter is applied later, results may not be what one might expect.

I assume this is by design (no idea how the collection could be "partially" loaded and behave correctly under all conditions), so filing it as a documentation issue.



 Comments   
Comment by Matthias Pigulla [ 17/Dec/12 ]

An additional observation:

If you eager-load a collection using WITH, for the resulting entities that collection is marked as initialized as described above.

Should you happen to come across the same entity during hydration in another (later) context where you explicitly eager load the same association without the WITH restriction (or with another one), the collection on that (existing) entity won't be re-initialized and still contains the associated objects found during the first query.





Generated at Sun Aug 02 04:20:42 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.