[DCOM-173] Add test assets and tests for proxy generators Created: 18/Feb/13  Updated: 21/Feb/13  Due: 18/Feb/13  Resolved: 21/Feb/13

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

Type: Bug Priority: Blocker
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

Need to add tests assets to check __isset __get __set, etc. Currently only code generation for proxies inheriting __sleep is tested.



 Comments   
Comment by Marco Pivetta [ 18/Feb/13 ]

See https://github.com/doctrine/common/pull/255

Comment by Marco Pivetta [ 21/Feb/13 ]

Merged





[DCOM-84] Improve Proxy Naming Created: 01/Dec/11  Updated: 13/Dec/11  Resolved: 12/Dec/11

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

Type: Improvement Priority: Blocker
Reporter: Johannes Schmitt Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

see https://gist.github.com/b493493ecdb22c21590e



 Comments   
Comment by Benjamin Eberlei [ 12/Dec/11 ]

Implemented in https://github.com/doctrine/common/pull/83

Comment by Benjamin Eberlei [ 13/Dec/11 ]

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





[DCOM-61] Class annotation is not setting annotation properties Created: 18/Aug/11  Updated: 25/Aug/11  Resolved: 25/Aug/11

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

Type: Bug Priority: Blocker
Reporter: James Reed Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Windows 7 64-bit, PHP v5.3.1



 Description   

