[DCOM-233] Support for class constant annotations Created: 05/Feb/14  Updated: 24/Apr/14  Resolved: 24/Apr/14

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

Type: New Feature Priority: Minor
Reporter: Steve Müller Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

I need to read annotations for class constants which currently is not possible. Obviously there is a good reason for that because PHP lacks a native ReflectionConstant class. Still sometimes this would be really useful and there are custom reflection implementation out there such as the PHP-Token-Reflection library (https://github.com/Andrewsville/PHP-Token-Reflection) which provide a class for that purpose.
Now the problem is that there is no way to extend the annotation reader to add support for this purpose without having to duplicate a lot of code. This is due to the annotation parser being private in the annotation reader and Doctrine not providing a Target::TARGET_CONSTANT.
If we could decide on supporting this, there are two options IMO:

1. Provide a ReflectionConstant interface in the core and add getConstantAnnotation(ReflectionConstant $constant, $annotationName) and getConstantAnnotations(ReflectionConstant $constant) to the Reader interface in conjunction with an AbstractReader class to throw an exception when calling those methods (to preserve BC).

2. Extend AnnotationReader to provide a final protected getParser() method for better extensibility so that one can subclass the annotation reader without heavy code duplication.

In both cases an addition of Target::TARGET_CONSTANT would desirable.

Currently I have to workaround this is in a very ugly manner by extending \ReflectionClass to access ReflectionConstant objects provided by PHP-Token-Reflection library and wrapping them into objects that emulate \ReflectionProperty, just to be able to use the annotation reader.

Do you think there is any solution to this which we can provide in Doctrine annotations lib?



 Comments   
Comment by Marco Pivetta [ 22/Apr/14 ]

Guilherme Blanco was thinking of marking this as "won't fix". A constant, after all, is a constant, and it can be accessed no matter what.

Steve Müller can you clarify on the use-case? This is too much work for too little benefit IMO...

Comment by Steve Müller [ 22/Apr/14 ]

Marco Pivetta This is not about access but about being able to put metadata on class constants. My exact use-case is an Enum implementation through class constants where I can put things like readable values, ordinal numbers and such on each enum constants. I haven't thought of any other special use-cases and it might not be as common to be able to enrich class constants with metadata but still it would perfectly fit the annotation reader.
I see that this might cause too much work so if you decide on a "won't fix" I'll be fine with that.

Comment by Christophe Coevoet [ 22/Apr/14 ]

Given that PHP does not expose the docComment of constants, I would vote for marking it as "won't fix", as it would force us to require a separate parsing of the code to find the docComment

Comment by Guilherme Blanco [ 24/Apr/14 ]

No magic please... PHP is guilty here. We should propose docComment support there, then we add this support here.





[DCOM-205] Missing filenames from exception messages Created: 01/Jul/13  Updated: 24/Apr/14  Resolved: 24/Apr/14

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

Type: Improvement Priority: Minor
Reporter: Igor Wiedler Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   
  • Doctrine\Common\Persistence\Mapping\MappingException
  • "File mapping drivers must have a valid directory path, however the given path seems to be incorrect!"

This would be more helpful if it included a path name. There are probably other similar exceptions affected as well, so you might want to adjust others too.



 Comments   
Comment by Guilherme Blanco [ 24/Apr/14 ]

This issue seems to be already fixed in an earlier version. Closing as fixed.





[DCOM-168] ignoredAnnotationNames doesn't work in Annotation loop Created: 27/Jan/13  Updated: 24/Apr/14  Resolved: 24/Apr/14

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

Type: Bug Priority: Minor
Reporter: James S Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Mac OSX 10.6.8



 Description   

I'm just starting out with Doctrine, so my setup is a bit messy, but hopefully someone can figure out what is relevant from all my code.

Basically, I'm using Annotations on Doctrine ORM, and am integrating with Gedmo for several of their extensions.

I can run the CLI tool and update the schema, but when running via my web server, I'm getting the following error:

object(Doctrine\Common\Annotations\AnnotationException)[150]
  protected 'message' => string '[Semantical Error] The annotation "@Entity" in class Innertube\Models\Device was never imported. Did you maybe forget to add a "use" statement for this annotation?' (length=163)
  private 'string' (Exception) => string '' (length=0)
  protected 'code' => int 0
  protected 'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/common/lib/Doctrine/Common/Annotations/AnnotationException.php' (length=211)
  protected 'line' => int 52
  private 'trace' (Exception) => 
    array
      0 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/common/lib/Doctrine/Common/Annotations/DocParser.php' (length=201)
          'line' => int 592
          'function' => string 'semanticalError' (length=15)
          'class' => string 'Doctrine\Common\Annotations\AnnotationException' (length=47)
          'type' => string '::' (length=2)
          'args' => 
            array
              ...
      1 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/common/lib/Doctrine/Common/Annotations/DocParser.php' (length=201)
          'line' => int 533
          'function' => string 'Annotation' (length=10)
          'class' => string 'Doctrine\Common\Annotations\DocParser' (length=37)
          'type' => string '->' (length=2)
          'args' => 
            array
              ...
      2 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/common/lib/Doctrine/Common/Annotations/DocParser.php' (length=201)
          'line' => int 297
          'function' => string 'Annotations' (length=11)
          'class' => string 'Doctrine\Common\Annotations\DocParser' (length=37)
          'type' => string '->' (length=2)
          'args' => 
            array
              ...
      3 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/common/lib/Doctrine/Common/Annotations/AnnotationReader.php' (length=208)
          'line' => int 151
          'function' => string 'parse' (length=5)
          'class' => string 'Doctrine\Common\Annotations\DocParser' (length=37)
          'type' => string '->' (length=2)
          'args' => 
            array
              ...
      4 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/common/lib/Doctrine/Common/Annotations/CachedReader.php' (length=204)
          'line' => int 86
          'function' => string 'getClassAnnotations' (length=19)
          'class' => string 'Doctrine\Common\Annotations\AnnotationReader' (length=44)
          'type' => string '->' (length=2)
          'args' => 
            array
              ...
      5 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/AnnotationDriver.php' (length=205)
          'line' => int 61
          'function' => string 'getClassAnnotations' (length=19)
          'class' => string 'Doctrine\Common\Annotations\CachedReader' (length=40)
          'type' => string '->' (length=2)
          'args' => 
            array
              ...
      6 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php' (length=202)
          'line' => int 112
          'function' => string 'loadMetadataForClass' (length=20)
          'class' => string 'Doctrine\ORM\Mapping\Driver\AnnotationDriver' (length=44)
          'type' => string '->' (length=2)
          'args' => 
            array
              ...
      7 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php' (length=228)
          'line' => int 302
          'function' => string 'doLoadMetadata' (length=14)
          'class' => string 'Doctrine\ORM\Mapping\ClassMetadataFactory' (length=41)
          'type' => string '->' (length=2)
          'args' => 
            array
              ...
      8 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php' (length=228)
          'line' => int 205
          'function' => string 'loadMetadata' (length=12)
          'class' => string 'Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory' (length=64)
          'type' => string '->' (length=2)
          'args' => 
            array
              ...
      9 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/orm/lib/Doctrine/ORM/EntityManager.php' (length=187)
          'line' => int 268
          'function' => string 'getMetadataFor' (length=14)
          'class' => string 'Doctrine\Common\Persistence\Mapping\AbstractClassMetadataFactory' (length=64)
          'type' => string '->' (length=2)
          'args' => 
            array
              ...
      10 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/libraries/lerteco_framework/libraries/vendor-composer/doctrine/orm/lib/Doctrine/ORM/EntityManager.php' (length=187)
          'line' => int 682
          'function' => string 'getClassMetadata' (length=16)
          'class' => string 'Doctrine\ORM\EntityManager' (length=26)
          'type' => string '->' (length=2)
          'args' => 
            array
              ...
      11 => 
        array
          'file' => string '/Users/jshannon/Documents/Work/Projects/InnerTube/Repo/web/packages/lerteco_innertube/api/routes/devices.php' (length=108)
          'line' => int 16
          'function' => string 'getRepository' (length=13)
          'class' => string 'Doctrine\ORM\EntityManager' (length=26)

The call that initiates this is getRepository(), which IS NOT in the CLI.

I've tracked it down to the fact that DocParser is not getting the list of names to ignore.

Oddly, it gets it the first time that it's called by AnnotationReader. However, DocParser->parse() calls $this->Annotations(), which calls $this->Annotation(), calls $this->collectAnnotationMetadata(), which then creates a new parser

self::$metadataParser = new self();

and eventually parses it

self::$metadataParser->parse()

, but DOES NOT pass its ignorednames.

This seems like an oversight, but it clearly works for a lot of people. My configuration code is:

                if (self::$isDevMode) {
			$cache = new \Doctrine\Common\Cache\ArrayCache;
		} else {
			$cache = new \Doctrine\Common\Cache\ApcCache;
		}

		\Doctrine\Common\Annotations\AnnotationReader::addGlobalIgnoredName('package');

		AnnotationRegistry::registerFile(__DIR__ . "/vendor-composer/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/DoctrineAnnotations.php");
		\Gedmo\DoctrineExtensions::registerAnnotations();

		

		$annotationReader = new \Doctrine\Common\Annotations\AnnotationReader();
		$cachedAnnotationReader = new \Doctrine\Common\Annotations\CachedReader($annotationReader, $cache);



		$annotationDriver = new \Doctrine\ORM\Mapping\Driver\AnnotationDriver($cachedAnnotationReader, self::$namespaceArray);

		$config = new \Doctrine\ORM\Configuration;
		$config->setProxyNamespace('Proxy');
		$config->setAutoGenerateProxyClasses(self::$isDevMode); // this can be based on production config.
		// register metadata driver
		$config->setMetadataDriverImpl($annotationDriver);
		// use our allready initialized cache driver
		$config->setMetadataCacheImpl($cache);
		$config->setQueryCacheImpl($cache);

		if (defined('DIR_FILES_CACHE')) {
			$config->setProxyDir(DIR_FILES_CACHE);
		} else {
			$config->setProxyDir(sys_get_temp_dir());
		}

		// create event manager and hook prefered extension listeners
		$evm = new \Doctrine\Common\EventManager();

		$prefix = new TablePrefix(null);
		$prefix->useNamespace(true);
		$evm->addEventListener(\Doctrine\ORM\Events::loadClassMetadata, $prefix);


		$blameableListener = new \Gedmo\Blameable\BlameableListener();
		$blameableListener->setAnnotationReader($config->getMetadataDriverImpl()->getReader());
		//class_exists makes this usable with the command-line
		if (class_exists('\User') && ($u = new \User()) != false) {
			$blameableListener->setUserValue($u->getUserID());
		}
		$evm->addEventSubscriber($blameableListener);


		$timestampableListener = new \Gedmo\Timestampable\TimestampableListener();
		$timestampableListener->setAnnotationReader($config->getMetadataDriverImpl()->getReader());
		$evm->addEventSubscriber($timestampableListener);

		$config->addFilter('soft-deleteable', '\Gedmo\SoftDeleteable\Filter\SoftDeleteableFilter');


		return EntityManager::create($connectionOptions, $config, $evm);

and the entity is (which sets up the repository) is:

namespace Innertube\Models;
defined('C5_EXECUTE') or die('Access Denied.');

use Doctrine\ORM\Mapping as ORM;
use Doctrine\Common\Collections\ArrayCollection;
use Gedmo\Mapping\Annotation as Gedmo;

/**
 * @ORM\Entity(repositoryClass="DeviceRepository") @ORM\Table(name="Devices")
 * @Gedmo\SoftDeleteable(fieldName="deletedOn")
 **/
class Device {

and the repository is:

namespace Innertube\Models;
defined('C5_EXECUTE') or die('Access Denied.');

use Doctrine\ORM\EntityRepository;

class DeviceRepository extends EntityRepository {


 Comments   
Comment by Guilherme Blanco [ 24/Apr/14 ]

As of https://github.com/doctrine/annotations/commit/01ddf2cfa8aaf08d1f22d535471b62b039df1222 I added coverage to your issue which was already resolved earlier.





[DCOM-191] Wrong inflection for "identity" Created: 07/May/13  Updated: 22/Apr/14  Resolved: 22/Apr/14

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

Type: Bug Priority: Minor
Reporter: Tom Vogt Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

OS X and Linux, PHP 5.4.x



 Description   

console doctrine:generate:entities

For an association named "identities", the code generator creates the two methods
addIdentitie() and removeIdentitie() - apparently the inflector doesn't catch that it should be addIdentity and removeIdentity.



 Comments   
Comment by Guilherme Blanco [ 22/Apr/14 ]

As of https://github.com/doctrine/inflector/commit/dc02e4f73eb0938c35ddd60fa37825a98195a33f I added coverage to this issue and it does seem to work.





[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-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. =)





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





[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/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: 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





[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-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-28] Extract Common Persistance Interfaces Created: 13/Oct/10  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: Minor
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None

Attachments: File dcom_persistence.diff    
Issue Links:
Duplicate
is duplicated by DCOM-23 Add interface for ObjectManager Resolved

 Description   

I discussed this with jwage on symfony day cologne and this also came up during discussions with @dzuelke at IPC yesterday. So i hacked up a first patch for discussion that adds a Doctrine\Common\Persistance namespace and extracts the functionality all our 3 layers implement with regards to EntityManager/EntityRepository (and equivalents).

Additionally i think it might make sense to also add an interface "ObjectMetadata" that has several getters-only that allow access to the field, identifier and association mapping information. This stuff is not necessarly compatible across layers when returned as its "array" representation, but for libraries hooking into the metadata (symfony admin generator) this might not even be necessary.



 Comments   
Comment by Jonathan H. Wage [ 15/Feb/11 ]

Added the interfaces here https://github.com/doctrine/common/commit/59e6b8c6edcb271622923035b687a063c2b47ce8

I implemented them here in the mongodb-odm https://github.com/doctrine/mongodb-odm/commit/8d02e8439fb6737de1e23e1953a643858a8a6c68

and the ORM https://github.com/doctrine/doctrine2/commit/68a40996841b1dbec3b8de5c1038809e5db512b7

I think we can add a few more methods to ClassMetadata interface that are always gonna exist between the different persistence layers. Let me know what you think and what you want to add.

Comment by Guilherme Blanco [ 15/Feb/11 ]

Jon is working on this.

Comment by Lukas Kahwe [ 19/Mar/11 ]

CouchDB ODM also has DocumentRepositry::findMany(array $ids)
Should we add that to the interface?

Comment by Benjamin Eberlei [ 19/Mar/11 ]

No, that method is only on the repository because CouchDB doesn't need persisters (yet). Its not part of the interfaceable public methods.

Comment by Lukas Kahwe [ 19/Mar/11 ]

Not sure I understand. The method is used in DocumentRepository::findBy() as well as in PersistentIdsCollection::load. Seems unnecessary for that method to be public just for this. At any rate imho the method seems convenient and also allows for more efficient access in many RDBMS compared to the generic findBy($criteria) method. So it seems worthwhile adding it.

Comment by Benjamin Eberlei [ 20/Mar/11 ]

It doesn't matter what CouchDB uses internally on the DocumentRepository, i don't think this method is particularly useful in another context than CouchDBs use of Collections. In any case the method is just a proxy for findBy(array("id" => array(1, 2, 3, 4, 5, 6))); and i am not sure we need such a method on an interface just for convenience, Repository::find() use-case is much broader.

Comment by Lukas Kahwe [ 20/Mar/11 ]

Actually using findMany($ids) ias clearly more efficient in CouchDB than using findBy(array("id" => $ids));
The same applies to PHPCR, since going by the node path means you can go via the normal node API, rather than the search API.
So this is already 2 out of 3 examples and I do not know MongoDB enough to tell if they also have some specific API advantage.

Comment by Benjamin Eberlei [ 20/Mar/11 ]

Hm, you might be right. Ok, this should be included.

What i am still pondering with is adding array $orderBy and $firstResult, $maxResults to findOneBy() and findBy() and findAll().

@Jon: Would this be possible for MongoDB?

It would not be possible for all use-cases in CouchDB, but for some it can work.

Comment by Lukas Kahwe [ 20/Mar/11 ]

Just a super trivial pull to add this to the interface:
https://github.com/doctrine/common/pull/11

Comment by Lukas Kahwe [ 21/Mar/11 ]

also wondering if we want to include the idgenerator API in the interface?

Comment by Benjamin Eberlei [ 21/Mar/11 ]

Hm yes, i think that is necessary. At least the differentation between assigned and auto-generated ids is relevant for metadata queries.

Comment by Jonathan H. Wage [ 21/Mar/11 ]

Yes, findMany() is possible with MongoDB.

I think it would just be a proxy to:

public function findMany(array $ids)
{
    return $this->findBy(array('_id' => array('$in' => $ids)));
}
Comment by Benjamin Eberlei [ 21/Mar/11 ]

Hm, What is this syntax? This is not conforming to the EntityRepository interface.

The only two allowed methods are:

IN Query:

$ids = array(...);
findBy(array('_id' => $ids)); 

Equals = Query:

$ids = 1234;
findBy(array('_id' => $id)); 

Everything else is not portable accross implementations and should only be able through DocumentManager::CreateQuery* sort of apis.

Comment by Jonathan H. Wage [ 21/Mar/11 ]

To find by things in MongoDB you just give an array of key => value pairs. It gets passed straight through to MongoDB. The $in syntax is just soemthing mongodb supports. It's not anything specific to Doctrine.

Comment by Lukas Kahwe [ 30/Jul/11 ]

i want to heat this topic back up:

  • findMany()
  • id generator API
Comment by Guilherme Blanco [ 21/Apr/14 ]

Closing as this was already done previously.





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





Generated at Fri Apr 25 00:15:04 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.