[DDC-2794] the Paginator does not support arbitrary join Created: 14/Nov/13  Updated: 30/Sep/14  Resolved: 22/Sep/14

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

Type: Bug Priority: Major
Reporter: Christophe Coevoet Assignee: Marco Pivetta
Resolution: Fixed Votes: 3
Labels: paginator

Issue Links:
Dependency
depends on DDC-3233 [GH-1092] Arbitrary Join count walker... Resolved

 Description   

Using the following query with the paginator fails:

SELECT u
FROM User u
JOIN Message m WITH m.author = u
WHERE m.status = 'draft' -- a condition justifying the join

The CountWalker and the CountOutputWalker both throw a exception saying "Cannot count query which selects two FROM components, cannot make distinction"

This message is wrong (I can make distinction here. Only User is selected in the result set) and confusing (I spent some time finding the second FROM before figuring it was related to the use of an arbitrary join instead of an association join).



 Comments   
Comment by Pierre-Antoine Pinel [ 23/Dec/13 ]

Hi,

I have the same issue.

My query is : SELECT entity FROM W\XBundle\Entity\X entity LEFT JOIN Z\YBundle\Entity\Y y WITH y.x = entity LEFT JOIN y.v v WHERE v.name LIKE :like

Is there a way to fix this issue ? I really need this to work with the Paginator.

Best,

Comment by Christophe Coevoet [ 23/Dec/13 ]

Why changing the status to "Awaiting feedback" ? It is not waiting for a feedback of the reporter to check the fix. It is an open ticket which does not have a fix yet

Comment by Glen Ainscow [ 30/Sep/14 ]

Is this going to be back-ported to 2.4.x?





[DDC-2726] EventSubscriber PreUpdate Error Bug? Created: 06/Oct/13  Updated: 29/Sep/14

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

Type: Bug Priority: Major
Reporter: Nelson Ford Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: orm

Attachments: PNG File caca.png    

 Description   

Should this:

public function preUpdate(PreUpdateEventArgs $eventArgs)
{
    $entity = $eventArgs->getEntity();
    $em = $eventArgs->getEntityManager();
    $uow = $em->getUnitOfWork();

    if ($entity instanceof User) {
        if ($eventArgs->hasChangedField('finalStatus')) {
            $entity->setFinalStatusDate(new \DateTime('now'));
            $uow->recomputeSingleEntityChangeSet(
                $em->getClassMetadata("MyAdminBundle:User"),
                $entity
            );
        }
        if ($eventArgs->hasChangedField('membershipCode')) {
            $entity->setMembershipCodeDate(new \DateTime('now'));
            $uow->recomputeSingleEntityChangeSet(
                $em->getClassMetadata("MyAdminBundle:User"),
                $entity
            );
        }
    }
}

...result in this?

Catchable Fatal Error: Argument 3 passed to Doctrine\ORM\Event\PreUpdateEventArgs::__construct() must be an array, null given, called in /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php on line 995 and defined in /var/www/vendor/doctrine/orm/lib/Doctrine/ORM/Event/PreUpdateEventArgs.php line 47

I'm just setting a time stamp for two updated values. Dumping the 3rd argument in PreUpdateEventArgs.php on line 47 reveals an array of changes. I'm not sure if this is a bug or if I'm performing this simple operation incorrectly.



 Comments   
Comment by Marco Pivetta [ 17/Oct/13 ]

Can you write an integration test around it? Looks like the changeset is removed in a particular edge case, but it's hard to figure it out without a test.

Comment by Florin [ 29/Sep/14 ]

here, solve it





[DDC-3331] DQL parsing fail when using COUNT with "Simple Derived Identity" primary key Created: 29/Sep/14  Updated: 29/Sep/14

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

Type: Bug Priority: Major
Reporter: Mickael Zhu Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: bidirectional, count, onetoone, parser
Environment:

Mac osx Maverick
PHP 5.5.13
Nginx 1.6.0
Mysql 5.6.19



 Description   
Member.php

namespace DoctrineOrmTest\Assets\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="member")
 */
class Member
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer");
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\Column(type="string", nullable=true)
     */
    protected $name;

    /**
     * @var Student
     *
     * @ORM\OneToOne(targetEntity="DoctrineOrmTest\Assets\Entity\Student", mappedBy="member")
     */
    protected $student;

}

Student.php

namespace DoctrineOrmTest\Assets\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="student")
 */