My annotations were working fine with v2.0.5. Once I upgraded to v2.1 they stopped working. Using this condensed code based on the v2.1 documentation on Annotations (http://www.doctrine-project.org/docs/common/2.1/en/reference/annotations.html):

require 'c:/dev/library/doctrine-orm/Doctrine/Common/ClassLoader.php';

$classLoader = new \Doctrine\Common\ClassLoader('Doctrine', 'c:/dev/library/doctrine-orm');
$classLoader->register();
$classLoader = new \Doctrine\Common\ClassLoader('Symfony', 'c:/dev/library/doctrine-orm/Doctrine');
$classLoader->register();

$reader = new \Doctrine\Common\Annotations\AnnotationReader();
$reader->setIgnoreNotImportedAnnotations(true);
$reader->setEnableParsePhpImports(false);
$className = 'User';
$reflectionClass = new \ReflectionClass($className);

$classAnnotations = $reader->getClassAnnotations($reflectionClass);
echo "Class Annotations - $className:\n";
print_r($classAnnotations);

/**
* @Annotation
*/
class Foo {
    public $bar;
}

/**
* @Foo(bar="foo")
*/
class User {
    
}

The result is:

Class Annotations - User:
Array
(
    [0] => Foo Object
        (
            [bar] =>
        )

)

Why is bar empty? If I remove the @Foo annotation from the docblock for the User class, then the result is an empty array. So it's clearly detecting the annotation, it's just not setting the annotation property.



 Comments   
Comment by James Reed [ 25/Aug/11 ]

This is blocking me from upgrading to v2.1

Comment by James Reed [ 25/Aug/11 ]

Got the same result with v2.0.6. Must be something I'm missing here.





[DCOM-242] [GH-322] 2.4 do not serialize static properties Created: 21/May/14  Updated: 21/May/14  Resolved: 21/May/14

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

Type: Task Priority: Blocker
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: None


 Description   

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

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

Message:

The master branch does not serialize static properties, 2.4 does.

When we upgraded to Doctrine ORM 2.4 the proxy generation was moved to Doctrine Common (I think) and subsequently all the proxy entities which has static properties caused errors on __sleep



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

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





[DCOM-194] Creating Proxy class failure for own __get method Created: 22/May/13  Updated: 08/Sep/13  Resolved: 10/Jun/13

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

Type: Bug Priority: Critical
Reporter: Jan Pecek Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: proxy
Environment:

using Nette framework ( http://nette.org ), PHP 5.4



 Description   

Nette framework (http://nette.org) has got own Nette\Object as a base of other objects. It also rewrite the default __get method in PHP object but it uses definition with pointer:

public function &__get($name)

Doctrine Common creates Proxy classes with __get method too but not with reference. It causes an error using strict warning:

Declaration of Proxy\__CG__\MyEntityObject::__get() should be compatible with & Nette\Object::__get($name)

The problem is in ProxyGenerator. Locally I've patched it in my Doctrine repository clone but don't know how to resolve it globally.



 Comments   
Comment by Marco Pivetta [ 22/May/13 ]

https://github.com/doctrine/common/blob/2.4.0-RC2/lib/Doctrine/Common/Proxy/ProxyGenerator.php#L386-L403 could be patched to verify if the method is byref/byval.

Comment by Christophe Coevoet [ 03/Jun/13 ]

This should probably be checked for all proxied methods, not only for magic ones

Comment by Marco Pivetta [ 03/Jun/13 ]

Christophe Coevoet I think I already check proxied methods, but didn't apply that logic for magic methods.

edit: indeed, there's a test for that: https://github.com/doctrine/common/blob/2.4.0-RC3/tests/Doctrine/Tests/Common/Proxy/LazyLoadableObject.php#L101-L106

Comment by Michael Moravec [ 06/Jun/13 ]

Hello, I've patched ProxyGenerator::generateMagicGet method to support reference, see Github PR #278.
Jan Pecek, could you confirm it fixes the problem?

Comment by Jan Pecek [ 06/Jun/13 ]

Michael Moravec: Yes, this is ok. Now, proxy classes are generated well.

Comment by Marco Pivetta [ 10/Jun/13 ]

Cleaned and re-submitted at https://github.com/doctrine/common/pull/281

Please review and then I'll merge.

Comment by Marco Pivetta [ 10/Jun/13 ]

Merged at https://github.com/doctrine/common/commit/d658ec7a03f6475eff0dd1eb940bdedd862e4b96





[DCOM-69] [APC Cache] doFlush does not clear user cache Created: 27/Sep/11  Updated: 03/Oct/11  Resolved: 03/Oct/11

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

Type: Bug Priority: Critical
Reporter: Jérôme Forêt Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

lib\Doctrine\Common\Cache\ApcCache.php

The function "doFlush" only clears opcode cache.
The user cache is never cleared.

To correct it, one solution should be :

protected function doFlush()
{
    $res = false;    
    $bool1 = apc_clear_cache();
    $bool2 = apc_clear_cache('user');
    if ($bool1 && $bool2)
    {
        $res = true;
    }
    return $res;
}


 Comments   
Comment by Guilherme Blanco [ 03/Oct/11 ]

Fixed in https://github.com/doctrine/common/commit/d6e4c8b22af9800db4fd9d679ce98538da028168





[DCOM-27] Method Next from ArrayCollection needs to return something! Created: 11/Oct/10  Updated: 31/Oct/10  Resolved: 31/Oct/10

Status: Resolved
Project: Doctrine Common
Component/s: Collections
Affects Version/s: 2.0.0-RC1
Fix Version/s: 2.0.0-RC2

Type: Bug Priority: Critical
Reporter: Henrique Girardi dos Santos Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

I think this method needs to return something...

/**

  • Moves the internal iterator position to the next element.
    *
  • @return mixed
    */
    public function next() { next($this->_elements); }

doctrine-common/lib/Doctrine/Common/Collections/ArrayCollection.php



 Comments   
Comment by Benjamin Eberlei [ 31/Oct/10 ]

resolved





[DCOM-25] method setAutoloadAnnotationClasses-fails Created: 25/Sep/10  Updated: 31/Oct/10  Resolved: 31/Oct/10

Status: Resolved
Project: Doctrine Common
Component/s: Annotations
Affects Version/s: 2.0.0-RC1
Fix Version/s: 2.0.0-RC2

Type: Bug Priority: Critical
Reporter: Margus Sipria Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

$reader = new Doctrine\Common\Annotations\AnnotationReader();
$reader->setAutoloadAnnotationClasses(true);

above code is trying use default parser's setAutoloadAnnotationClasses-method, which isn't found, instead parser has setAutoloadAnnotations.



 Comments   
Comment by Benjamin Eberlei [ 31/Oct/10 ]

fixed.





[DCOM-240] FileCacheReader requires write access, even when it isn't writing Created: 16/Apr/14  Updated: 16/Apr/14  Resolved: 16/Apr/14

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

Type: Bug Priority: Major
Reporter: Chris Sedlmayr Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: cache


 Description   

Within the constructor of Doctrine\Common\Annotations\FileCacheReader, it checks if the $cacheDir is writable, and if not, it throws an exception.
As this class performs read and write operations, it makes sense to only perform that check when it needs to write, maybe as part of the saveCacheFile method.

We are warming all parts of our cache during application build process, so on production servers we have no writable directories, this code means that can't happen.



 Comments   
Comment by Chris Sedlmayr [ 16/Apr/14 ]

Fixed by https://github.com/doctrine/annotations/pull/30





[DCOM-236] @Target isn't properly bitmasked Created: 03/Mar/14  Updated: 03/Mar/14  Resolved: 03/Mar/14

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

Type: Bug Priority: Major
Reporter: Joshua Thijssen Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

The @target annotation can be used for adding annotation-targets. However, adding multiple targets results in unwanted behaviour, as the targets aren't OR'ed together, but simply added.

For instance: @target(

{METHOD, METHOD}

) results in an annotation that can only be added to properties (2 + 2 = 4), instead of the wanted 2, and other weirdness.



 Comments   
Comment by Marco Pivetta [ 03/Mar/14 ]

Merged: https://github.com/doctrine/annotations/commit/c1a38760a6cfeec627ed66f9192db2acce1cb9e0

Note: no assigned fix version since doctrine/annotation versioning diverges from doctrine/common versioning.

Likely fixed with doctrine/annotations:1.1.3





[DCOM-235] [GH-317] Implemented an ObjectPersisterInterface for entity/object storage Created: 21/Feb/14  Updated: 24/Feb/14  Resolved: 24/Feb/14

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

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

Issue Links:
Duplicate
is duplicated by DDC-2994 [GH-959] Implemented an ObjectPersist... Resolved

 Description   

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

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

Message:

      1. Why is this useful?
        Instead of using the ```repositoryClass```, we use 'Repository as a Service'. This means that we inject our repository service instead of doing ```$em->getRepository('MyEntity')```, this provides typehinting and autocomplete in IDEs. This introduces a minor inconvenience, we need to inject an ```EntityManagerInterface``` to provide persist/flush. We don't want the entire ```EntityManagerInterface``` capabilities just to store an object.

Using the ```ObjectPersisterInterface``` we can "hide" the ```EntityManagerInterface``` and only let the code know we have the persist and flush methods available. By default this is implemented on the ```EntityManager```, but is also possible to be mocked or replaced by a custom implementation (rotating entity managers?).

        1. Example
          ``` php

class MyService
{
private $op;
private $es;

public function __construct(ObjectPersisterInterface $op, MyEntityService $es)

{ $this->op = $op; $this->es = $es; }

public function doSomething($value)

{ $entity = $this->es->findByValue($value)->setValue('something'); $this->op->flush(); }

public function doSomethingElse()

{ $entity = new MyEntity(); $this->op->persist($entity); $this->op->flush(); }

}

```



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

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





[DCOM-228] [GH-312] Improve UnexpectedValueException error message Created: 19/Dec/13  Updated: 19/Dec/13  Resolved: 19/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

UnexpectedValueException::proxyDirectoryNotWritable() provides
information as to which directory was unwritable.



 Comments   
Comment by Doctrine Bot [ 19/Dec/13 ]

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

Comment by Marco Pivetta [ 19/Dec/13 ]

Merged: https://github.com/doctrine/common/commit/a4e2629e0a3ab57e4a70fa49ec556a44414ffb27





[DCOM-223] [GH-308] fix the optimize regex and adapt the tests to actually test classAnnotat... Created: 12/Dec/13  Updated: 12/Jan/14  Resolved: 12/Jan/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

There has been several problems

  • Even we enabled classAnnotationOptimized we expected a different behavior: You cannot parse properties any longer (fixed that by expecting an exception). Therefore moved the test data into a provider so you can check the exception on each of them.
  • Once done I realized that DeeperNamespaceParent had the wrong className
  • Additional I added a test to check that the regex matched.


 Comments   
Comment by Doctrine Bot [ 12/Jan/14 ]

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

Comment by Marco Pivetta [ 12/Jan/14 ]

Merged: https://github.com/doctrine/common/commit/a45d110f71c323e29f41eb0696fa230e3fa1b1b5





[DCOM-222] [GH-306] DCOM-162 - Returning the dumped value in `Doctrine\Common\Util\Debug::dump()` Created: 03/Dec/13  Updated: 03/Dec/13  Resolved: 03/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

This is a replacement for DCOM-162 (issue #244) - rebased and cleaned



 Comments   
Comment by Marco Pivetta [ 03/Dec/13 ]

Duplicate of DCOM-162

Comment by Doctrine Bot [ 03/Dec/13 ]

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





[DCOM-220] [GH-304] fix typo Created: 19/Nov/13  Updated: 19/Nov/13  Resolved: 19/Nov/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



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

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





[DCOM-219] [GH-301] fix hasPublicMethod implementations for abstract functions in ReflectionService Created: 10/Oct/13  Updated: 03/Feb/14  Resolved: 03/Feb/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Since php >=5.4.8 the method is_callable returns false for
abstract functions. As the documentation for the
hasPublicMethod method states that it is sufficient
for the class to have a public method with that name it���s
not necessary to check whether the method is abstract or not.

The mentioned method is currently used in the doctrine2-orm
project where it helps with the validation of lifecycle callbacks.
As lifecycle callbacks must be callable but considering the fact
that abstract functions can only be used in abstract classes it
should be OK to rely on php for the assumption that the method
is in fact not abstract when it is called because php would be
unable to instantiate abstract classes.

this fixes DDC-2708.

there are currently no tests in this pull request. i���d volunteer for writing one or two (one for common, one for orm) but i would like to talk to someone first .



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

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





[DCOM-218] [GH-299] Allow root namespaces for Entities Created: 19/Sep/13  Updated: 03/Dec/13  Resolved: 03/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Allow root namespaces for entities to be "valid" since a prefix in symfony2 cannot be empty.



 Comments   
Comment by Doctrine Bot [ 20/Sep/13 ]

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





[DCOM-216] [GH-298] Silence E_NOTICE warning: "Undefined index". Created: 16/Sep/13  Updated: 16/Sep/13  Resolved: 16/Sep/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DCOM-217 Merge DCOM-216 into 2.4.x Sub-task Resolved Guilherme Blanco  

 Description   

This issue is created automatically through a Github pull request on behalf of fredrik-w:

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

Message:

Running PHP with error reporting on for E_NOTICE this bit me. Fix is simple and straightforward, check if key is defined and use that value if so, otherwise use null.



 Comments   
Comment by Doctrine Bot [ 16/Sep/13 ]

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

Comment by Marco Pivetta [ 16/Sep/13 ]

Merged: https://github.com/doctrine/common/commit/d9dea98243c733ff589aab10e321de4f14a63ab4





[DCOM-212] [GH-296] Proxies shouldn't serialize static properties in __sleep() Created: 11/Sep/13  Updated: 11/Sep/13  Resolved: 11/Sep/13

Status: Resolved
Project: Doctrine Common
Component/s: None
Affects Version/s: 2.4, 2.4.1
Fix Version/s: 2.5.0

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: proxy

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DCOM-213 Merge DCOM-212 back into 2.4.x Sub-task Resolved Guilherme Blanco  

 Description   

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

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

Message:

This PR contains a test and a fix for the following bug: Proxies did serialize static properties.

I believe this is a regression in 2.4 since I've never met this bug before.

Given the class:

class StaticPropertyClass
{
    protected static $protectedStaticProperty;
}

Before the fix, proxies would contain the following `__sleep` method:

    public function __sleep()
    {
        if ($this->__isInitialized__) {
            return array('__isInitialized__', 'protectedStaticProperty');
        }

        return array('__isInitialized__', 'protectedStaticProperty');
    }

With the fix:

    public function __sleep()
    {
        if ($this->__isInitialized__) {
            return array('__isInitialized__');
        }

        return array('__isInitialized__');
    }


 Comments   
Comment by Doctrine Bot [ 11/Sep/13 ]

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

Comment by Marco Pivetta [ 11/Sep/13 ]

Merged: https://github.com/doctrine/common/commit/4233262c8a94b2f22189ce3e5972dae25aa6764b





[DCOM-211] [GH-295] Patch to support entity's static property. Created: 01/Sep/13  Updated: 01/Sep/13  Resolved: 01/Sep/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Entity contains association mapping have trouble to debug with dumping object (entity) because association field will invoke proxy entity, in additional the association field can make as static and static can solve in this case. This patch make to support static member of the fields.

This pull to review.



 Comments   
Comment by Doctrine Bot [ 01/Sep/13 ]

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





[DCOM-208] [GH-290] Fixed html_errors overwriting Created: 17/Aug/13  Updated: 17/Aug/13  Resolved: 17/Aug/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

html_errors configuration option is being overwritten instead of switched on temporarily.
Especially annoying when using xdebug extension which relies on html_errors
>By default Xdebug overloads var_dump() with its own improved version for displaying variables when the html_errors php.ini setting is set to 1.



 Comments   
Comment by Doctrine Bot [ 17/Aug/13 ]

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

Comment by Marco Pivetta [ 17/Aug/13 ]

Merged: https://github.com/doctrine/common/commit/f28a39065d455b6df1c989ea6590e971a1f0256d





[DCOM-210] ProxyFactory: Modes for NEVER, FILE_NOT_EXISTS, ALWAYS Created: 07/Aug/13  Updated: 09/Sep/13  Resolved: 25/Aug/13

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

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


 Comments   
Comment by Marco Pivetta [ 25/Aug/13 ]

Implemented in https://github.com/doctrine/common/pull/291 - ( DCOM-209 )

Comment by Matthieu Napoli [ 09/Sep/13 ]

Any docs?

It seems that it can't be used with Doctrine\ORM\Configuration

Comment by Marco Pivetta [ 09/Sep/13 ]

I think this should work in v2.4.0: see https://github.com/doctrine/doctrine2/blob/v2.4.0/lib/Doctrine/ORM/EntityManager.php#L163

I'll open an issue to document these new flags

Comment by Marco Pivetta [ 09/Sep/13 ]

Created DDC-2664

Comment by Matthieu Napoli [ 09/Sep/13 ]

Actually found it, it's not documented and not really foolproof:

$doctrineConfig = new Doctrine\ORM\Configuration();
$doctrineConfig->setAutoGenerateProxyClasses(AbstractProxyFactory::AUTOGENERATE_EVAL);

However it will not work if the proxy autoloader is registered (which was necessary before, so if you forget to remove it, you'll get confusing errors that the proxy file can't be found), and you need to set a proxy dir else there's an exception:

exception 'Doctrine\Common\Proxy\Exception\InvalidArgumentException' with message 'You must configure a proxy directory. See docs for details'
$doctrineConfig->setProxyDir('/tmp/proxies');

The docs needs updating, both in code and on the website. If I find some time today I'll try to do it.

Comment by Matthieu Napoli [ 09/Sep/13 ]

Woops, commented at the same time, will copy my comment to the other ticket for better tracking.

Comment by Doctrine Bot [ 09/Sep/13 ]

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

Comment by Doctrine Bot [ 09/Sep/13 ]

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





[DCOM-202] [GH-285] Fixed getting wrong manager with getManagerForClass() when using multipl... Created: 20/Jun/13  Updated: 22/Dec/13  Resolved: 20/Jun/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

...e document managers

Please reply if an example is needed



 Comments   
Comment by Doctrine Bot [ 20/Jun/13 ]

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

Comment by Doctrine Bot [ 22/Dec/13 ]

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





[DCOM-204] AnnotationDriver cannot find classes inside Phar files Created: 25/Jun/13  Updated: 03/Feb/14  Resolved: 03/Feb/14

Status: Resolved
Project: Doctrine Common
Component/s: Annotations
Affects Version/s: 2.3
Fix Version/s: 2.4.2

Type: Bug Priority: Major
Reporter: Johan Groth Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

If an application is packaged inside a Phar file, the annotation driver cannot find any classes. The problem is in the method AnnotationDriver::getAllClassNames()

AnnotationDriver.php
 
foreach ($iterator as $file) {
    $sourceFile = realpath($file[0]);

    require_once $sourceFile;

    $includedFiles[] = $sourceFile;
}

$iterator will hold all paths to the files found, however realpath() will return false since the files are inside a phar file.

I have solved this locally in my application with the following, however I'm not sure if this is the right approach to solve the problem.

AnnotationDriver.php
$sourceFile = str_replace('\\', '/', $file[0]);
if (!preg_match('#^phar://#i', $sourceFile)) {
    $sourceFile = realpath($sourceFile);
}





[DCOM-201] [GH-284] Adding failing test demonstrating DCOM-175 Created: 19/Jun/13  Updated: 30/Jul/13  Resolved: 19/Jun/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

Private properties of parent classes are not serialized correctly, therefore PHP throws a notice during serialization



 Comments   
Comment by Marco Pivetta [ 19/Jun/13 ]

Duplicate of DCOM-175

Comment by Doctrine Bot [ 30/Jul/13 ]

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





[DCOM-200] [GH-283] Add a test on the ReflexionClass to call implementsInterface on an interface Created: 18/Jun/13  Updated: 03/Dec/13  Resolved: 03/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 03/Dec/13 ]

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





[DCOM-199] [GH-282] Fixing failing test Created: 11/Jun/13  Updated: 03/Dec/13  Resolved: 03/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

This fix https://github.com/doctrine/common/commit/a111f1c18d833d4c7a12a3ea059a022f5363e188 for 2.2 branch



 Comments   
Comment by Doctrine Bot [ 18/Aug/13 ]

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





[DCOM-195] [GH-277] graceful classloader Created: 04/Jun/13  Updated: 03/Dec/13  Resolved: 03/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of Tim-Erwin:

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

Message:

Right now if the Doctrine class loader is asked to load a class that it is actually not responsible for (because my class loader is later in the list) it fails with a fatal error. This patch only requires a file if it exists. Other class loaders in the list can still try to load the class.



 Comments   
Comment by Doctrine Bot [ 20/Aug/13 ]

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





[DCOM-193] [GH-275] Improve code to throw exception getting parents class instead of php warning Created: 09/May/13  Updated: 09/May/13  Resolved: 09/May/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Related to https://github.com/doctrine/common/pull/274



 Comments   
Comment by Doctrine Bot [ 09/May/13 ]

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





[DCOM-190] [GH-273] Added visibility in the methods Interfaces Created: 06/May/13  Updated: 08/Sep/13  Resolved: 21/May/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

This adjustment aims to bring to the default PSR2.
I see more alerts and warnings this is only a part.

Thanks,
Ramon



 Comments   
Comment by Doctrine Bot [ 21/May/13 ]

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

Comment by Marco Pivetta [ 21/May/13 ]

merged





[DCOM-188] [GH-272] MappingDriverChain: the default driver wasn't called for getAllClassNames() Created: 16/Apr/13  Updated: 08/Sep/13  Resolved: 16/Apr/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

`MappingDriverChain::getAllClassNames()` would call and merge sub-drivers `getAllClassNames()` results, but not for the default driver.

I added a test that reproduced the problem, and then fixed it.



 Comments   
Comment by Doctrine Bot [ 16/Apr/13 ]

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

Comment by Marco Pivetta [ 16/Apr/13 ]

Merged





[DCOM-187] [GH-270] Allow empty arrays in annotations Created: 29/Mar/13  Updated: 03/Dec/13  Resolved: 03/Dec/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

an empty array so far is impossible as it either results in a parse error if you just do the obvious {} or if you try

{""}

it will create an empty entry which in turn will cause errors depending on the annotation.



 Comments   
Comment by Doctrine Bot [ 20/Aug/13 ]

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

Comment by Marco Pivetta [ 03/Dec/13 ]

Won't be fixed in 2.3 - master already has the fix in doctrine/annotations





[DCOM-183] [GH-262] Fixed travis build Created: 11/Mar/13  Updated: 08/Sep/13  Resolved: 11/Mar/13

Status: Resolved
Project: Doctrine Common
Component/s: None
Affects Version/s: None
Fix Version/s: 2.3, 2.4

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


 Description   

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

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

Message:

since composer/composer#1005 composer updates --dev by default.



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

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





[DCOM-182] [GH-261] Fixed typos Created: 11/Mar/13  Updated: 08/Sep/13  Resolved: 11/Mar/13

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

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


 Description   

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

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

Message:



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

A related Github Pull-Request [GH-261] was opened
https://github.com/doctrine/common/pull/261

Comment by Benjamin Eberlei [ 11/Mar/13 ]

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





[DCOM-181] [GH-260] Hotfix/issue #259 Created: 07/Mar/13  Updated: 08/Sep/13  Resolved: 08/Mar/13

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

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


 Description   

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

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

Message:

Hotfix for doctrine/common#259



 Comments   
Comment by Benjamin Eberlei [ 07/Mar/13 ]

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





[DCOM-172] [GH-254] Update lib/Doctrine/Common/Proxy/ProxyGenerator.php Created: 18/Feb/13  Updated: 08/Sep/13  Resolved: 19/Feb/13

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

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


 Description   

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

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

Message:

Added missed semicolon



 Comments   
Comment by Benjamin Eberlei [ 18/Feb/13 ]

A related Github Pull-Request [GH-254] was opened
https://github.com/doctrine/common/pull/254

Comment by Benjamin Eberlei [ 18/Feb/13 ]

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

Comment by Marco Pivetta [ 19/Feb/13 ]

Continuing in DCOM-173

Comment by Benjamin Eberlei [ 19/Feb/13 ]

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





[DCOM-171] [GH-253] Proxy Generation Bug Created: 16/Feb/13  Updated: 08/Sep/13  Resolved: 16/Feb/13

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

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


 Description   

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

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

Message:

Added missing semi colon and removed backslashes previously used to escape function arguments



 Comments   
Comment by Benjamin Eberlei [ 16/Feb/13 ]

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





[DCOM-170] [GH-250] Adding export attributes Created: 27/Jan/13  Updated: 16/Apr/13  Resolved: 16/Apr/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 16/Apr/13 ]

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

Comment by Marco Pivetta [ 16/Apr/13 ]

No good positive feedback - no need to force it in





[DCOM-167] [GH-248] Hotfix/doctrine/common#247 fixes Created: 26/Jan/13  Updated: 21/Dec/13  Resolved: 26/Jan/13

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

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


 Description   

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

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

Message:

Includes fixes suggested for #247 (plus a weird fix on a failure with `array_map` on PHP <5.4)



 Comments   
Comment by Benjamin Eberlei [ 26/Jan/13 ]

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

Comment by Doctrine Bot [ 21/Dec/13 ]

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





[DCOM-169] [GH-249] Namespaced the PR246 test case Created: 27/Jan/13  Updated: 08/Sep/13  Resolved: 29/Jan/13

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

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


 Description   

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

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

Message:

Sorry, I've forgot the namespace in the test case of my previous PR, which has just been merged.



 Comments   
Comment by Benjamin Eberlei [ 29/Jan/13 ]

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





[DCOM-166] [GH-246] Undefined variable fix Created: 25/Jan/13  Updated: 08/Sep/13  Resolved: 26/Jan/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 26/Jan/13 ]

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





[DCOM-163] [GH-245] Documentation fixes Created: 20/Jan/13  Updated: 11/Feb/14  Resolved: 03/Dec/13

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

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


 Description   

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

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

Message:

Documentation fixes, continuing the work done on [ORM](https://github.com/doctrine/doctrine2/pull/528) and [DBAL](https://github.com/doctrine/dbal/pull/243).

  • Missing docblocks
  • Missing / incorrect `@param` / `@return` / `@throws` annotations
  • Missing newlines between annotations
  • Incorrect vertical alignment of `@param` annotations
  • Incorrect doctrine-project.org links
  • SVN leftovers cleanup
  • Licensing (LGPL => MIT)


 Comments   
Comment by Doctrine Bot [ 21/Jun/13 ]

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

Comment by Doctrine Bot [ 21/Jun/13 ]

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

Comment by Marco Pivetta [ 03/Dec/13 ]

Merged: https://github.com/doctrine/common/commit/c4255b9fbd63ee1fe52697839318af5937fced9b

Comment by Doctrine Bot [ 23/Dec/13 ]

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

Comment by Doctrine Bot [ 11/Feb/14 ]

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





[DCOM-162] [GH-244] return parameter for debug method Created: 14/Jan/13  Updated: 05/Dec/13  Resolved: 05/Dec/13

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

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


 Description   

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

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

Message:

Added $return as 4th parameter to specify whether to return the debug text or print it. It works similar to print_r function



 Comments   
Comment by Doctrine Bot [ 03/Dec/13 ]

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

Comment by Marco Pivetta [ 05/Dec/13 ]

Merged: https://github.com/doctrine/common/commit/ba2ad8a7db24adb37a33ff52ee64b02d59ccfee0





[DCOM-159] [GH-241] Minor performance optimization for lookups of `ArrayCollection#contains()` Created: 08/Jan/13  Updated: 08/Sep/13  Resolved: 08/Jan/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 08/Jan/13 ]

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





[DCOM-158] [GH-240] [Cache/CouchbaseCache] Return false instead of null for compat. Created: 07/Jan/13  Updated: 08/Sep/13  Resolved: 07/Jan/13

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

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


 Description   

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

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

Message:

This changeset fixes and verifies that instead of null, false is returned
from the fetch method. This fixes a bug which causes CouchbaseCache not
to work in combination with the ORM library. Test added.



 Comments   
Comment by Benjamin Eberlei [ 07/Jan/13 ]

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





[DCOM-157] [GH-239] Update lib/Doctrine/Common/Cache/Cache.php Created: 06/Jan/13  Updated: 20/Dec/13  Resolved: 06/Jan/13

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

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


 Description   

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

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

Message:

Typo in interface documentation



 Comments   
Comment by Benjamin Eberlei [ 06/Jan/13 ]

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

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DCOM-155] [GH-237] Update tests/Doctrine/Tests/Common/Annotations/Fixtures/NamespaceWithClo... Created: 03/Jan/13  Updated: 08/Sep/13  Resolved: 10/Jan/13

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

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


 Description   

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

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

