[DCOM-47] When using different class loaders Created: 07/Apr/11  Updated: 27/Dec/11  Resolved: 14/Sep/11

Status: Resolved
Project: Doctrine Common
Component/s: Class Loading
Affects Version/s: 2.1
Fix Version/s: 2.1.2

Type: Bug Priority: Major
Reporter: Gediminas Morkevicius Assignee: Guilherme Blanco
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

all



 Description   

ClassLoader::classExists($class); will fail if different class loader is used which does not return any boolean value. This includes Symfony2 UniversalClassLoader

I have never used this function before because native PHP method class_exits($class, true) first will try to autoload. But if the class does not exist
and you are using Doctrine\Common::ClassLoader and you call class_exists($class) it will trigger fatal error. This behavior makes it impossible to make code compatible
with different class loading mechanisms for Doctrine2



 Comments   
Comment by Christophe Coevoet [ 07/Apr/11 ]

This is known and documented in the code: https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Annotations/Parser.php#L110

Comment by Guilherme Blanco [ 14/Sep/11 ]

Since Annotations package changed a lot since the bug was opened and today, I'm closing the ticket as "Cannot reproduce".

Please reopen it if the issue is still valid with a testcase.

Cheers,

Comment by Benjamin Eberlei [ 27/Dec/11 ]

This issue is referenced in Github Pull-Request GH-88
https://github.com/doctrine/common/pull/88

Comment by Jan Dolecek [ 27/Dec/11 ]