class Student
{
    /**
     * @var Member
     *
     * @ORM\Id
     * @ORM\OneToOne(targetEntity="DoctrineOrmTest\Assets\Entity\Member")
     * @ORM\JoinColumn(name="id", referencedColumnName="id", nullable=false)
     */
    private $member;
}

When I use a oneToOne relation as primary key, the following dql request fail :

SELECT COUNT(a) FROM DoctrineOrmTest\Assets\Entity\Student a

I have the following message :

[Semantical Error] line 0, col 13 near 'a) FROM DoctrineOrmTest\Assets\Entity\Student': Error: Invalid PathExpression. Must be a StateFieldPathExpression

I can fix it with this workaround

SELECT COUNT(a.member) FROM DoctrineOrmTest\Assets\Entity\Student a

But it mess with one of my auto-generation script.






[DDC-3330] Bad Pagination - rows with sorted collection Created: 29/Sep/14  Updated: 29/Sep/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Thomas Lallement Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Ubuntu 12.04, PHP 5.5.3


Attachments: File DDC3330Test.php    

 Description   

I use the Doctrine Paginator to be able to have a correct pagination with collection.
I followed the documentation here:
http://doctrine-orm.readthedocs.org/en/latest/tutorials/pagination.html

It works well in most cases but there is a problem when ordering on a property of the entity + on an other property of the collection.

See the failing unit test I joined to this ticket.






[DDC-3329] Comment on clumn is passed when creating self-reference association Created: 28/Sep/14  Updated: 28/Sep/14

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

Type: Bug Priority: Minor
Reporter: Steve Todorov Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm
Environment:

PostgreSQL 9.1, possibly other databases as well.



 Description   

The example below will pass the comment from the column group_id to parent_id. Unfortunately that is not what I would like because the comment would confuse that parent_id has the same purpose as group_id which is not the case.

Group.php
class Group {

    /**
     * @var integer
     *
     * @ORM\Id
     * @ORM\Column(name="group_id", type="integer", options={"comment" = "This column is a relation to atable.z, btable.y, rtable.k, or whatever long comment we have here."})
     * @ORM\GeneratedValue(strategy="IDENTITY")
     */
    private $id;

    /**
     * @var string
     *
     * @ORM\Column(name="name", type="string", length=255)
     */
    private $name;

    /**
     * @var integer
     *
     * @ORM\JoinColumn(name="parent_id", referencedColumnName="group_id", nullable=true)
     * @ORM\ManyToOne(targetEntity="Acme\MyBundle\Entity\Group")
     */
    private $parent;

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

    /**
     * Get name
     *
     * @return string
     */
    public function getName() {
        return $this->name;
    }

    /**
     * Set name
     *
     * @param string $name
     *
     * @return Group
     */
    public function setName( $name ) {
        $this->name = $name;

        return $this;
    }

    /**
     * Get parent
     *
     * @return Group
     */
    public function getParent() {
        return $this->parent;
    }

    /**
     * Set parent
     *
     * @param Group $parent
     *
     * @return Group
     */
    public function setParent( Group $parent ) {
        $this->parent = $parent;

        return $this;
    }
}





[DDC-3120] Warning: Erroneous data format for unserializing PHP5.6+ Created: 11/May/14  Updated: 28/Sep/14  Resolved: 27/Aug/14

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

Type: Bug Priority: Critical
Reporter: Cornelis Brouwers Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: mapping, orm
Environment:

Webserver Apache/2.4.7 (Win32) OpenSSL/1.0.1e PHP/5.6.0beta2

and

PHP-CLI (Win32) PHP/5.6.0beta2


Issue Links:
Duplicate
is duplicated by DDC-3252 [GH-1109] DDC-3120 - PHP 5.6-RC3 comp... Resolved
Reference
is referenced by DDC-3156 [GH-1050] DDC-3120 -- Catch Reflectio... Resolved

 Description   

Hi all,

There seems to be something strange going on in the method newInstance() of the class \Doctrine\ORM\Mapping\ClassMetadataInfo.

The original class method looks like this:

\Doctrine\ORM\Mapping\ClassMetadataInfo#newInstance()

    {
        if ($this->_prototype === null) {
            $this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
        }

        return clone $this->_prototype;
    }

What happens now when a class that implements \Serializable is that a "Warning: Erroneous data format for unserializing" shows up and the function unserialize() returns false.

That is because a class that implements \Serializable is expected to have the letter 'C' in the serialize string instead of the letter 'O'.