Message:

...sureDeclaration.php

Statement duplicate

$var = 1;
function () use ($var) {};



 Comments   
Comment by Benjamin Eberlei [ 10/Jan/13 ]

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





[DCOM-154] [GH-236] Adding Support for Couchbase as Caching Infrastructure. Created: 20/Dec/12  Updated: 06/Jan/13  Resolved: 06/Jan/13

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

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


 Description   

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

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

Message:

This changeset brings in support for Couchbase Server 2.0 as
the caching layer. The interface is identical to the memcached
one, but using ext/couchbase allows to take advantage of the
automatic cluster discovery and failover functionality provided.






[DCOM-153] [GH-235] Improve performance of if key exists in the array Created: 17/Dec/12  Updated: 08/Sep/13  Resolved: 18/Dec/12

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

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


 Description   

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

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

Message:

So, here are few indications:
http://php.net/manual/en/function.array-key-exists.php#107786
http://php.net/manual/en/function.array-key-exists.php#104474



 Comments   
Comment by Benjamin Eberlei [ 18/Dec/12 ]

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





[DCOM-149] [GH-231] Fixing CS Created: 04/Dec/12  Updated: 08/Sep/13  Resolved: 14/Jan/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Benjamin Eberlei [ 04/Dec/12 ]

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





[DCOM-148] [GH-229] Decorator base class for object manager decorators Created: 25/Nov/12  Updated: 20/Jan/13  Resolved: 20/Jan/13

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

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


 Description   

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

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

Message:

As discussed on IRC, the first PR for decorator base classes. This time for ObjectManager.






[DCOM-147] [GH-227] [DDC-2160] Smart Pluralize/Singularize support for Doctrine/Common/Util/Inflector Created: 23/Nov/12  Updated: 08/Sep/13  Resolved: 14/Jan/13

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

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


 Description   

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

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

Message:

Doctrine/ORM/Tools/EntityGenerator should pluralize/signularize correctly.

This PR adds functionality to Doctrine/Common/Util/Inflector to singularize/pluralize. The code is largely borrowed from a similar class in the CakePHP project - I'm not sure if the updates to the class doc covers the requirements for this.

Test coverage also added.






[DCOM-146] [GH-226] Added error suppression to unlink() calls Created: 22/Nov/12  Updated: 08/Sep/13  Resolved: 22/Nov/12

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

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

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

Message:

Added error suppression to unlink() calls in the getPropertyAnnotations and getMethodAnnotations methods to be consistent with the getClassAnnotations method.



 Comments   
Comment by Benjamin Eberlei [ 22/Nov/12 ]

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

Comment by Fabio B. Silva [ 22/Nov/12 ]

Merged : https://github.com/doctrine/common/commit/a836c86c13e964051549e234250cf665a5f5a190





[DCOM-145] [GH-225] Replace file_exists() calls with is_file() where it is needed Created: 20/Nov/12  Updated: 08/Sep/13  Resolved: 21/Nov/12

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

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


 Description   

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

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

Message:

The function `file_exists()` checks whether file or directory exists. And `is_file()` checks only files for the existence. All places, where `file_exists()` is replaced with `is_file()` needs only to check for file existence.



 Comments   
Comment by Benjamin Eberlei [ 20/Nov/12 ]

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





[DCOM-142] [GH-222] make Base LifecycleEventArgs usable in orm and odm Created: 19/Nov/12  Updated: 08/Sep/13  Resolved: 05/Dec/12

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

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


 Description   

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

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

Message:

Pull requests are to come for both orm and odm to make use of this.

The main goal is to make more abstract listeners, compatible with both orm and odm.



 Comments   
Comment by Florian Klein [ 05/Dec/12 ]

@Benjamin Eberlei, any news on this ?





[DCOM-144] [GH-224] Use preg_quote() to escape text before inserting into regexp Created: 20/Nov/12  Updated: 08/Sep/13  Resolved: 21/Nov/12

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

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


 Description   

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

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

Message:

PHP has build-in function `preg_quote()` in order to escape strings witch are dynamically inserted into regular expression.



 Comments   
Comment by Benjamin Eberlei [ 21/Nov/12 ]

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





[DCOM-143] [GH-223] Fix for DCOM-106 Created: 20/Nov/12  Updated: 08/Sep/13  Resolved: 21/Nov/12

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

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


 Description   

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

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

Message:

Both fixme and TODO become ignored.



 Comments   
Comment by Benjamin Eberlei [ 20/Nov/12 ]

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





[DCOM-141] [GH-221] strip invalid characters Created: 17/Nov/12  Updated: 08/Sep/13  Resolved: 14/Jan/13

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

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


 Description   

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

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

Message:

This patch is proposal to fix #180
by replace invalid characters and hashing the filename as sub directories to create a unique path.






[DCOM-138] [GH-219] BC breaking constant name fix Created: 16/Nov/12  Updated: 20/Dec/13  Resolved: 03/Dec/13

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

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


 Description   

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

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

Message:

fixed typo on constant name (STATS_MEMORY_AVAILIABLE => STATS_MEMORY_AVAILABLE)



 Comments   
Comment by Doctrine Bot [ 03/Dec/13 ]

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

Comment by Marco Pivetta [ 03/Dec/13 ]

Merged - see https://github.com/doctrine/cache/commit/eec7544f6788dc28b2b8f18395c273bb65bfed7c

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DCOM-136] [GH-216] Adding failing test for silent autoloaders Created: 15/Nov/12  Updated: 08/Sep/13  Resolved: 10/Jan/13

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

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


 Description   

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

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

Message:

Fixing support for silent autoloaders






[DCOM-133] [GH-212] Issue/gh #135 Created: 09/Nov/12  Updated: 08/Sep/13  Resolved: 08/Sep/13

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

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


 Description   

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

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

Message:

Fixes #135



 Comments   
Comment by Benjamin Eberlei [ 09/Nov/12 ]

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





[DCOM-131] [GH-210] MappingDriverChain::getAllClassNames should load all classes from the defaultDriver Created: 27/Oct/12  Updated: 03/Dec/13  Resolved: 03/Dec/13

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

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


 Description   

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

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

Message:

I actually tried working around this by adding a driver using an empty string as the namespace, only to find out that `strpos()` doesn't accept an empty delimiter.

Anyway, this makes sure that all loadable classes for the defaultDriver are actually returned by MappingDriverChain as well.



 Comments   
Comment by Doctrine Bot [ 03/Dec/13 ]

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

Comment by Marco Pivetta [ 03/Dec/13 ]

Already solved in 2.4 at https://github.com/doctrine/common/commit/f7cdf27f04c27ce02e2c14a18ff9064cc37f7284





[DCOM-125] [GH-204] Bad function call in Debug::toString() Created: 17/Oct/12  Updated: 22/Dec/13  Resolved: 14/Jan/13

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

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


 Description   

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

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

Message:

Fixed an (obviously) over used function which were calling [method_exists](http://php.net/method_exists) function the wrong way.

In `Doctrine\Common\Util\Debug::toString($obj)`
From `method_exists('__toString',$obj)`
To `method_exists($obj,'__toString')`



 Comments   
Comment by Benjamin Eberlei [ 17/Oct/12 ]

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

Comment by Doctrine Bot [ 22/Dec/13 ]

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





[DCOM-127] [GH-206] Debug::export ArrayIterator dumps the internal storage variable Created: 19/Oct/12  Updated: 08/Sep/13  Resolved: 14/Jan/13

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

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


 Description   

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

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

Message:

Following my previous PR https://github.com/doctrine/common/pull/191 I found also ArrayIterator needs special behaviour.






[DCOM-126] [GH-205] Fixed a typo in PHPdoc Created: 17/Oct/12  Updated: 08/Sep/13  Resolved: 14/Jan/13

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

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


 Description   

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

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

Message:

A unnecessary new line was inserted in ClassLoader.php



 Comments   
Comment by Benjamin Eberlei [ 17/Oct/12 ]

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





[DCOM-122] [GH-200] ClassMetadataFactory child classes can now filter the metadata when calling getAllMetadata Created: 07/Oct/12  Updated: 07/Oct/12  Resolved: 07/Oct/12

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

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


 Description   

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

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

Message:

This is due mainly, because we have found performance issues when trying to generate a complete schema (annotation based) from a legacy database with tons of tables with the ConvertMapping command.

This will let filter table names to the ```Doctrine\ORM\Mapping\Driver\DatabaseDriver::getAllClassNames``` and ```Doctrine\ORM\Mapping\Driver\DatabaseDriver::loadMetadataForClass``` methods, and extract class metadata from a smaller subset of classes (I'm doing another PR for this in the ORM repository).



 Comments   
Comment by Benjamin Eberlei [ 07/Oct/12 ]

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





[DCOM-123] [GH-202] Add sqlite cache driver Created: 08/Oct/12  Updated: 23/May/13  Resolved: 23/May/13

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

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


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 23/May/13 ]

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





[DCOM-121] [GH-198] [DCOM-118] fix for issue #195 Created: 03/Oct/12  Updated: 03/Dec/13  Resolved: 03/Dec/13

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

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


 Description   

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

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

Message:

I'm sorry, i have no idea why i got here now 23 commits .. i tried but no success.



 Comments   
Comment by Doctrine Bot [ 03/Dec/13 ]

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

Comment by Marco Pivetta [ 03/Dec/13 ]

Ported to https://github.com/doctrine/annotations/pull/17





[DCOM-120] [GH-197] Avoid a critical error when parsed class is not found Created: 03/Oct/12  Updated: 08/Sep/13  Resolved: 08/Sep/13

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

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


 Description   

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

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

Message:

Found a bug that returns a critical error when parsed class is not found. The new test explains exactly the situation found.

This issue was found running this test suite: https://github.com/alphalemon/AlphaLemonCmsBundle, running the following test; phpunit Tests/Functional/Controller/SecuryControllerTest.php



 Comments   
Comment by Benjamin Eberlei [ 07/Oct/12 ]

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





[DCOM-116] [GH-193] Optimize autoload prefix in composer.json Created: 28/Sep/12  Updated: 08/Sep/13  Resolved: 14/Jan/13

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

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


 Description   

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

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

Message:

By having more specific autoload prefixes it is possible to reduce the number of stat calls made.



 Comments   
Comment by Benjamin Eberlei [ 28/Sep/12 ]

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





[DCOM-115] [GH-191] Debug::export ArrayObject dumps the internal storage variable Created: 27/Sep/12  Updated: 20/Dec/13  Resolved: 01/Oct/12

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

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


 Description   

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

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

Message:

Until now, exporting `ArrayObject` hid the internal storage variable, but `print_r` and `var_dump` show it.

With this PR the `ArrayObject::storage` variable is exported too.



 Comments   
Comment by Benjamin Eberlei [ 01/Oct/12 ]

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

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DCOM-102] Updates for Fedora packaging Created: 07/Jul/12  Updated: 28/Dec/13  Resolved: 28/Dec/13

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

Type: Improvement Priority: Major
Reporter: Shawn Iwinski Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

PEAR, Fedora, RHEL


Issue Links:
Reference
relates to DBAL-300 Updates for Fedora packaging Resolved
is referenced by DDC-1913 Updates for Fedora packaging Resolved

 Description   

I am packaging the DoctrineDBAL PEAR package for Fedora and would like to have the following updates:

  • package.xml role for LICENSE changed from "data" to "doc"


 Comments   
Comment by Steve Müller [ 28/Dec/13 ]

See DBAL-300





[DCOM-101] Implement FilesystemCache Created: 08/Jun/12  Updated: 25/Jun/12  Resolved: 25/Jun/12

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

Type: New Feature Priority: Major
Reporter: Guilherme Blanco Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   

