[DCOM-203] Ability to set defaultManager on ManagerRegistry Created: 21/Jun/13  Updated: 21/Jun/13

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

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


 Description   

We (in the CMF) need to be able to change the "default manager" name at runtime, to enable switching, for example, between Production and Staging workspaces.

This is currently not possible because defaultManager is private and there is no setter.

See: https://github.com/doctrine/DoctrinePHPCRBundle/issues/73






[DCOM-80] Add common exceptions into Doctrine\Common Created: 19/Nov/11  Updated: 20/Dec/11

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

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


 Description   

Following the ZF and SF2 Standard for Exceptions we should have base exceptions in Common






[DCOM-77] add a method to force removal of any unmapped data on flush for a given object Created: 16/Nov/11  Updated: 16/Nov/11

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

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


 Description   

in order to ensure that any unmapped fields are set to their defaults or removed in the case of nosql right now there is no way to do this except with 2 flush calls: aka remove+flush, persist+flush

there should be some way to do this in one flush






[DCOM-67] Introduce immutable DateTime with __toString() Created: 27/Aug/11  Updated: 29/Jan/12

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

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


 Comments   
Comment by Benjamin Eberlei [ 27/Aug/11 ]

Implemented

Comment by Koji Ando [ 11/Jan/12 ]

Though it is implemented once on https://github.com/doctrine/common/commit/7140ad3ba0ba2a94238976dd7f310ff92b478c96,
the class is removed on https://github.com/doctrine/common/commit/f845c1e267abf9069422eba8addfa976bc8d8685.

I think this issue must be reopened.

Comment by Benjamin Eberlei [ 11/Jan/12 ]

Code was removed due to implementation problems.





[DCOM-73] CodeGeneration using Doctrine\Common\Persistence\Mapping\ObjectMetadata Created: 24/Oct/11  Updated: 03/Dec/13

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

Type: New Feature Priority: Major
Reporter: Benjamin Eberlei Assignee: Jonathan H. Wage
Resolution: Unresolved Votes: 1
Labels: None


 Description   

Currently we have tons of code in the ODM/ORMs regarding code generation that are ugly to extend and maintain. We should extract all them into a new component, for example named: doctrine-code-generator

  • It should be feed by only instances of Doctrine\Common\Persistence\Mapping\ObjectMetadata into a twig template.
  • A base template for an entity/document is shipped
  • Maybe ORM/ODM specific child templates or twig traits are necessary to handle writing annotations. This could also be done by adding hooks into the code-generation somehow.
  • Each entity of the user can provide its own template, for examples from a configurable directory "code_templates/Vendor.ProjectBundle.Entity.User.twig" to extend the base template and add own code.
  • As a perspective we should aim for 5.4 generating a trait so that you can have your entity "class User { use UserBase; }

    "






[DCOM-239] [GH-319] Add last modified time for metadata Created: 22/Mar/14  Updated: 28/May/14

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

This PR is part 1 of 2. Part 1 is for the doctrine/doctrine2 repository.

Read more in https://github.com/doctrine/doctrine2/pull/986



 Comments   
Comment by Christian Schmidt [ 28/May/14 ]

All comments raised in the pull request have been addressed. What is the next step?





[DCOM-250] [GH-335] add base events class Created: 28/Aug/14  Updated: 28/Aug/14

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

Hi,

All doctrine projects implements events. A lot of them are similars, but there is no base class defining common Events.

I tried to gathen them all in this PR. I looked into ```CouchDb-orm```, ```doctrine-orm```, ```doctrine-mongodb-odm``` and ```phpcr-odm```.

I only added events present in all packages, but CouchDB is the only one to not implement some events implemented in every other packages (```postPersist```, ```loadClassmetadata```, ```preFlush```, etc.).






[DCOM-256] [GH-340] Change tracking interface for object values Created: 21/Oct/14  Updated: 24/Oct/14

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

Currently, aside from the "NOTIFY" change tracking policy which takes long to implement on pre-existing entities, there is no atomic mechanism to allow tracking changes that take place inside de-serialized values of the DBAL\ObjectType once the entity has been loaded.

The UnitOfWork uses PHP's identity comparison operator (===) to compute the changed sets which yelds no change result when comparing pointers to the same object instance.

By implementing this interface, a serialized object may manage it's own dirty state and ensure the new values are persisted without affecting the entity's current change tracking policy.

The corresponding pull request on doctrine2 changes the following in Doctrine\ORM\UnitOfWork.php:
// skip if value haven't changed
if ($orgValue === $actualValue)

{ continue; }

into:

// skip if value haven't changed
if (($orgValue === $actualValue) && ( ! ($actualValue instanceof ObjectChangeTracking) || ( ! $actualValue->isDirty()))) { continue; }

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

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





[DCOM-254] [GH-338] Short gettter should work with associations Created: 22/Sep/14  Updated: 09/Jan/15

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:



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

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





[DCOM-279] Allow AbstractProxyFactory to load proxies by autoloading Created: 05/Mar/15  Updated: 05/Mar/15

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

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


 Description   