I've made a quick work-around like this:

\Doctrine\ORM\Mapping\ClassMetadataInfo#newInstance()

    {
        if ($this->_prototype === null) {
            $this->_prototype = @unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
            if ($this->_prototype === false) {
                $this->_prototype = unserialize(sprintf('C:%d:"%s":0:{}', strlen($this->name), $this->name));
            }
        }

        return clone $this->_prototype;
    }

That seems to work in my isolated tests and with Symfony2 and Doctrine2 and FOSUserBundle together.

I've noticed this because the Model\User class from FOSUserBundle implements \Serializable.

I had to implement a check in Model\User class because when using 'C:%d:"%s":0:{}' the $serialized parameter of the unserialize method in the Model\User class is a empty string then.

That warning seems only to happen with PHP5.6+. PHP5.5.12 and below doesn't show that warning.

I hope someone can shine some light on this, thank you,

Cornelis.



 Comments   
Comment by Marco Pivetta [ 11/May/14 ]

Indeed, for PHP 5.4+ we should use

ReflectionClass#newInstanceWithoutConstructor()
Comment by Cornelis Brouwers [ 11/May/14 ]

Just tested it. That works as expected, far more better then the dirty hacks I did, thanks a lot!

Any idea when this would be implemented into the code?

Comment by Marco Pivetta [ 11/May/14 ]

Send a pull request and I'll merge it later today (we could also need a failing test with an entity implementing the Serializable interface)

Comment by Evert Harmeling [ 30/May/14 ]

Seems to be a problem in the latest PHP 5.4 version too.

https://github.com/doctrine/doctrine2/pull/1045/

Comment by Doctrine Bot [ 30/May/14 ]

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

Comment by Julian Reyes Escrigas [ 02/Jun/14 ]

I am facing this same error i have PHP 5.5.13, I'm using Symfony, Doctrine ORM and FOSUserBUndle

Comment by Marco Pivetta [ 02/Jun/14 ]

Julian Reyes Escrigas the patch landed in master (2.5.x) for now.

Comment by Marco Pivetta [ 02/Jun/14 ]

Merged via DDC-3147

Comment by Thomas Buhk [ 04/Jun/14 ]

When can we expect the version with this bugfix?

Comment by Anthony Rey [ 08/Jun/14 ]

Why don't you tag 2.4.3 version with this fix ? Because the error is already present in PHP 5.5.13 which is a stable version and it's a blocking issue when you're using FOSUserBundle for example. There is also no opened issue refering this version and the due date is in april.

Comment by Jovan Perovic [ 19/Jun/14 ]

I'm still seeing this bug, although my PHP_VERSION_ID is 50600

So, version based condition is no good...

Comment by Marco Pivetta [ 19/Jun/14 ]

The approach to be taken for 50600 is still under discussion in php-internals.

Comment by Cornelis Brouwers [ 20/Jun/14 ]

Hi all,

I've just downloaded PHP5.6RC1 and updated doctrine and the error is back indeed.

A little peek at the code starting on line 866 of file Doctrine\ORM\Mapping\ClassMetadataInfo.php shows this:

    public function newInstance()
    {
        if ($this->_prototype === null) {
            if (PHP_VERSION_ID === 50429 || PHP_VERSION_ID === 50513) {
                $this->_prototype = $this->reflClass->newInstanceWithoutConstructor();
            } else {
                $this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
            }
        }

        return clone $this->_prototype;
    }

As can be seen, PHP5.6 is out of the picture, it only checks for the exact versions 5.4.29 and 5.5.13.

So for the code to work correctly on PHP5.6 one can add PHP5.6 to the test condition, or just skip the test all together if you don't mind the old PHP5.3. According to PHP, ReflectionClass::newInstanceWithoutConstructor is available since PHP >= 5.4.0.

Greetings, Cornelis.

Comment by Marco Pivetta [ 21/Jun/14 ]

As I already pointed out, this is still being discussed in php internals. See http://news.php.net/php.internals/75009

This won't be dealt with in 5.6 until there's either a stable release or internals decides what has to be done.

Comment by Marco Pivetta [ 21/Jun/14 ]

Also, ReflectionClass#newInstanceWithoutConstructor() still doesn't cover the pre-existing "hack" using unserialize, so we're still waiting for a reliable API from PHP core.

Comment by Chase Noel [ 23/Jul/14 ]