Implement FilesystemCache, storing var exported pieces that could be loaded on demand.



 Comments   
Comment by Fabio B. Silva [ 25/Jun/12 ]

Fixed By : https://github.com/doctrine/common/commit/8df9cdf3b921a3b59bbba51d5ba9063509ef6a1a





[DCOM-98] Fix bug with memcache/memcached and 0 as expire Created: 30/Mar/12  Updated: 30/Mar/12  Resolved: 30/Mar/12

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

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





[DCOM-175] Proxies return private properties in __sleep, which is not supported by PHP. Created: 27/Mar/12  Updated: 02/Dec/13  Resolved: 30/Jul/13

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

Type: Bug Priority: Major
Reporter: Ryan Mauger Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DCOM-221 Merge DCOM-175 into 2.4 Sub-task Resolved Guilherme Blanco  

 Description   

__sleep should not return private parent property names (see http://php.net/__sleep) this raises notices, and also results in the value of the property being 'N' (null) instead of keeping its value.

I am unfortunately stuck having to serialize proxies in my revision tracking, as doctrine seems to be currently ignoring the fetch="EAGER" I set on the related properties.

Proxies should use the Serializable interface, and not __sleep, or not return parent property names which are private, it serves no purpose, and is not supported by PHP itself anyway.

Also, if you keep __sleep, but do not return the parent property names, then it will only include the items you return, so it would be better to simply drop the __sleep method, I cannot actually see any useful purpose it serves.



 Comments   
Comment by Ryan Mauger [ 27/Mar/12 ]

just updated the issue body, realised that I worded something badly.

Comment by Marco Pivetta [ 23/Jan/13 ]

Ryan Mauger I think that's a limitation we have. We use `__sleep` to avoid serializing fields like the initializers and the persisters of course.

Even by implementing serializable, it would only work if the end user implemented it in the parent class.

Tempted to mark it as "can't fix"

Comment by Marco Pivetta [ 24/Jan/13 ]

I think there's a solution by having something like following:

class SomeGeneratedProxyName extends RealName implements \Serializable
{
    public function unserialize($data)
    {
        $reflectionClass = new ReflectionClass($this);
        foreach ($reflectionClass->getProperties(ReflectionProperty::IS_PRIVATE) as $privateProp) {
            $privateProp->setAccessible(true);
            $privateProp->setValue($this, $data[$privateProp->getName()]);
        }
        // ... other props ...
    }

    public function serialize()
    {
        $data = array();
        $reflectionClass = new ReflectionClass($this);
        foreach ($reflectionClass->getProperties(ReflectionProperty::IS_PRIVATE) as $privateProp) {
            $privateProp->setAccessible(true);
            $data[$privateProp->getName()] = $privateProp->getValue($this);
        }
        // ... other props ...
        return $data;
    }
}
Comment by Marco Pivetta [ 23/Feb/13 ]

Ryan Mauger I started implementing this one at https://github.com/Ocramius/common/compare/hotfix;DCOM-175 and so far it looks promising.

The only doubts so far are with handling cases like following:

class MyEntity implements Serializable
{
    public function serialize()
    {
        // [...]
    }

    public function unserialize($serialized)
    {
        // [...]
    }

    public function __sleep()
    {
        // [...]
    }

    public function __wakeup()
    {
        // [...]
    }
}

So far I didn't get to write tests that demonstrate the exact behaviour for this case, but it looks like when `Serializable` is implemented, `_sleep` and `_wakeup` are ignored. Any thoughts on this?

Comment by Marco Pivetta [ 19/Apr/13 ]

A possible solution is to use something like http://eval.in/16806, and thus exploiting the ability of php to retrieve an object's private properties by using the special

chr(0) . 'Foo' . chr(0) . 'bar'

trick.

This can be abstracted by using

array_keys((array) $object);

, which retrieves also those special keys

Comment by Marco Pivetta [ 19/Jun/13 ]

Provided a fix at https://github.com/doctrine/common/pull/284

Comment by Marco Pivetta [ 30/Jul/13 ]

Solved at https://github.com/doctrine/common/commit/9c6b8615a988117dec83bdbb0fad80afef23eab8





[DCOM-96] Extract a common ProxyFactory Created: 12/Feb/12  Updated: 10/Jan/13  Resolved: 10/Jan/13

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

Type: New Feature Priority: Major
Reporter: Christophe Coevoet Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: None


 Description   

Currently, each Doctrine project implements its own ProxyFactory. But the most part of the logic is simply copy-pasted from the ORM implementation (or from an older version of the ORM implementation). Extracting the common code would be a good idea to avoid having to maintain 4 places (or even more) containing the same logic



 Comments   
Comment by Marco Pivetta [ 22/Oct/12 ]

I have a working implementation of public properties lazy loading at https://github.com/Ocramius/doctrine2/compare/master...DCOM-96-restarted

I am still trying to figure out performance issues, since this PR adds 5% overhead on top of Hydrators/Persisters/UnitOfWork, since it turned out that

$reflectionProperty->getValue($object);

actually triggers PHP's magic __get method.
I've worked this around by assuming nulls when values are not set, but this adds some conditionals that obviously slow down all the extraction of values process.





[DCOM-93] Add Reflection Abstraction Created: 28/Dec/11  Updated: 03/Jan/12  Resolved: 02/Jan/12

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

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

Issue Links:
Reference
is referenced by DDC-1577 Remove static Reflection dependency f... Resolved

 Description   

The Reflection code in ClassMetadata(Info*)s is getting out of control.

I want to remove the dependency by introducing a ReflectionService interface:

interface ReflectionService
{
    public function getClassShortName($class);
    public function getClassNamespace($class);
    public function getClass($class);
    public function getAccessibleProperty($class, $property);
    public function hasPublicMethod($class, $method);
}

The reflection methods are specifically allowed to return NULL, so that we can create a StaticReflectionService that works without the classes actually existing.



 Comments   
Comment by Benjamin Eberlei [ 28/Dec/11 ]

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

Comment by Benjamin Eberlei [ 29/Dec/11 ]

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

Comment by Benjamin Eberlei [ 02/Jan/12 ]

Implemented





[DCOM-91] GH-87: typos Created: 23/Dec/11  Updated: 16/Jan/12  Resolved: 16/Jan/12

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/common/pull/87



 Comments   
Comment by Guilherme Blanco [ 16/Jan/12 ]

Fixed as per PR resolution





[DCOM-90] GH-86: class_exists is great, use it. Created: 21/Dec/11  Updated: 16/Jan/12  Resolved: 16/Jan/12

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/common/pull/86



 Comments   
Comment by Guilherme Blanco [ 16/Jan/12 ]

As per PR's resolution





[DCOM-89] GH-85: php annotations Created: 15/Dec/11  Updated: 09/Jun/12  Resolved: 09/Jun/12

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/common/pull/85

Hello all,

This patch add support for php annotations, I think that is very useful to collect class metadata.
This patch support just 3 annotations ```@var, @param, @return```. but any annotation could be added.

@schmittjoh can you take a look please ?

Any suggestion are welcome.

Thanks



 Comments   
Comment by Guilherme Blanco [ 09/Jun/12 ]

Synchronizing with PR. It was closed.





[DCOM-88] GH-84: Fixed phpdoc for the persistence interfaces Created: 13/Dec/11  Updated: 16/Jan/12  Resolved: 16/Jan/12

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/common/pull/84



 Comments   
Comment by Guilherme Blanco [ 16/Jan/12 ]

Fixed since https://github.com/doctrine/common/commit/52c3882633b3cf11a694f2e8d9aaacb449bf5c6c





[DCOM-87] Add a method to retrieve the identifier values in the Common interfaces Created: 12/Dec/11  Updated: 02/Jan/12  Resolved: 02/Jan/12

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

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


 Description   

Currently, https://github.com/symfony/symfony/blob/master/src/Symfony/Bridge/Doctrine/Security/User/EntityUserProvider.php is tied to the ORM, forcing bundle integrating other Doctrine projects to reimplement it.

The only place which is not (or cannot be) implemented using only methods from the Common interfaces is retrieving the current id. `getIdentifierValues` is now implemented by the ClassMetadata in all ORM, MongoDB and CouchDB but not in the interface.

Note that the tricky point about adding it is the fact that the DisconnectedMetadataFactory (used when generating entities) returns a ClassMetadataInfo instead, which does not contain this method (as it relies on the existence of the class) but implements the interface.



 Comments   
Comment by Benjamin Eberlei [ 02/Jan/12 ]

This was implemented





[DCOM-85] GH-81: Add Proxy#__load() Created: 03/Dec/11  Updated: 12/Dec/11  Resolved: 12/Dec/11

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

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


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/common/pull/81



 Comments   
Comment by Benjamin Eberlei [ 12/Dec/11 ]

Implemented in https://github.com/doctrine/common/pull/83





[DCOM-82] Fix composer.json in 2.1.x releases missing autoloader Created: 26/Nov/11  Updated: 26/Nov/11  Resolved: 26/Nov/11

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

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





[DCOM-81] Attempt to create Annotation File Cache directory Created: 23/Nov/11  Updated: 23/Nov/11  Resolved: 23/Nov/11

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Comments   
Comment by Fabio B. Silva [ 23/Nov/11 ]

Fixed : https://github.com/doctrine/common/pull/77





[DCOM-78] ZendDataCache, Can't use method return value in write context Created: 19/Nov/11  Updated: 19/Nov/11  Resolved: 19/Nov/11

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

Type: Bug Priority: Major
Reporter: Matti Niemelä Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

On line 70, empty($this->getNamespace()).

empty() works only with variables so you need to assign the namespace to something before using empty().

Fatal error: Can't use method return value in write context in Doctrine/Common/Cache/ZendDataCache.php on line 70



 Comments   
Comment by Benjamin Eberlei [ 19/Nov/11 ]

Fixed





[DCOM-79] Move Lifecycle Events into Doctrine\Common\Persistence\Events Created: 19/Nov/11  Updated: 12/Dec/11  Resolved: 12/Dec/11

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

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


 Comments   
Comment by Benjamin Eberlei [ 12/Dec/11 ]

Implemented in 29dbb7070058c8e7bb81bc5f9ef79d877b058887





[DCOM-76] switch license to MIT Created: 09/Nov/11  Updated: 09/Jun/12  Resolved: 09/Jun/12

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

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


 Description   

since common was mostly written by a small group of people and not based on Doctrine 1.x it seems possible to switch the license which imho would really boost the use cases.



 Comments   
Comment by Guilherme Blanco [ 09/Jun/12 ]

Successfully migrated to MIT!!! \o/





[DCOM-70] [CacheProvider] missing functions Created: 27/Sep/11  Updated: 06/Mar/12  Resolved: 03/Oct/11

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

Type: Bug Priority: Major
Reporter: Jérôme Forêt Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

Why delete functions in CacheProvider like deleteByPrefix deleteByPostfix deleteByRegex ?
DeleteAll and FlushAll do not replace them. Please revert for these functions.



 Comments   
Comment by Guilherme Blanco [ 03/Oct/11 ]

The deleteBy*() aswell as getIds() methods cannot be brought back.
Some drivers do not support the getIds(), because (and I agree with) they consider the keys retrieval as a security issue.

Since we keep the Least Common Multiple (LCM) in our Cache platform, these drivers started to be affected in latest *NIX releases (like for example, Memcache 1.6.5+ that does not bring cachedump anymore).

We started to have many reports here because cache was not working, or they were not clearing or even they were getting partially cleared. So we re-worked on Cache package to bring the LCM again.

Based on that, individual drivers like APC may still support the cache Id retrieval, but our approach differed and we can't bring this back. You may override into your own driver (composition) extending our ApcCache and implemented your desired functions.

Marking the ticket as won't fix.

Cheers,

Comment by Peter Mitchell [ 06/Mar/12 ]

The documentation still refers to these deprecated elements which is a little confusing as there is no indication of this in the Abstract Classes/Interfaces

http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/caching.html





[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-71] Add save get_class() to Debug Util Created: 22/Oct/11  Updated: 23/Oct/11  Resolved: 23/Oct/11

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

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


 Comments   
Comment by Benjamin Eberlei [ 23/Oct/11 ]

Added.





[DCOM-66] Github-PR-55 by shesek: Use stream_resolve_include_path Created: 25/Aug/11  Updated: 28/Aug/11  Resolved: 28/Aug/11

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed 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/55

Message:

`Doctrine\Common\ClassLoader::fileExistsInIncludePath` behaves the same as `stream_resolve_include_path`, use that instead when available (PHP >= 5.3.2). It should be faster than doing that manually.



 Comments   
Comment by Guilherme Blanco [ 28/Aug/11 ]

Fixed in trunk.





[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-60] SimpleAnnotationReader get*Annotations Created: 12/Aug/11  Updated: 28/Aug/11  Resolved: 28/Aug/11

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

Type: Bug Priority: Major
Reporter: Ryan Hutchison Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

<br />
<b>Notice</b>: Undefined variable: class in <b>/usr/home/gym/doctrine2-common/lib/Doctrine/Common/Annotations/SimpleAnnotationReader.php</b> on line <b>45</b><br />
<br />
<b>Fatal error</b>: Call to a member function getName() on a non-object in <b>/usr/home/gym/doctrine2-common/lib/Doctrine/Common/Annotations/SimpleAnnotationReader.php</b> on line <b>45</b><br />

Doctrine/Common/Annotations/SimpleAnnotationReader.php
    public function getMethodAnnotations(\ReflectionMethod $method)
    {
-        return $this->parser->parse($method->getDocComment(), 'method '.$class->getName().'::'.$method->getName().'()');
+        return $this->parser->parse($method->getDocComment(), 'method '.$method->getName().'::'.$method->getName().'()');
    }

    public function getPropertyAnnotations(\ReflectionProperty $property)
    {
-        return $this->parser->parse($property->getDocComment(), 'property '.$class->getName().'::$'.$property->getName());
+        return $this->parser->parse($property->getDocComment(), 'property '.$property->getName().'::$'.$property->getName());
    }


 Comments   
Comment by Guilherme Blanco [ 28/Aug/11 ]

This issue is already fixed in master. Closing the ticket.





[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





[DCOM-56] Remote autoloading from annotations completly, replacing it with its own loading mechanism Created: 01/Jul/11  Updated: 02/Jul/11  Resolved: 02/Jul/11

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

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


 Description   

This is a mail from me to the symfony-dev mailing-list:

I am sorry it is very late to bring this up again, but given the nasty problems I faced today with the way annotationreader works with autoload = true I have to share them (and blow of some steam). While i guess its to late to change this again before 2.0, we might still have to discuss to go away from autoload = true for 2.1. Now for the reasons:

AnnotationReader with autoload = true (which Symfony2 uses) will not only require a silent autoloader, it requires ALL autoloaders used to be silent. While this is the case for the Symfony Universal loader its not the case for the Doctrine one, and not for many others - and its not even a PSR-0 requirement. For a simple reason: Supporting silent failure means using file_exists, means a file stat, which means apc.stat = 0 is useless. While I don't care so much about it in Doctrine context, because the AnnotationReader default is NOT to autoload annotations this will cause problems for Symfony: Not every library in any Symfony2 app will be included through a silent autoloader. That means given the context users might run into problems using annotations that they have absolutely no way of fixing. And since the AnnotationReader does not know this upfront, potential failures become very real issue.

Example: I use SecurityExtraBundle and happen to have my SuperDuperLibrary XYZ. That library was developed by my company and contains tons of important business logic but unfortunately uses a non-silent autoloader (for whatever reasons). However i use Symfony to secure access to it by generating secure proxies. Now what happens if an annotation reader runs over that library? Because the current namespace is always considered, for every @var _NAMESPACE."
var" is class_exists'ed and then your code fatal errors. I didn't see this problem before, because i don't use annotations myself so much and always in the BC Doctrine 2.0.x way and that slipped my mind. Same goes for Validation with Annotations on external code, or maybe in the future services definitions through annotations.

All this trouble we are getting into with autoloading annotations is just because we wanted to validate that the annotations used actually exist. But since we changed to a use/import approach rather then re-using namespaces we don't even have the clashing problem anymore that got us into the trouble with class_exists before. The autoloading however also got us and users into other problems:

1. We have to maintain a rather large map of "blacklisted" annotations that never throw failure exceptions because they are actually used as doc documentations. As with blacklists this is never a complete list.
2. Users with intensive doc-block usage are punished by Symfony having to maintain their own blacklist of annotations that never throw exceptions so that their code actually works.
3. Libraries have to handle the case that a reader is either using autoloading or not through special code.

While I do think it would have been nice to offer validation for annotation this is a task that should be put on IDEs and developers, since it turns out that its not possible flawlessly within the library itself. The AnnotationReader should always use class_exists($name, false). Docblocks are still comments and the code shouldn't fail because classes are not available that are not even relevant in the context of the current AnnotationReader. Each part of the code that uses an AnnotationReader should require_once the annotations that it can potentially need upfront. That even works for Validation as you can grab the tags from the DIC. That way we have a single mode of operation for the AnnotationReader and not two different ones that are 180 degrees different. OF course one could argue ALWAYS to use class_exists($name, true) instead, but i hope my mail showed why this is not a good idea.

If for some reason we do want autoloading for annotations then it should be a mechanism different from the PHP one, because they are both not compatible. The reader could have hooks for autoloading and validation mechanisms. Nothing we want to add for Doctrine Common 2.1, but something we could easily play around with for Common 3.

Next a mail with implementation details:

I propose to change the following on AnnotationReader:

1. Add a method to register annotation classes:
$reader->registerAnnotation("Symfony\Bridge\Doctrine\Validator\UniqueEntity");
and $reader->registerAnnotations(array(..));
2. Add a method to register files that contain annotations:
$reader->registerAnnotationFile(".."), directly loading them via
require_once;
3. Add a method to register annotation namespaces:
$reader->registerAnnotationNamespace("Symfony\Component\Validator\Constraint",
$dir). This is used to create a silently failing PSR-0 "autoloader" for
this path + directories. It can be automatically populated from data in
the UniversalClassLoader.
4. Change the class_exists check to never use autoload = true. If a
class is part of a registered annotation namespace try load the file based on a silent
PSR-0 autoload for it using an autoloader impl. contained in the
AnnotationReader (not the php autoloading mechanism), before triggering
the class_exists($name, false)

This way for symfony only the UniversalClassLoader data has to be used
to populate the registered annotation namespaces.



 Comments   
Comment by Benjamin Eberlei [ 02/Jul/11 ]

Implemented





[DCOM-55] Ugly problems with default import __NAMESPACE__ when it contains non-annotation classes that are docblock props Created: 29/Jun/11  Updated: 29/Jun/11  Resolved: 29/Jun/11

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

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


 Description   

Say you have a class "Entity".

Then /** @Entity */ on a class in the same namespace will try to instantiate Entity.

We should avoid this by testing if Entity is a subclass of \Doctrine\Common\Annotations\Annotation



 Comments   
Comment by Benjamin Eberlei [ 29/Jun/11 ]

Actually this problem is more problematic, we have to enforce extending \Doctrine\Common\Annotations\Annotation for ALL annotations.

Comment by Benjamin Eberlei [ 29/Jun/11 ]

Fixed.





[DCOM-54] ClassLoader protected properties Created: 14/Jun/11  Updated: 17/Jul/11  Resolved: 17/Jul/11

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

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

na



 Description   

It would be great if the members of ClassLoader($fileExtension, $namespace, $includePath, $namespaceSeparator) where protected instead of private. In order to work around DCOM-20 I was going to extend and override loadClass but the private members mean I need to copy a lot of other code.
Didn't seem worth the overhead of creating a patch - but I can if you prefer.



 Comments   
Comment by Guilherme Blanco [ 17/Jul/11 ]

Fixed in https://github.com/doctrine/common/commit/c614a20e02cb8fd5531bce1adcb34a1210f79ac6





[DCOM-53] PhpParser doesn't ignore commented keywords Created: 24/May/11  Updated: 04/Sep/11  Resolved: 04/Sep/11

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

Type: Bug Priority: Major
Reporter: Michel D'HOOGE Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

PhpParser class provided with Symfony2 BETA 2
https://github.com/doctrine/common/blob/18518814c0f4e11fe90a0ec56919d4d2315565ef/lib/Doctrine/Common/Annotations/PhpParser.php



 Description   

The PhpParser makes a too optimistic assumption about code convention...

If you have the word 'class' or 'interface' in the comment before the class definition, preg_match_all finds wrong slice of code and PHP complains with a Warning about "Unterminated comment". This occurs only once after the cache is cleared.



 Comments   
Comment by Fabio B. Silva [ 03/Sep/11 ]

Hello all
I tested this issue.

After rewriting the php parser does not happen. : https://github.com/doctrine/common/commit/d274bd7fe9e8f5657c670ed8a22a31024544eeeb

I think that can be closed

Thanks

Comment by Michel D'HOOGE [ 04/Sep/11 ]

Unfortunately, I can't remember when the problem disappeared but it is no longer here for sure.
And since the call to preg_match_all has been removed, we can close the issue.





[DCOM-51] Support parsing of single quotes Created: 03/May/11  Updated: 05/May/11  Resolved: 05/May/11

Status: Resolved
Project: Doctrine Common
Component/s: Annotations
Affects Version/s: 2.0.2
Fix Version/s: 2.1

Type: New Feature Priority: Major
Reporter: Jordi Boggiano Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

It'd be great to support single quotes, this limitation doesn't make sense from a user point of view and in php context single quotes are so commonly used that it's easy to slip and then get some funny Exception message out of it.



 Comments   
Comment by Jordi Boggiano [ 03/May/11 ]

Patch against master is at https://github.com/doctrine/common/pull/17

Comment by Guilherme Blanco [ 05/May/11 ]

Merged the pull request.

Thanks!





[DCOM-50] Unable to use '@' in combination with a number (example: email@3domain.tld) in comment block Created: 28/Apr/11  Updated: 13/May/11  Resolved: 13/May/11

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

Type: Bug Priority: Major
Reporter: Florian Preusner Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

My tld contains a number at the beginning (8points.de).
I'm not able to use it in the @author section (@author Florian Preusner <florian.preusner@8points.de>) cause after the "@" the next letter is a number.

Exception:
AnnotationException: [Syntax Error] Expected Doctrine\Common\Annotations\Lexer::T_IDENTIFIER, got '8' at position 118 in method Blog\MainBundle\Controller\MainController::indexAction().
n /var/www/floeh/vendor/doctrine-common/lib/Doctrine/Common/Annotations/AnnotationException.php at line 41

I think this is a bug?!



 Comments   
Comment by Guilherme Blanco [ 13/May/11 ]

Fixed on master.

https://github.com/doctrine/common/commit/42029e6327f6ffc00a268cb61892b8ecbba49278





[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-46] Make annotation index configurable Created: 07/Apr/11  Updated: 13/May/11  Resolved: 13/May/11

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

Type: Improvement Priority: Major
Reporter: Johannes Schmitt Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

So, this is another improvement that I'd like to make. Right now all annotations are indexed by their name which has the limitation that on the top level annotations with the same name are only gathered once.

/**
 * @param mixed $a
 * @param mixed $a
 * @param mixed $a
 */
function ($a, $b, $c) { }

In the above case the annotation parser would only pick up one "param" annotation. My guess is that this was done for fast lookups, but I think we need to make this configurable (I know you hate this word ) as the workaround here is needlessly bloated.

/**
 * @params({@param, @param, @param})
 */
function($a, $b, $c) {}

This only requires two lines to be changed/made conditional, see
https://github.com/schmittjoh/SecurityExtraBundle/blob/master/Mapping/Driver/AnnotationParser.php#L63
https://github.com/schmittjoh/SecurityExtraBundle/blob/master/Mapping/Driver/AnnotationParser.php#L72

p.s. If you want me to provide a patch for this, just tell me.



 Comments   
Comment by Guilherme Blanco [ 13/May/11 ]

Implemented on master.

https://github.com/doctrine/common/commit/59910f53fad7ce08a1ec840d9874a74cefcf32b8





[DCOM-45] Allow different namespaces for the same alias Created: 07/Apr/11  Updated: 26/Apr/11  Resolved: 26/Apr/11

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

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


 Description   

Right now, it is only possible to register one namespace per annotation alias. This might lead to problems since we now throw exceptions if an annotation is not found in that namespace (https://github.com/doctrine/common/commit/8967f476ddcdb7b9017a8be7f774979ca4c72247).

This improvement would be a necessary first step in order to overcome the problem we talked about on IRC (FrameworkExtra/SecurityExtra both using the "extra" alias).



 Comments   
Comment by Johannes Schmitt [ 26/Apr/11 ]

I'll close this as there is a better solution now.





[DCOM-44] Throw exception if known namespaced annotation is not found Created: 05/Apr/11  Updated: 06/Apr/11  Resolved: 05/Apr/11

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

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


 Description   

If we know that an annotation is namespaced and that the namespace exists we should throw an exception if the annotation specified does not exist, currently its just skipped which can be very nasty to debug.



 Comments   
Comment by Benjamin Eberlei [ 05/Apr/11 ]

Implemented

Comment by Gediminas Morkevicius [ 06/Apr/11 ]

For example my extensions are using same alias[vendor name] for all annotations. In this case each extension can be used independetly from others. And after this "fix" it couples all extensions and forces to autoload all annotations because in other case it will simply throw a fatal error, since class_exists now uses require without even checking if file exists.
Instead of fatal error ClassLoader maybe could throw an exception.

Comment by Benjamin Eberlei [ 06/Apr/11 ]

This change should not fatal through class_exists(). I dont change the autoloading behavior at all, i just throw an exception if the class was not found and annotation is namesapced

Johannes complained about this for the same reason (reusing vendor prefixes).

I find this quite annoying, because i constantly misstype annotations and get no error messages at all, the number of bug reports in this regard is also quite high. We have to find a solution for this





[DCOM-43] Cache Stats Created: 05/Apr/11  Updated: 21/Sep/11  Resolved: 21/Sep/11

Status: Resolved
Project: Doctrine Common
Component/s: Caching
Affects Version/s: 2.0.1
Fix Version/s: 2.2

Type: New Feature Priority: Major
Reporter: Otavio Ferreira Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Doctrine should be able to retrieve stats from cache providers, such as Memcache and APC. Stats may list cache hits, cache misses, memory, and so forth.



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

Implemented this support since this commit: https://github.com/doctrine/common/commit/34e060309ee1ae06f4be610d39d8721d2cfb1b90





[DCOM-41] Make annotation parser a bit cleverer Created: 09/Mar/11  Updated: 07/Apr/11  Resolved: 07/Apr/11

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

Type: Bug Priority: Major
Reporter: Johannes Schmitt Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

From an initial look that I had at the annotation parser, it simply search for anything starting with an "@" somewhere in the doc comment and assumes that it is an annotation. Now, if someone uses the @ somewhere in his doc comment but not as an annotation, the parser breaks.

An example for this can be found in the Doctrine code base, the following comment will result in a parse error:

    /**
     * Annotation     ::= "@" AnnotationName ["(" [Values] ")"]
     * AnnotationName ::= QualifiedName | SimpleName | AliasedName
     * QualifiedName  ::= NameSpacePart "\" {NameSpacePart "\"}* SimpleName
     * AliasedName    ::= Alias ":" SimpleName
     * NameSpacePart  ::= identifier
     * SimpleName     ::= identifier
     * Alias          ::= identifier
     *
     * @return mixed False if it is not a valid annotation.
     */

Obviously the first @ is not used to refer to an annotation here. I think it makes sense to allow new annotations only to start at a new line, what do you think?



 Comments   
Comment by Johannes Schmitt [ 09/Mar/11 ]

The pull request is here:
https://github.com/doctrine/common/pull/9

Comment by Benjamin Eberlei [ 09/Mar/11 ]

Does this still work with nested annotations?

/**
 * @annot({@annot2})
 */
Comment by Johannes Schmitt [ 09/Mar/11 ]

Sure, my patch only changes the way how the first @ is found.

Comment by Roman S. Borschel [ 09/Mar/11 ]

First of all, thanks for the patch. I'm just not sure whether the added complexity (nontrivial regexp vs substr/strpos) and performance penalty (to be tested) can justify fixing these such edge-cases where an @ appears in the comment block that is not one of the already stripped inline docblocks. Just my two cents, I think this needs further investigation and more extensive testing.

Edit: Since the regex is "only" applied once per parsed docblock the perf. difference might be negligible but should be tested anyway. Remains the verification of the correctness of the regex, given more extensive testing and test-cases.

Comment by Johannes Schmitt [ 09/Mar/11 ]

I think performance should not be an issue since this data is cached anyway.

As for the necessity of this, it's a pain if you parse third party files and they use @ somewhere which then breaks the parser. Since Symfony2 is heavily relying on the annotation parser not only for Doctrine metadata, but for annotation metadata in general, imo this needs to be fixed. I'm not 100% happy with my solution since it covers not all, but only the most likely cases. Ideally, the lexer would have a better way to detect if an @ is used to mark the beginning of an annotation, and simply ignore the @ if it does not. I'm not familar with the lexer code, but you probably have a better understand of how it works and whether this would make sense.

EDIT: I've made an alternative implementation which you can find here: https://github.com/schmittjoh/common/commit/123315e21aff6d7bce7cb77ab798660d0e68b139

Comment by Benjamin Eberlei [ 05/Apr/11 ]

Fixed formatting of code block

Comment by Benjamin Eberlei [ 07/Apr/11 ]

Fixed





[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-39] It is not possible to load multiple directories under the same namespace Created: 04/Mar/11  Updated: 04/Mar/11  Resolved: 04/Mar/11

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

Type: Improvement Priority: Major
Reporter: Steven Rosato Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

Consider the following code snippet:

$loader = new ClassLoader('DoctrineExtensions',
   "/path/to/vendor/doctrine2-extensions-beberlei/lib");
$loader->register();

$loader = new ClassLoader('DoctrineExtensions',
   "/path/to/vendor/doctrine2-extensions-srosato/lib");
$loader->register();

The latter will not be able to be loaded since the documentation specifies (with good reason) that class loaders do not fail silently. Is there a workaround for this issue?



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

Or maybe this is intentional, such as authors that write separate doctrine extensions (according to this exemple) must define their own namespace.

Comment by Benjamin Eberlei [ 04/Mar/11 ]

This is desired behavior, you need to pass a more specific path like "DoctrineExtensions/Versionable" + "DoctrineExtensions/Paginate" and so on...





[DCOM-32] Memcache cache relies on deprecated functions Created: 21/Dec/10  Updated: 28/Mar/12  Resolved: 27/Aug/11

Status: Resolved
Project: Doctrine Common
Component/s: Caching
Affects Version/s: 2.0.0-RC2
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: Sebastian Hoitz Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

The method getIds() in MemcacheCache relies on the old "cachedump" stat type.

But as you can read here: http://de2.php.net/manual/en/memcache.getextendedstats.php this has been removed due to security reasons.



 Comments   
Comment by Sebastian Hoitz [ 21/Dec/10 ]

Adding this to memcached before getting the extended stats cachedump fixed this issue for me:

if(!is_int($slabId)) {
    continue;
}
Comment by Guilherme Blanco [ 15/Feb/11 ]

This issue doesn't seen to be valid anymore based on commit of @hobodave on Jan 29th.

Please reopen if it is still valid. I could not reproduce.

Comment by Guilherme Blanco [ 18/Apr/11 ]

Memcache daemon 1.4.5 do not provide cachedump and triggers a couple of issues all around.
Here is a link that gives more information: http://www.pecl.php.net/bugs/bug.php?id=20375&edit=3

We need to think on a workaround since current state of Doctrine 2 is unusable with recent memcache.

Comment by Denis [ 07/May/11 ]

There additionally seems to be a hard-coded limit to the size of the dump:

http://stackoverflow.com/questions/4363904/is-there-any-length-limitation-of-result-by-stats-cachedump-in-memcached

http://lists.danga.com/pipermail/memcached/2007-April/003906.html

Comment by Guilherme Blanco [ 27/Aug/11 ]

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

Comment by Przemek Sobstel [ 28/Mar/12 ]

@Guilherme, your fix introduced big performance issue as now for each fetch() call there are always 2 additional calls, which is kind of big overhead. See https://github.com/doctrine/common/pull/125 for details.





[DCOM-31] setAutoloadAnnotationClasses() within AnnotationReader fails Created: 12/Nov/10  Updated: 15/Nov/10  Resolved: 15/Nov/10

Status: Resolved
Project: Doctrine Common
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.0-RC2

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


 Description   

When calling setAutoloadAnnotationClasses() from within AnnotationReader, it fails because setAutoloadAnnotationClasses() is not implemented in Doctrine\Common\Annotations\Parser.

This should be fixed, or at least a FeatureNotImplementedException or such.



 Comments   
Comment by Benjamin Eberlei [ 15/Nov/10 ]

Duplicate of DCOM-25





[DCOM-21] Bug with annotations parser and tags that are not annotations (stripped tags) Created: 18/Aug/10  Updated: 18/Aug/10  Resolved: 18/Aug/10

Status: Resolved
Project: Doctrine Common
Component/s: None
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1

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


 Comments   
Comment by Jonathan H. Wage [ 18/Aug/10 ]

Fixed in http://github.com/doctrine/common/commit/df50f65ee707bb148682232c516d5168cf46d987





[DCOM-19] Transitive persistence on collections doesn't work when cascade is set to "all" Created: 10/Aug/10  Updated: 11/Aug/10  Resolved: 11/Aug/10

Status: Resolved
Project: Doctrine Common
Component/s: Collections
Affects Version/s: 2.0.0-BETA4
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: akeem philbert Assignee: Roman S. Borschel
Resolution: Invalid Votes: 0
Labels: None


 Description   

In documentation it says that cascade needs be set to persist for transitive persistence to work (http://www.doctrine-project.org/projects/orm/2.0/docs/reference/working-with-associations/en#transitive-persistence-/-cascade-operations:persistence-by-reachability:-cascade-persist) , but since "all" setting is a superset of "persist" it should work for that setting as well (but it doesn't )



 Comments   
Comment by akeem philbert [ 11/Aug/10 ]

It seems there is an issue with persisting new elements to a collection with existing elements and I've created a separate ticket (http://www.doctrine-project.org/jira/browse/DDC-742) so this one is invalid.





[DCOM-20] ClassLoader should check before require()... Created: 12/Aug/10  Updated: 12/Aug/10  Resolved: 12/Aug/10

Status: Resolved
Project: Doctrine Common
Component/s: Class Loading
Affects Version/s: 2.0.0-BETA4
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Alexander Trauzzi Assignee: Roman S. Borschel
Resolution: Invalid Votes: 0
Labels: None
Environment:

Ubuntu 10.04



 Description   

I noticed that prior to the require function call in loadClass(), no attempt is made to see if the file can be loaded, or to trap the result of the require attempt.

This means that when I chain together class loaders on the autoload stack, the first one that specifies a namespace of null effectively terminates the process, preventing any others from being run.



 Comments   
Comment by Alexander Trauzzi [ 12/Aug/10 ]

One solution I propose (and have used in my own class loaders in the past) is to check and see if the file exists and/or is accessible prior to the require() or include().
It might be done something like this:


public function loadClass($className)
{
if ($this->namespace !== null && strpos($className, $this->namespace.$this->namespaceSeparator) !== 0)

{ return false; }

if ($this->canLoadClass())

{ require ($this->includePath !== null ? $this->includePath . DIRECTORY_SEPARATOR : '') . str_replace($this->namespaceSeparator, DIRECTORY_SEPARATOR, $className) . $this->fileExtension; return true; }

return false;

}

Another might be to catch any errors thrown by the require statement if possible.

This effectively guarantees that in the event of a failure, the natural PHP mechanism of the class autoloader can follow up or terminate, resulting in a Class Not Found error, rather than a failed include - which might be potentially misleading??

Comment by Alexander Trauzzi [ 12/Aug/10 ]

I should note that it isn't up to ClassLoader to trigger a failure in class loading, otherwise class instantiation requires every call to the "new" keyword to be prefixed by a check to verify the class is available.

ClassLoader should for the most part fail silently with the one exception of notifying the autoload stack with the boolean return value. Any other errors force developers to get into the plumbing and breaks the contract between PHP's class loading behaviour and the autoload stack.

Comment by Roman S. Borschel [ 12/Aug/10 ]

Hi.

This is by design. We consider the default "contract" for autoloaders inferior as checks for file existence are unnecessary and expensive in 99.9% of the classes loaded.

The ClassLoader of the Common project separates the responsibilities for a) checking whether a class can be loaded and b) actually loading the class.

Furthermore, it is by design that each class loader is responsible for classes in a certain namespace. Only 1 classloader can thus be responsible for a single class. If a class loader is asked to load a class, and he is responsible for loading that class, any failure to do so is a fatal error. A missing class that is requested to be loaded is a fatal error. Silently ignoring such cases is a very bad approach from our point of view and it requires slow(er) implementations due to checks for file existence.

If you specify NULL as the namespace, that means this class loader should be responsible for all classes. Thus it is obvious that a class loader that is configured as such can only be used a) as the only one or b) at the end of the autoload stack (as the last one).