The AbstractProxyFactory supports several modes for proxy auto-generation. But, all of them, even AUTOGENERATE_NEVER, currently use an explicit require (or direct code evaluation for AUTOGENERATE_EVAL).

Being able to have the proxy factory skip the require would allow you to use autoloading to find and load the proxies when needed. Doctrine of course already has the concept of proxy autoloading, but only for use in deserialization and related contexts, but being able to skip the require here would allow autoloading to be used for Doctrine's normal loading of the proxies as well. This would allow alternative organizational structures, like storing and loading proxies in more than one directory, without requiring major changes to Doctrine or the tooling to support them.

It looks like the change could be as simple as a flag for the proxy factory, or an additional mode AUTOLOAD or AUTOGENERATE_NEVER_AUTOLOAD. Obviously this would be something users would need to opt-in for, as the default behavior currently present suffices for the majority of setups.






[DCOM-269] [GH-350] Made PATTERN_MATCH_ID_METHOD more flexible Created: 23/Jan/15  Updated: 25/Mar/15

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

PATTERN_MATCH_ID_METHOD match any valid function declaration, example:
function getId()

{return$this->id;}

 Comments   
Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DCOM-273] [GH-353] Support for Variadic arguments (PHP 5.6 - Argument unpacking) Created: 09/Feb/15  Updated: 26/Mar/15

Status: Open
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: Unresolved Votes: 0
Labels: php-5.6, proxy, proxy-generator, splat

Issue Links:
Dependency
is required for DCOM-272 Proxy generator doesn't understand sp... Resolved
Reference
relates to DCOM-272 Proxy generator doesn't understand sp... Resolved

 Description   

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

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

Message:

See http://www.doctrine-project.org/jira/browse/DCOM-272

It converts
```php
/**

  • @param ...$types
    */
    public function addType(...$types)
    {
    }
    ```

into
```php
/**

  • {@inheritDoc}

    */
    public function addType(...$types)

    { $this->__initializer__ && $this->__initializer__->__invoke($this, 'addType', array($types)); return parent::addType(...$types); }

    ```

This works but I don't know if the `__invoke` call is correct.



 Comments   
Comment by Doctrine Bot [ 09/Feb/15 ]

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

Comment by Doctrine Bot [ 26/Mar/15 ]

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





[DCOM-275] Collections\Expr\ClosureExpressionVisitor should support private properties as well as SQL visitors do. Created: 20/Feb/15  Updated: 14/Apr/15

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

Type: Bug Priority: Major
Reporter: Anton Serdyuk Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Reference
relates to DCOM-249 Criteria are unable to locate getters... Open
relates to DDC-2838 Leaky abstraction when applying Crite... Awaiting Feedback

 Description   

Given I have some entity method like this:

    public function hasNewComments()
    {
        $newComments = $this->comments->matching(
            Criteria::create()
                ->where(Criteria::expr()->eq('new', true))
        );

        return count($newComments) > 0;
    }

Where $this->comments is OneToMany collection.

If $this->comments is EXTRA_LAZY, then this code will always produce SQL query to database and always will work fine. But if it is not EXTRA_LAZY and appears to be loaded before (for eample count($this->comments) was called before), then this code will produce error "Trying to get private property Comment::$new from ClosureExpressionVisitor context".

I thins we should have something like reflection or \Closure::bind() stuff to get actual field value within ClosureExpressionVisitor regardless this field is private or public.

I know I can create getter getNew() or isNew(), but I believe this is known to be a good OOP practice to avoid unnecessary getters, and I am not sure collection api should make this decision for me.



 Comments   
Comment by Anton Serdyuk [ 14/Apr/15 ]

This issue is related to DCOM-249 and DDC-2838. I think this issue provides more clear understanding of the underlying problem than these two.





[DCOM-283] ArrayCollection::matching() and PersistentCollection::matching() keys mismatch Created: 14/Apr/15  Updated: 14/Apr/15

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

Type: Bug Priority: Major
Reporter: Anton Serdyuk Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have this code in my project

public function getAByB(B $b)
    {
        $as = $this->as->matching(
            Criteria::create()
                ->where(
                    Criteria::expr()->eq('b', $b)
                )
        );

        if (count($as) === 0) {
            throw new \Exception('Can not find a for b');
        }

        return $as[0];
    }

This code works fine when dealing with EXTRA_LAZY collections. But when I do not persist data in my tests and thereby use simple ArrayCollection for "as" property, this code fails. Because "ArrayCollection::matching()" method preserves keys here:

        if ($expr) {
            $visitor  = new ClosureExpressionVisitor();
            $filter   = $visitor->dispatch($expr);
            $filtered = array_filter($filtered, $filter);
        }

In theory this code should be rewritten this way:

        if ($expr) {
            $visitor  = new ClosureExpressionVisitor();
            $filter   = $visitor->dispatch($expr);
            $filtered = array_values(array_filter($filtered, $filter));
        }