Using PHP 5.6RC2 and ORM 2.4.4 I am still experiencing this issue. I have also tested with PHP 5.5.15 and I am still getting the issue. Do i need to be using a different build of ORM to have the fix applied?

Comment by pascall [ 23/Jul/14 ]

Hi,
I'm using 5.6.0beta3 and ORM 2.4.4 and i have the same probleme
Warning: Erroneous data format for unserializing .. in orm/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php line 872

and in current code in ClassMetadataInfo.php line 872 is :

public function newInstance()
{
if ($this->_prototype === null) {
if (PHP_VERSION_ID === 50429 || PHP_VERSION_ID === 50513)

{ $this->_prototype = $this->reflClass->newInstanceWithoutConstructor(); }

else {
$this->_prototype = unserialize(sprintf('O:%d:"%s":0:{}', strlen($this->name), $this->name));
}
}

return clone $this->_prototype;
}

Comment by Evert Harmeling [ 23/Jul/14 ]

As stated by Marco Pivetta; "This won't be dealt with in 5.6 until there's either a stable release or internals decides what has to be done.". And besides that 5.6 still is in development, not stable.
If you still want to use 5.6 you can fork the code and extend the 5.4 / 5.5 check to support 5.6.

Comment by Chase Noel [ 23/Jul/14 ]

5.6 has an RC which should mean a stable API, and that only bugs will be fixed before an official stable release?

Comment by Evert Harmeling [ 23/Jul/14 ]

Looking at http://news.php.net/php.internals/75966 it's still being discussed, and they are planning to have it fixed in RC3.

Comment by Marco Pivetta [ 23/Jul/14 ]

Internals still didn't get to a clear decision. Until then, we won't support 5.6 officially.

Comment by Ronan [ 24/Jul/14 ]

Same error encountered with PHP 5.5.13 (cli) (built: May 30 2014 10:43:29)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.3, Copyright (c) 2002-2013, by Derick Rethans