This approach to class loading and this implementation is designed for best efficiency.

If you do not like this approach to class loading you are free to use any other implementations, Doctrine classes don't care which autoloader loads them.

ps. return values don't matter at all in autoload functions for PHP, they only matter if you invoke them directly. The SPL autoload stack continues to invoke the next loader until the class is defined/loaded, then it stops, irrespective of what a loader returns. It only matters whether the class definition is now available to PHP.





[DCOM-17] Add Collection::slice($offset, $length) Created: 08/Aug/10  Updated: 14/Jan/11  Resolved: 24/Aug/10

Status: Resolved
Project: Doctrine Common
Component/s: Collections
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1

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


 Description   

Since we are still at a point were bc breaks are potentially not so harming:

We need a slice() method on the Collection for forward compatibility, the support for large and very large collections using FETCH_EXTRA would heavily benefit from a method like this.

/**
 * Extract a slice of $length elements starting at position $offset from the Collection.
 * 
 * If $length is null it returns all elements from $offset to the end of the Collection.
 * Keys have to be preserved by this method.
 * 
 * @param int $offset
 * @param int $length
 * @return array
 */
public function slice($offset, $length = null);

The ArrayCollection implement would be:

public function slice($offset, $length = null);
{
    return array_slice($this->_elements, $offset, $length, true); // preserve keys
}


 Comments   