[DCOM-286] [GH-367] Fix how namespace matching happens in SymfonyFileLocator Created: 08/May/15  Updated: 08/May/15

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

The problem was that namespace prefixes can overlap, and for classes
that would match more than one prefix only the first prefix would be
tested for. This meant that the findMappingFile and fileExists functions
would return different results depending on the order of the stored
prefixes.

For these methods to return the correct values the prefixes must be
listed in order of most to least specific. For example

['Vendor\Package\Entities', 'Vendor\Package\Entities\Blog']

would return the wrong result whereas

['Vendor\Package\Entities\Blog', 'Vendor\Package\Entities']

would return the correct one.

This changeset simply allows the class to be compared to more than one prefix, and updates one test as an exception message has changed.






[DCOM-287] [GH-369] [RFC] Load parent classes when loading metadata from cache Created: 22/May/15  Updated: 22/May/15

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

This can be done more neatly, but before putting more time in it I'd like to check if it's a good idea.
I came across this solution because we had a problem with Gedmo extensions when caching metadata in Redis, this is our scenario:
```
Class A extends B;
```
``Class B`` has a ``Gedmo extension`` mapped field.

On first request metadata for both ``Class A`` and ``Class B`` is cached in Redis.

On second request ``AbstractClassMetadataFactory`` loads ``Class A`` from Redis.

Gedmo extension loops through all ``Class A`` parents and calls method ``hasMetadataFor($parentClass)`` in ``AbstractClassMetadataFactory``, only ``Class A`` metadata has been loaded previously, therefore ``hasMetadataFor($parentClass)`` returns false, and ``Gedmo`` then skips the parent class.

Should Gedmo exension load the metadata for the parent class or should it be done as proposed in this PR?






[DCOM-276] [GH-356] Identifier getters now found in traits when generating proxies. Created: 23/Feb/15  Updated: 23/Feb/15

Status: Open
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: Unresolved Votes: 1
Labels: None


 Description   

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

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

Message:

Related to http://www.doctrine-project.org/jira/browse/DDC-2556

TODO: Add test cases



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

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





[DCOM-289] [GH-373] composer: bump to PHPUnit 4.7 Created: 10/Jul/15  Updated: 10/Jul/15

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:






[DCOM-290] [GH-374] getManagerForClass should try to retrieve the default manager Created: 21/Jul/15  Updated: 21/Jul/15

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

getManagerForClass should try to retrieve the default manager instead of the first one found in the list.






[DCOM-291] [GH-375] Allow access to variables in concrete implementations Created: 24/Jul/15  Updated: 24/Jul/15

Status: Open
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: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

It seems the variables in this abstract class should be protected instead of private so concrete implementations can modify them as needed.






[DCOM-189] Doctrine Proxies may conflict with interfaced constructors Created: 03/May/13  Updated: 26/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Harmen M Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The Doctrine ProxyGenerator generates for a proxy a constructor. The documentation of Doctrine states that the constructor is never called. For a project, I created a group of entities with a interfaced constructor in order to enforce a common interface. This results in a incompatible proxy and so a fatal error.



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

Cannot fix this - the constructor is required to override instantiation logic

Comment by Harmen M [ 03/May/13 ]

Edit: added the correct description. I accidentially submitted the form before editing the description.

Comment by Marco Pivetta [ 03/May/13 ]

Harmen M why do you have a constructor in an interface? That's a very bad practice, and it makes things quite hard to handle.

I can think of a workaround, but I first want to be sure there's a real advantage in changing the current implementation to use

unserialize()

just to handle this specific use case.

Comment by Benjamin Eberlei [ 03/May/13 ]

Adding __construct to an interface is an anti pattern and shouldn't be done.

Comment by Harmen M [ 03/May/13 ]

Ok, then I change my implementation.

But, maybe it is an idea to update the documentation of the ORM and state that constructor interfacing is not possible?
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/architecture.html

Comment by Marco Pivetta [ 18/Dec/13 ]

I actually had more requests for this feature on a similar project ( https://github.com/Ocramius/ProxyManager/issues/115 ).
I will mark this as feature request, but can't guarantee that it will get into Doctrine 2.x, since it may be a BC break.

Comment by Guilherme Blanco [ 24/Apr/14 ]

Creating interfaces with __construct ties your contract preventing extensibility points. This is nature of OOP and I do not consider this should be documented because it's (in-theory) expected that people have some level of knowledge in OO design when coding.

Closing this as invalid.

Comment by Marco Pivetta [ 24/Apr/14 ]

Re-opening.

While interfaced constructors are a known bad practice, changing constructor parameters is also a well known LSP violation (a minor one).

I'll keep tracking this, but I'm blocked by HHVM's missing Closure::bind() as of https://github.com/facebook/hhvm/issues/1203

Comment by Marco Pivetta [ 26/Mar/15 ]

Note: won't be solved in 2.5.0.

As a side-note, this was solved in ProxyManager meanwhile, but we can consider this change only for 3.0.x





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