(PHP 5.5 installed via http://php-osx.liip.ch/)

Comment by Marco Pivetta [ 24/Jul/14 ]

Ronan what D2 version? We fixed it for 2.4.x (temporarily)

Comment by Ronan [ 24/Jul/14 ]

My bad: reading my composer.lock: doctrine/orm, v2.4.2, ref 0363a5548d9263f979f9ca149decb9cfc66419ab, "time": "2014-02-08 16:35:09"... Well.. this is was an old one !

`composer update` fixed it. Sorry for disturbing.

Comment by Chase Noel [ 12/Aug/14 ]

Im still getting this error running php 5.6RC2 and the dev-master(6ac19b04bfbd7a97aad5ed8c2abd6279ff5e0022) build of D2/orm. Am i missing something?

Comment by Marco Pivetta [ 12/Aug/14 ]

This was semi-fixed in PHP5.6-RC3, and it will be patched into ORM once doctrine/instantiator is out

Comment by Chase Noel [ 12/Aug/14 ]

Ok good to know. Thanks

Comment by Marco Pivetta [ 13/Aug/14 ]

Not yet fixed for PHP 5.6

Comment by Marco Pivetta [ 14/Aug/14 ]

Provided a hotfix proposal at https://github.com/doctrine/doctrine2/pull/1109 - please check it out with PHP 5.6.0-RC3 or later

Comment by Doctrine Bot [ 27/Aug/14 ]

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

Comment by Marco Pivetta [ 27/Aug/14 ]

Due to a new introduced dependency, this issue will only be solved for PHP 5.6 in 2.5.0 and later.

Comment by Doctrine Bot [ 28/Aug/14 ]

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

Comment by Dominik Zogg [ 10/Sep/14 ]

@ocramius would be great if there where backports for 2.4 and 2.3

Comment by Attila Bukor [ 28/Sep/14 ]

I agree with Dominik, we'd like to use the latest stable version and would need this patch.





[DDC-3328] [GH-1150] Improve Comparison::CONTAINS: allow to use custom position for % and _ wildcard characters Created: 28/Sep/14  Updated: 28/Sep/14

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

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 Fedik:

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

Message:

This pull prevent forced wrapping of the value in to `%`
and allow to use the custom position for `%` and `_` wildcard characters in case `Comparison::CONTAINS`

Allow to build the `contains` expressions like:
```php
Criteria::expr()->contains('myField', 'some string%');
Criteria::expr()->contains('myField', '%some string');
Criteria::expr()->contains('myField', '10%');
Criteria::expr()->contains('myField', 's_m_ string');
```






[DDC-3326] [GH-1148] [DWEB-118] Fixed small typo in documentation about extra lazy associations Created: 26/Sep/14  Updated: 27/Sep/14

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

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 naitsirch:

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

Message:

Fixed small documentation issue http://www.doctrine-project.org/jira/browse/DWEB-118



 Comments   
Comment by Doctrine Bot [ 27/Sep/14 ]

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





[DDC-3327] [GH-1149] Update Composite.php for HHVM compatibility Created: 26/Sep/14  Updated: 26/Sep/14

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

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 zhil:

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

Message:

Not sure, why this issue is not founded in unittests, but I got HHVM crushed with message
```
Fatal error: Stack overflow in ...../vendor/doctrine/orm/lib/Doctrine/ORM/Query/Expr/Composite.php on line 58
```
The same issue is being reported here
https://github.com/facebook/hhvm/issues/1747

@LinuxDoku proposed quick patch, which works great for me and its in this PR.

Just in case, if you wonder what trigger this error - here is my repository function, which trigger it
```
public function findOpenTeamTimeEntry($user)
{
$r = $this->createQueryBuilder("t")
->join("t.owner","u")
->where("t.dateEnd IS NULL")
->andWhere("u.id = :user_id")
>setParameter(":user_id",$user>getId())
->getQuery()
->getResult();
if(is_array($r) && count($r))

{ return $r[0]; }

else

{ return false; }

}
```






[DDC-3325] No exception thrown when passing invalid option to mapXToY() in ClassMetadataInfo Created: 25/Sep/14  Updated: 25/Sep/14

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

Type: Bug Priority: Minor
Reporter: Thomas Konrad Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: mapping, orm
Environment:

Symfony2, Windows 7, PHP 5.4



 Description   

I recently ran into the problem that I wrongly specified the `joinColumn` option passed to the method `mapManyToOne` in the `ClassMetadataInfo` class:

    $metadata->mapManyToOne(array(
        // ...
        'joinColumn'   => array(
            'name' => 'column_id',
        )
    ));

This would be the intuitive way to define that mapping, as with Annotations it is also called `JoinColumn` (but yeah I know, there could possibly be multiple `JoinColumn` definitions). The right way to do it is:

    $metadata->mapManyToOne(array(
        // ...
        'joinColumns'   => array(array(
            'name' => 'column_id',
        ))
    ));

The actual bad experience that I had as a developer here is that no exception was through even though I had definitely passed a wrong configuration option to the mapping function. In fact, nothing happended, the `joinColumn` option was just ignored. It would be great in this case if an exception would be thrown so that it is clear to the developer that there is something wrong.

Thanks!






[DDC-3324] [GH-1147] Extended the docs for mapping attributes precision and scale Created: 25/Sep/14  Updated: 25/Sep/14

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

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 naitsirch:

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

Message:

I for myself am always confused about precision and scale and have to lookup what is the numer of maximum digits and what is the number for digits right of the decimal point. Other people seem to have the same [problem](http://stackoverflow.com/questions/14940574/what-do-scale-and-precision-mean-when-specifying-a-decimal-field-type-in-doctrin).

So I have extended the docs to make it more clear.






[DDC-3323] Add user managed parameters bag to UnitOfWork Created: 24/Sep/14  Updated: 24/Sep/14

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

Type: Improvement Priority: Trivial
Reporter: Krzysztof Lechowski Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

User Story:
1. User has Article:Tags entities.
2. There is sort order attribute of a tag.
3. after any tag is removed, sort orders should be recalculated.

The intuitive place for it is postRemove, but technically we don't want to do any flushes in LifeCycle event. Below suggested solution is pass the handling of sort orders update to postFlush. For this sake postFlush needs to receive information from postRemove.

No global state is good idea I have 2 candidates:
1. Passet around event args
2. Unit of Work.

I'd prefer UnitOfWork because it's of more general use and more logical. This kind of information is unit-of-work context related. I'd like to call $unitOfWork->setParam('param_name', $value); and $unitOfWork->getParam('param_name');

Another person who stumbled upon the same situation, not sure how he handled it:

http://stackoverflow.com/questions/13095083/symfony2-doctrine2-throwing-index-error-when-flushing-the-entity-manager#answer-16701360






Generated at Tue Sep 30 19:54:11 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.