Comment by Benjamin Eberlei [ 08/Aug/10 ]

Updated preserve paragraph

Comment by Benjamin Eberlei [ 24/Aug/10 ]

Implemented

Comment by Jan Pieper [ 14/Jan/11 ]

Is there any reason why slice() returns an array although methods like filter() and map() return an instance of Doctrine\Common\Collections\ArrayCollection?





[DCOM-18] ArrayCollection::removeElement() violates Interface Contract Created: 09/Aug/10  Updated: 09/Aug/10  Resolved: 09/Aug/10

Status: Resolved
Project: Doctrine Common
Component/s: Collections
Affects Version/s: 2.0.0-BETA4
Fix Version/s: 2.0.0-RC1

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


 Description   

It return the element, not true.



 Comments   
Comment by Benjamin Eberlei [ 09/Aug/10 ]

Fixed





[DCOM-13] Better flexibility when the Annotation is created by the Parser Created: 24/Jul/10  Updated: 02/Aug/10  Resolved: 02/Aug/10

Status: Resolved
Project: Doctrine Common
Component/s: Annotations
Affects Version/s: None
Fix Version/s: 2.0.0-BETA4

Type: Improvement Priority: Major
Reporter: Fabien Potencier Assignee: Roman S. Borschel
Resolution: Fixed Votes: 0
Labels: None

Attachments: HTML File patch    

 Description   

The creation of the Annotation class is done at the end in Parser::Annotation(). It assumes that the Annotation class constructor takes an array of values. But if this is not the case, you are out of luck. So, I propose to move the logic of Annotation creation to is own method for better flexibility.



 Comments   
Comment by Jonathan H. Wage [ 31/Jul/10 ]

What is the reason your annotation class can't have a single argument array constructor?

Comment by Jonathan H. Wage [ 31/Jul/10 ]

Currently it is by design that Annotation classes take a single argument array constructor and the Reader and Parser are not designed for inheritance.

Comment by Fabien Potencier [ 01/Aug/10 ]

To sum up:

  • You force me to design my Annotation class is a certain way (for no obvious reason);
  • You don't want the Parser and Reader to be extensible.

So, basically, you say that the Doctrine Annotation library is not designed to be used outside Doctrine? That's fine, but then I will need to create my own Annotation component, which makes me sad.

Comment by Roman S. Borschel [ 01/Aug/10 ]

@"You force me to design my Annotation class is a certain way (for no obvious reason)"

It is a contract of the implementation, nothing more, nothing less. An annotation class must have a single argument array constructor. Would you feel better if there were an interface with such a constructor? Any contract always "forces" you to design your class that implements that contract in a certain way.

@"You don't want the Parser and Reader to be extensible."

They simply are not designed to be inherited right now which simply means we don't care about backwards compatibility with regards to subclasses when changing these classes and we're not documenting and telling people it is a good idea to subclass them. And frankly, inhertiance just to swap out the annotation construction process is a bad idea. It reveals & couples the subclasses to all the details of the parent class even though all they actually want is exchange the construction process. Moreover you would right now need to extend both, the parser and and reader to swap out the construction process. At least the parser would then need to become an (optional) constructor argument of a reader in order not to need to subclass the reader. Inheritance => strong coupling => hard to maintain backwards compatibility.