Still a problem! Especially since this is used by ORM (https://github.com/doctrine/doctrine2/commit/3aea203b9ca77df65f55f036080a9af653194cbf)

Class loader doesn't have to return bool (and usually DOES NOT), so even though it has loaded the class, classExists will return false. Please pull this https://github.com/doctrine/common/pull/88

Comment by Benjamin Eberlei [ 27/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/common/pull/88





[DCOM-68] Add @codeCoverageIgnoreStart and @codeCoverageIgnoreEnd to annotation ignore map Created: 25/Sep/11  Updated: 25/Sep/11  Resolved: 25/Sep/11

Status: Resolved
Project: Doctrine Common
Component/s: None
Affects Version/s: 2.1.1
Fix Version/s: 2.1.2

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


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

Done





[DCOM-62] Github-PR-53 by shawndellysse: ArrayCollection#join Created: 21/Aug/11  Updated: 14/Sep/11  Resolved: 14/Sep/11

Status: Resolved
Project: Doctrine Common
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.2

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

{username}

:

Url: https://github.com/doctrine/common/pull/53

Message:

Added the `join` method to `ArrayCollection`.



 Comments   
Comment by Guilherme Blanco [ 14/Sep/11 ]

This can't be easily implemented by ORM because join() would require more than a single delimiter.
Marking ticket as won't fix. If you have a better solution, please reopen the issue with more details about how would you like to achieve it.





[DCOM-40] Using shared references with the SharedFixtureInterface with the DataFixtures extension will not work. Created: 06/Mar/11  Updated: 14/Sep/11  Resolved: 14/Sep/11

Status: Resolved
Project: Doctrine Common
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.2

Type: Bug Priority: Major
Reporter: Steven Rosato Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: None

Attachments: Text File 0001-DCOM-40-Fixed-an-issue-where-shared-fixtures-where-n.patch    

 Description   

I did not know where to issue that component, but since this extension using the Doctrine Common namespace I thought it relevant to issue the bug here.

Consider the following shared fixures (as stated on jwage's github repo here: https://github.com/doctrine/data-fixtures)

In case if fixture objects have relations to other fixtures, it is now possible to easily add a reference to that object by name and later reference it to form a relation. Here is an example fixtures for Role and User relation

namespace MyDataFixtures;

use Doctrine\Common\DataFixtures\AbstractFixture;

class LoadUserRoleData extends AbstractFixture
{
    public function load($manager)
    {
        $adminRole = new Role();
        $adminRole->setName('admin');

        $anonymousRole = new Role;
        $anonymousRole->setName('anonymous');

        $manager->persist($adminRole);
        $manager->persist($anonymousRole);
        $manager->flush();

        // store reference to admin role for User relation to Role
        $this->addReference('admin-role', $adminRole);
    }
}

namespace MyDataFixtures;

use Doctrine\Common\DataFixtures\AbstractFixture;

class LoadUserData extends AbstractFixture
{
    public function load($manager)
    {
        $user = new User();
        $user->setUsername('jwage');
        $user->setPassword('test');
        $user->setRole(
            $this->getReference('admin-role') // load the stored reference
        );

        $manager->persist($user);
        $manager->flush();

        // store reference of admin-user for other Fixtures
        $this->addReference('admin-user', $user);
    }
}

This will not use the last reference as a MANAGED entity but whether as a NEW one since the manager gets cleared (thus the unit of work) on each call to load() for the AbstractExecutor and thus marking any new references to the 'admin-user' considered a NEW entity, which should not be the case.

The current workaround is to directly fetch the entity using the EM's find() function, but that completely eliminates the main goal SharedFixtures' references are bringing.

I have provided the small patch that adress this issue, tests still pass.



 Comments   
Comment by Steven Rosato [ 06/Mar/11 ]

Added patch that addresses the issue.

Comment by Guilherme Blanco [ 14/Sep/11 ]

Not related to Common package (do we have a project for that?), but it seems this issue was already addressed when I looked at data-fixture repository.
https://github.com/doctrine/data-fixtures/blob/master/lib/Doctrine/Common/DataFixtures/Executor/AbstractExecutor.php#L79

Closing as fixed.





[DCOM-37] orm:convert-d1-schema not working Created: 22/Feb/11  Updated: 14/Sep/11  Resolved: 14/Sep/11

Status: Resolved
Project: Doctrine Common
Component/s: None
Affects Version/s: 2.0.1
Fix Version/s: 2.1.2

Type: Bug Priority: Minor
Reporter: Jon Johnson Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None
Environment:

Ubuntu 10.04 PEAR install of DoctrineORM



 Description   

orm:convert-d1-schema ~/schema.yml yml ~/newyml returns The helper "em" is not defined



 Comments   
Comment by Guilherme Blanco [ 14/Sep/11 ]

You are not providing the EntityManagerHelper to Symfony Console.

Marking as invalid. Please reopen if you have already addressed that and issue is still valid.





[DCOM-57] Doctrine\Common\Cache\AbstractCache::deleteAll() does not take the namespace into account Created: 14/Jul/11  Updated: 08/Sep/11  Resolved: 27/Aug/11

Status: Resolved
Project: Doctrine Common
Component/s: Caching
Affects Version/s: 2.1
Fix Version/s: 2.1.2

Type: Bug Priority: Major
Reporter: Eric Durand-Tremblay Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Memcached



 Description   

The deleteAll() function delete all keys with no respect of the namespace.

Using orm:clear-cache:metadata with memcache result in the deletion of all memcache keys. (including keys unrelated to the orm)



 Comments   
Comment by Eric Durand-Tremblay [ 14/Jul/11 ]

See pull request : https://github.com/doctrine/common/pull/46

I think the best way to fix this problem is to check for the namespace in the getIds() function.

Unfortunately, that would break the interface of AbstractCache

Split the function in getIds() and abstract _getIds(). Do the namespace check in getIds()

I can do pull request on github if necessary.

NOTE
I checked on master branch and the probleme is not fixed by commit
786deeae264ae03061d6aa92c681afa4344f18b9 : Fixed AbstractCache where delete* functions were incorrectly being prepended by namespace if any is defined. This was causing a double p

Comment by Guilherme Blanco [ 27/Aug/11 ]

Fixed in master since this commit: https://github.com/doctrine/common/commit/486169851ea87b3e14ed45d5bfd7d07b1d41af65

Comment by Benjamin Eberlei [ 08/Sep/11 ]

Merged into 2.1.x for next release





Generated at Sat Jul 26 17:25:18 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.