If there is strong desire to replace the annotation construction process, a factory (method/closure) approach would be much better.
Can you maybe reveal your concrete use-case? That an annotation class must have a single-argument array constructor is not an unreasonable requirement and you're really exaggerating if you're saying that this simple requirement makes the annotation library unusable outside of Doctrine. That is ridiculous. The Symfony Validator component already uses it.

Please try to be more constructive. Neither did you show concrete use-cases nor is your suggested solution a good idea as it is now because it requires 2 classes to be extended plus 1 constructor and 1 method to be overridden just to exchange the annotation construction process. This can surely be done simpler and will be done simpler if there is enough need for this enhancement.

Comment by Jonathan H. Wage [ 02/Aug/10 ]

This was fixed in http://github.com/doctrine/common/commit/66dad3e22205d812911adeb32b9f8bab8879d4b7





[DCOM-12] Annotation caching causes application instance mixups Created: 13/Jul/10  Updated: 13/Jul/10  Resolved: 13/Jul/10

Status: Resolved
Project: Doctrine Common
Component/s: Annotations
Affects Version/s: 2.0.0-BETA2, 2.0.0-BETA3, 2.0.0-BETA4
Fix Version/s: None

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


 Description   

Take a look at lib/Doctrine/Common/Annotations/AnnotationReader.php:137

 
    /**
     * Gets the annotations applied to a class.
     * 
     * @param string|ReflectionClass $class The name or ReflectionClass of the class from which
     * the class annotations should be read.
     * @return array An array of Annotations.
     */
    public function getClassAnnotations(ReflectionClass $class)
    {
        $cacheKey = $class->getName() . self::$CACHE_SALT;

        // Attempt to grab data from cache
        if (($data = $this->cache->fetch($cacheKey)) !== false) {
            return $data;
        }
        
        $annotations = $this->parser->parse($class->getDocComment(), 'class ' . $class->getName());
        $this->cache->save($cacheKey, $annotations, null);
        
        return $annotations;
    }

It uses the class name and a static salt to create a cache key. Actually, everything in that class uses a class name to assemble a cache key.

This makes it impossible to have mulitple instances of the same application in different states. Practically: it makes it impossible to have testing and staging, or staging and production versions on the same host if they use the same type of caching (which you sort of need in a staging environment).



 Comments   
Comment by John Kleijn [ 13/Jul/10 ]

Confused "fix" with "affects", sorry

Comment by Roman S. Borschel [ 13/Jul/10 ]

Why not just use the namespacing facilities of the cache drivers?

Comment by John Kleijn [ 13/Jul/10 ]

Cause I didn't read the caching docs?





[DCOM-6] Non existant namespace alias throws a PHP Notice Created: 27/May/10  Updated: 01/Sep/10  Resolved: 01/Sep/10

Status: Resolved
Project: Doctrine Common
Component/s: None
Affects Version/s: 2.0.0-BETA2
Fix Version/s: 2.0.0-RC1

Type: Bug Priority: Major
Reporter: Tim Nagel Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

@nonalias:Annot results in a php notice.



 Comments   
Comment by Tim Nagel [ 27/May/10 ]

Proposed tests and fix

http://github.com/merk/common/commit/65e8c10b74201c39dbe291c36230205d9b08ed65

Comment by Guilherme Blanco [ 31/Aug/10 ]

In commit: http://github.com/doctrine/common/commit/ad49a676269af368563bd9a848c904b81a825622

I fixed this issue.
The validation on unexistent classes cannot be done correctly, otherwise it'd conflict with phpDoc tags.

Comment by Tim Nagel [ 31/Aug/10 ]

What will your change do if there are multiple implementations of the Reader working on entities that dont have common namespaces, but still use namespaces?

Would it not make more sense to skip something that the Reader doesnt understand, rather than throwing an error?

(For example, Symfony2's validator system might have namespaced validators, which would then cause the 'Doctrine' reader to throw an exception)

Comment by Guilherme Blanco [ 01/Sep/10 ]

Yes, you're right...

I think we'll have to silently bypass unknown aliases... this makes debug harder, but we don't have any other option. =(

Reopening it

Comment by Benjamin Eberlei [ 01/Sep/10 ]

Fixed to skip the unknown alias annotation.





[DCOM-3] Public value property in Base annotation class Created: 22/Apr/10  Updated: 14/Jun/10  Resolved: 14/Jun/10

Status: Resolved
Project: Doctrine Common
Component/s: None
Affects Version/s: None
Fix Version/s: 2.0.0-BETA2

Type: Improvement Priority: Major
Reporter: Kirill chEbba Chebunin Assignee: Roman S. Borschel
Resolution: Fixed Votes: 0
Labels: None


 Description   

1) If our annotation doesn't need any parameters, it stll can accept one ('value').
2) We can intercept set and get of annotation properties via __set and __get methods which is not final, but not for 'value'.
Example of interception

class Annotation extends \Doctrine\Common\Annotations\Annotation
{

    private $someProperty;
    
    public function __set($name, $value)
    {
        $setMethod = 'set' . ucfirst($name);
        if (method_exists($this, $setMethod)) {
            return $this->{$setMethod}($value);
        }
        return parent::__set($name, $value);
    }
    
    public function __get($name)
    {
        $getMethod = 'get' . ucfirst($name);
        if (method_exists($this, $getMethod)) {
            return $this->{$getMethod}();
        }
        return parent::__get($name);
    }

    public function getSomeProperty()
    {
        //some logic
        return $this->someProperty;
    }

    protected function setSomeProperty($someProperty)
    {
        //some logic
        $this->someProperty = $someProperty;
    }
}


 Comments   
Comment by Benjamin Eberlei [ 22/Apr/10 ]

Why is this even relevant? can't you just ignore the value property?

Comment by Roman S. Borschel [ 22/Apr/10 ]

I think there is something not clear here. __get and __set on Annotation are not used to set or get values but to intercept calls to non-existant values.
Annotations are populated through their constructors.

Second, you don't need to extend from Annotation (not in HEAD at least). Any class can be used as an annotation as long as it has a constructor that takes an array with values.

Annotation values are set through the constructor, not through setters or public properties. This allows you to even use immutable classes as annotations:

class MyClass {
     private $a, $b;
     public function __construct(array $values) {
          $this->a = $values['a'];
          $this->b = $values['b'];
     }
    //... only getters...
}
/** @MyClass(a="Hello", b="World") */
class Other {
    //...
}

The default "value" will still be in $values['value'] if set. So this should work, too:

class MyClass {
     private $value;
     public function __construct(array $values) {
          $this->value = $values['value'];
     }
    //...
}
/** @MyClass("Hello World") */
class Other {
    //...
}
Comment by Roman S. Borschel [ 22/Apr/10 ]

So my suggestion would be: Just don't extend from Doctrine\Common\Annotations\Annotation and you don't have the public $value property.

Comment by Kirill chEbba Chebunin [ 22/Apr/10 ]

Oh, i got it. It was my miss, because there was subclass checking in previous versions.
Also, is it a good idea not to have some base class or interface for all annotations, may be it will be better to have an interface with a constructor? based on this restriction
"Any class can be used as an annotation as long as it has a constructor that takes an array with values". Of course using constructors in interfaces not really good, but if we have such restriction...
For example

interface SomeCommonAnnotationInterface
{
    public function __construct(array $values);
}




[DCOM-227] [GH-311] Improve UnexpectedValueException error message, add testcase. Created: 19/Dec/13  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

UnexpectedValueException::proxyDirectoryNotWritable() provides
information as to which directory was unwritable.

A TestCase is provided for the proxyDirectoryNotWritable() function.



 Comments   
Comment by Doctrine Bot [ 19/Dec/13 ]

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

Issue got closed by reporter





[DCOM-226] [GH-310] Improve UnexpectedValueException error message, add testcase. Created: 19/Dec/13  Updated: 18/Apr/14  Resolved: 18/Apr/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

UnexpectedValueException::proxyDirectoryNotWritable() provides
information as to which directory was unwritable.

A TestCase is provided for the proxyDirectoryNotWritable() function.



 Comments   
Comment by Doctrine Bot [ 19/Dec/13 ]

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

Comment by Guilherme Blanco [ 18/Apr/14 ]

Issue got closed by reporter





[DCOM-118] [GH-195] Add failing test to demonstrate parse error when @ is present in the description Created: 02/Oct/12  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

If someone can take this and fix the issue it'd be great. I couldn't figure it out at a quick glance and I don't really have time, but it's a pretty messed up bug and not so trivial to debug if you don't know what happens in the background so I'd say it's pretty important.



 Comments   
Comment by Philipp Scheit [ 02/Oct/12 ]

I digged a little deeper. The test case is a great one
The DocLexer cuts ut -1 position from the first @ (which is the @ in the @example.com). so that the lexer has to process:

o@example.com"
     * }
     *
     * @AnnotationTargetPropertyMethod("Bar")

So that the catchable pattern: ("(?:[^"]|"")*") matches here to greedy (it matches string in quotes):

"
     * }
     *
     * @AnnotationTargetPropertyMethod("

As a result the lexer does not catch the correct @ from the Annotation

I could not think of a fast fix for this. But maybe tomorrow.
(leaving quoted string pattern with an @ was a wrong idea)

Its not a workaround to do more or less cutting in the parser, because not-well-formed quoted strings would break anyway

Comment by Philipp Scheit [ 03/Oct/12 ]

can someone think of a case, where a string (in some annotation) has a newline in it? Otherwise the tests do not fail, when I leave the string matching pattern with a newline.
I still had another idea to restrict the position of a annotation more strictly to:

  • the beginning of a new line (\s**\s* before)
  • in another annotation

but the second is not solvable with the lexer itself and would transfer the quoted string matching to the parser, because it needs context.

I'll let seldaek pull, what I have (is this the right way?)

Comment by Marco Pivetta [ 03/Dec/13 ]

PR @ https://github.com/doctrine/annotations/pull/17

Comment by Doctrine Bot [ 25/Mar/14 ]

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

This fix was merged in latest master





[DCOM-104] Dump() has side-effects or is unreliable Created: 02/Aug/12  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug Priority: Major
Reporter: Tom Vogt Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: None
Environment:

Debian Squeeze, MySQL 5



 Description   

after setting a one-to-one bi-directional relationship, I am hunting a bug and trying this:

\Doctrine\Common\Util\Debug::Dump($this->lord, 1);
\Doctrine\Common\Util\Debug::Dump($this, 2);
\Doctrine\Common\Util\Debug::Dump($this->lord, 1);

The first Dump() shows $this->lord as being NULL.
The third Dump() shows it as NOT being null, just like the 2nd one also shows it as having a value.



 Comments   
Comment by Tom Vogt [ 02/Aug/12 ]

More analysis found the issue being caused by an overloaded setLord() method:

public function setLord($NewLord) {
// overwriting the setter because we also want to update the lord days counter
if ($NewLord!=$this->lord)

{ $this->lord->setFief(null); // this is the line causing the issue if ($NewLord) $NewLord->setFief($this); $this->lord = $NewLord; $this->lordDays = 0; }

return $this;
}

without the marked line, everything works as expected, but of course the inverse side doesn't get updated without it.

Comment by Tom Vogt [ 02/Aug/12 ]

it ate the newlines in the comment above. The problematic line is:

$this->lord->setFief(null);

i.e. the update of the inverse side.

Comment by Christophe Coevoet [ 07/Aug/12 ]

I confirm that the dump command has some side effects. It initializes the persistent collections too

Comment by Tom Vogt [ 11/Jan/13 ]

Could this for the time being be fixed with a notice in the documentation warning of possible side-effects of Dump() ?

Comment by Guilherme Blanco [ 21/Apr/14 ]

Debug is a utility that does expose the Proxy information as part of its rendering, thus providing your suggested documentation addiction right out of the bat.

Closing as won't fix.





[DCOM-92] CouchDB, MongoDB caches Created: 25/Dec/11  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

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


 Description   

Very simple persisntent caches for query/view results now that result cache is actually useful



 Comments   
Comment by Guilherme Blanco [ 21/Apr/14 ]

This support was already implemented some time ago.





[DCOM-151] [GH-233] [DocParser] Fix trying include classes if its must be ignored. Created: 10/Dec/12  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

I recreate pull request (add test). Without fix test is failure.



 Comments   
Comment by Doctrine Bot [ 03/Dec/13 ]

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

Comment by Marco Pivetta [ 03/Dec/13 ]

Provided a cleaned up version at https://github.com/doctrine/annotations/pull/18

Comment by Guilherme Blanco [ 21/Apr/14 ]

As of https://github.com/doctrine/annotations/commit/1ac675c80dfdf8164ca7d435770adf5bda7b2a68 this issue is now fixed.





[DCOM-161] [GH-243] Update composer.json Created: 11/Jan/13  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Add `provide` part as `doctrine/common` >=2.2,<2.4 has cache in it.



 Comments   
Comment by Doctrine Bot [ 23/Dec/13 ]

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

Issue got closed, so closing it here also. =)





[GH-298] Silence E_NOTICE warning: "Undefined index". (DCOM-216)

[DCOM-217] Merge DCOM-216 into 2.4.x Created: 16/Sep/13  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Sub-task Priority: Major
Reporter: Marco Pivetta Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Commit https://github.com/doctrine/common/commit/d9dea98243c733ff589aab10e321de4f14a63ab4 should be merged back into 2.4.x



 Comments   
Comment by Guilherme Blanco [ 21/Apr/14 ]

Backported as of https://github.com/doctrine/common/commit/b1a31ae3df2c18c24bec42e2cc32e3e4bedc07c7





Proxies return private properties in __sleep, which is not supported by PHP. (DCOM-175)

[DCOM-221] Merge DCOM-175 into 2.4 Created: 01/Dec/13  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Sub-task Priority: Major
Reporter: Marco Pivetta Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: proxy


 Description   

DCOM-175 is scheduled for 2.5, but I think it should be merged back in 2.4.x



 Comments   
Comment by Guilherme Blanco [ 21/Apr/14 ]

Merged as of https://github.com/doctrine/common/commit/870b42119983059192ff7ef054f2acb580b64dfe





[DCOM-184] [GH-266] Add a new method to use a filter before extracting the metadata Created: 12/Mar/13  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Invalid Votes: 1
Labels: None


 Description   

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

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

Message:

Hi

I have notice that, when you use the doctrine:mapping:convert and doctrine:mapping:import command in symfony, the filter is added after all the metadata are extracting from the database.
In this case, when you have a table with no primary key for example, you cannot extract the mapping for only one entity.

I have also made a pull-request into the doctrineBundle and doctrine2 to fix this issue.
https://github.com/doctrine/DoctrineBundle/pull/161
https://github.com/doctrine/doctrine2/pull/603

What are your thought about my issue?



 Comments   
Comment by Doctrine Bot [ 23/Dec/13 ]

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

Marking this issue as invalid in conformance with ORM resolution one: DDC-2335





[DCOM-152] [GH-234] Criteria filtering doesn't work with DateTime instance Created: 17/Dec/12  Updated: 21/Apr/14  Resolved: 21/Apr/14

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

Type: Bug 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 ludekstepan:

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

Message:

Filtering associations doesn't work with DateTime instance as a comparison value because filtering uses === operator. It works with SQL backed filtering, but not on PHP collection level.

```php
$criteria = Criteria::create()
>where(Criteria::expr()>eq("birthday", new \DateTime("1982-02-17")))
->orderBy(array("username" => "ASC"))
->setFirstResult(0)
->setMaxResults(20)
;
```



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

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

Comment by Guilherme Blanco [ 21/Apr/14 ]

As a resolution happened 3 months ago, this issue is now marked as won't fix.

Commit reference: https://github.com/doctrine/collections/commit/5e2d9cfe6a3d8eb2906f805a27c27ba3e5f2140c





[DCOM-225] [GH-309] DCOM-224 - Multiple backslashes in class names are not considered Created: 14/Dec/13  Updated: 19/May/14  Resolved: 14/Dec/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: None


 Description   

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

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

Message:

DCOM-224 - Multiple backslashes in the class name are not being normalized, causing simplified autoloaders to crash badly



 Comments   
Comment by Marco Pivetta [ 14/Dec/13 ]

Duplicate of DCOM-224

Comment by Doctrine Bot [ 19/May/14 ]

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





[DCOM-230] [GH-314] Implemented the suggested fix of DCOM-204 Created: 17/Jan/14  Updated: 19/May/14  Resolved: 03/Feb/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Johan Groth has reported "AnnotationDriver cannot find classes inside Phar files" (http://www.doctrine-project.org/jira/browse/DCOM-204) and suggested this fix.



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

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





[DCOM-232] [GH-315] Ability to use alternate dump functions Created: 04/Feb/14  Updated: 19/May/14  Resolved: 19/May/14

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

In most cases functions such as print_r provide much more readable output than var_dump. Some might also want to use var_export or write their own dump function. This should be a simple change that does not cause any BC breaks.



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

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





[GH-296] Proxies shouldn't serialize static properties in __sleep() (DCOM-212)

[DCOM-213] Merge DCOM-212 back into 2.4.x Created: 11/Sep/13  Updated: 21/May/14  Resolved: 21/Apr/14

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

Type: Sub-task Priority: Major
Reporter: Marco Pivetta Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: proxy


 Description   

Commit https://github.com/doctrine/doctrine2/commit/bb7f18ced76a553b00be563bed934c86d99afb73 should be backported into Doctrine 2.4.2



 Comments   
Comment by Guilherme Blanco [ 21/Apr/14 ]

Backported as of https://github.com/doctrine/doctrine2/commit/63c5758070dd39a9a4dcf6e97025f712850d7e7f

Comment by Thorry [ 21/May/14 ]

This issue seems to be incorrectly marked as resolved, the patch was not backported in the commit referenced and does not seem to be fixed at all.

Comment by Marco Pivetta [ 21/May/14 ]

It is resolved because it was merged into the release branch. Now it is included in tag 2.4.2





[DCOM-247] [GH-329] Remove dead config Created: 27/Jul/14  Updated: 27/Jul/14  Resolved: 27/Jul/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DCOM-248] [GH-332] 0.25 second wait for file caching Created: 28/Jul/14  Updated: 28/Jul/14  Resolved: 28/Jul/14

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

To deal with the issue of windows caching files when you wirte to them then close the handle I have added a 0.25 second pause between closing and moving the file. This is so that windows finishes handling writting to the file before trying to move it



 Comments   
Comment by Doctrine Bot [ 28/Jul/14 ]

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





[DCOM-246] [GH-328] Optimized imports Created: 27/Jul/14  Updated: 27/Jul/14  Resolved: 27/Jul/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 27/Jul/14 ]

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





[DCOM-192] [GH-274] Improve code on loadMetadata() to verify if class exists Created: 07/May/13  Updated: 11/Sep/14  Resolved: 08/May/13

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Improve code on loadMetadata() to verify if class exists, avoid a later warning when calling class_parents()

Instead throws a \RuntimeException if class doesn't exists.

Before changing code, just after add test:
```
1) Doctrine\Tests\Common\Persistence\Mapping\ClassMetadataFactoryTest::testGetMetadataForAbsentClass
class_parents(): Class Doctrine\Tests\Common\Persistence\Mapping\AbsentClass does not exist and could not be loaded

/home/www/common/lib/Doctrine/Common/Persistence/Mapping/RuntimeReflectionService.php:38
/home/www/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:257
/home/www/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:281
/home/www/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php:212
/home/www/common/tests/Doctrine/Tests/Common/Persistence/Mapping/ClassMetadataFactoryTest.php:44
```



 Comments   
Comment by Doctrine Bot [ 08/May/13 ]

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

Comment by Marco Pivetta [ 08/May/13 ]

Merged

Comment by Doctrine Bot [ 11/Sep/14 ]

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





[DCOM-186] [GH-269] ProxyGenerator eval() proxy code when $autoGenerate is true Created: 28/Mar/13  Updated: 13/Oct/14  Resolved: 25/Aug/13

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-2210 PHP warning in ProxyFactory when rena... Resolved

 Description   

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

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

Message:

ProxyGenerator eval() proxy code instead of writing it to disk when $autoGenerate is true.

Related to DDC-2210(http://www.doctrine-project.org/jira/browse/DDC-2210)

The idea of eval() the proxy code was suggested by @ocramius in response to the fact that in dev environment, concurrent file writes create errors.

This would also simplify the setup for a dev environment: no more proxy directory to create and make writeable.



 Comments   
Comment by Doctrine Bot [ 20/Aug/13 ]

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

Comment by Marco Pivetta [ 25/Aug/13 ]

Will be handled in DDC-2597 instead





[DCOM-209] [GH-291] [DDC-717] Add eval() and FILE_NOT_EXISTS strategies for proxy generation Created: 20/Aug/13  Updated: 13/Oct/14  Resolved: 20/Aug/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Reference
is referenced by DDC-2210 PHP warning in ProxyFactory when rena... Resolved

 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 20/Aug/13 ]

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

Comment by Doctrine Bot [ 22/Dec/13 ]

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





[DCOM-231] Lifecycle-Callback MappingExceptions for abstract functions in PHP >=5.4.8 Created: 26/Sep/13  Updated: 03/Feb/14  Resolved: 03/Feb/14

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

Type: Bug Priority: Minor
Reporter: Konrad Mohrfeldt Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Windows 7 x64, PHP 5.5.3



 Description   

Hi,

i noticed that in PHP starting with Version 5.4.8 the ReflectionService implementations returns a different result for the hasPublicMethod function than in PHP <= 5.4.7 when called on an abstract function. This prevents me from defining a lifecycle callback on an abstract function for a mapped superclass.

I think that at least for mapped supperclasses it should be checked if the class and the function is abstract so it can be assumed that every extending class has this function and it is in fact callable.

The bug was introduced by a bugfix in PHP 5.4.8.

cheers

konrad



 Comments   
Comment by Konrad Mohrfeldt [ 10/Oct/13 ]

i’ve created a pull request to fix this issue. see https://github.com/doctrine/common/pull/301

Comment by Konrad Mohrfeldt [ 10/Oct/13 ]

oh… and… this bug should probably be moved to common as it affects orm but is caused in common

Comment by Doctrine Bot [ 03/Feb/14 ]

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





[DCOM-215] Decouple DocParser from annotation classes Created: 15/Sep/13  Updated: 15/Sep/13  Resolved: 15/Sep/13

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

Type: Improvement Priority: Minor
Reporter: Yosmany Garcia Assignee: Benjamin Eberlei
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

It would be nice to have a "general purpose" docblocks parser, able to parse annotations without defining annotation classes



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

That is not our use case, take a look at the parser from phpdocumentor2, they can do that. Its standalone as well





[DCOM-197] [GH-280] Typo in MappingException Created: 10/Jun/13  Updated: 08/Sep/13  Resolved: 10/Jun/13

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

Type: Bug Priority: Minor
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 10/Jun/13 ]

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

Comment by Marco Pivetta [ 10/Jun/13 ]

Merged at https://github.com/doctrine/common/commit/2286642f9979a15a799e6fb6919579e8caf6ef11





[DCOM-179] Underscore at the end of a label is not working with annotations Created: 03/Mar/13  Updated: 06/Dec/13  Resolved: 06/Dec/13

Status: Resolved
Project: Doctrine Common
Component/s: Annotations
Affects Version/s: 2.3
Fix Version/s: 2.3

Type: Bug Priority: Minor
Reporter: exoon Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

apache2, php 5.4, mysql



 Description   

use Zend\Form\Annotation;

[...]

works:

* @Annotation\Options({"label":Namespace\Entity::LABEL})

or

* @Annotation\Options({"label":Namespace\Entity::_LABEL})

or

* @Annotation\Options({"label":Namespace\Entity::LA_BEL})

works not:

* @Annotation\Options({"label":Namespace\Entity::LABEL_})

Error message:

/vendor/doctrine/common/lib/Doctrine/Common/Annotations/AnnotationException.php:52

[Semantical Error] Couldn't find constant Namespace\Entity\::LABEL, property ...

The _ at the end is missing.



 Comments   
Comment by Marco Pivetta [ 03/Dec/13 ]

Provided a hotfix at https://github.com/doctrine/annotations/pull/19

Comment by Guilherme Blanco [ 06/Dec/13 ]

Implemented: https://github.com/doctrine/annotations/commit/0500074e2af1b3c9c6d6ea03d38fbd9f5ee7da71





[DCOM-128] RedisCache uses IGBINARY which is not always available Created: 20/Oct/12  Updated: 03/Dec/13  Resolved: 03/Dec/13

Status: Resolved
Project: Doctrine Common
Component/s: Caching
Affects Version/s: 2.3
Fix Version/s: 2.4

Type: New Feature Priority: Minor
Reporter: Sander Marechal Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

The RedisCache uses Redis::SERIALIZER_IGBINARY. See https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Cache/RedisCache.php line 47.

The problem is that the php Redis extension can be compiled without IGBINARY support. In that case, this code causes a fatal error because the constant does not exist.

The DotDeb package of php5-redis (often used on Debian systems) for example comes compiled without IGBINARY support.

The code should probably check if the constant exists. If not, the default to Redis::SERIALIZER_PHP



 Comments   
Comment by Peter Mitchell [ 24/Jun/13 ]

This appears like it will be fixed when 2.4 is released https://github.com/doctrine/cache/blob/master/lib/Doctrine/Common/Cache/RedisCache.php#L128

Comment by Marco Pivetta [ 03/Dec/13 ]

Already fixed in master





[DCOM-106] Add @todo and @fixme to AnnotationReader::$globalIgnoredNames Created: 12/Sep/12  Updated: 08/Sep/13  Resolved: 21/Nov/12

Status: Resolved
Project: Doctrine Common
Component/s: Annotations
Affects Version/s: 2.3
Fix Version/s: 2.4

Type: Improvement Priority: Minor
Reporter: Stephen Ostrow Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

I was wondering if you would consider adding @todo and @fixme

After doing some research, I'm not sure if @fixme is used anywhere other than being in Eclipse's PDT. However, @todo is definitely on the common tags of wiki page about PHPdoc as well as the phpDoc manual.

http://en.wikipedia.org/wiki/PHPDoc#Tags
http://manual.phpdoc.org/HTMLSmartyConverter/PHP/phpDocumentor/tutorial_tags.todo.pkg.html



 Comments   
Comment by Marco Pivetta [ 12/Sep/12 ]

Todo is already built in:
https://github.com/doctrine/common/blob/master/lib/Doctrine/Common/Annotations/AnnotationReader.php#L63

Comment by Stephen Ostrow [ 12/Sep/12 ]

Sorry about that. I normally write them as @TODO so the standout more. Then when I got that exception and started doing research I swear I had tried @todo. But now looking back, I bet I tried @todo and still got exceptions which were from other bugs I had going on. I guess we can close this unless anyone thinks @fixme should be in there as well.

But like I said in the description, I'm not sure if @fixme is a common or just from Eclipse.

Comment by Marco Pivetta [ 12/Sep/12 ]

Netbeans matches that one too

Comment by Paweł Nowak [ 20/Nov/12 ]

I've prepared a fix for this issue that makes both @fixme and @TODO ignored. Pull request: https://github.com/doctrine/common/pull/223.





[DCOM-103] Debug::toString issue with swapped parameters Created: 04/Aug/12  Updated: 08/Sep/13  Resolved: 28/Dec/12

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

Type: Bug Priority: Minor
Reporter: Oleg Namaka Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

Debug::toString has an issue with swapped parameters:

method_exists('__toString', $obj)

should be

method_exists($obj, '__toString')


 Comments   
Comment by Marco Pivetta [ 28/Dec/12 ]

Fixed in master @ https://github.com/doctrine/common/commit/301228e3a52d5259a341423daf75b25366895f17





[DCOM-100] bad filename for WincacheCahe Created: 02/Jun/12  Updated: 09/Jun/12  Resolved: 09/Jun/12

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

Type: Bug Priority: Minor
Reporter: Vladimír Náprstek Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None