[DDC-1302] orphan-removal does not work in XML Created: 29/Jul/11  Updated: 31/Jul/11  Resolved: 31/Jul/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.1
Fix Version/s: 2.0.7, 2.1.1
Security Level: All

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


 Description   

The check for $oneToManyElement->

{'orphan-removal'}

returns false, the right check would be $oneToManyElement['orphan-removal']



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

Fixed and merged into 2.0.x and 2.1.x branches.





[DDC-1276] Merging persistent collections broken if managed and merged collection are the same object Created: 13/Jul/11  Updated: 26/Jul/11  Resolved: 26/Jul/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.1
Fix Version/s: 2.0.7, 2.1.1
Security Level: All

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

FLOW3



 Description   

When FLOW3 maps request arguments to entities, it works on clones of the changed entities while entities, which are not affected by the request arguments stay the original objects. If the entity has a persistent collection which is not changed and therefore not cloned, the call to $repository->update() (which internally calls $em->merge()) eventually clears the $managedCol in $uow->doMerge() (line 1460 in current master), but if the $mergeCol is the same object, this is obviously wrong behavior as no related entities exist anymore in the entity to merge.

Made up example code (not sure if this simple example works as I have no test setup I could use for it)

/**
 * @entity
 * @scope prototype
 */
class A {}

/**
 * @entity
 * @scope prototype
 */
class B {
    /**
     * @var \Doctrine\Common\Collection\ArrayCollection<A>
     * @ManyToMany
     */
    public $relation;
}

$b = $repository->find(); // assume $b has some A in relation
$anotherB = clone $b;
$em->merge($anotherB);

After this relation of $b is empty



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

Fixed





[DDC-1257] Duplicate PHP methods generated from XML metadata lifecycle-callbacks Created: 08/Jul/11  Updated: 09/Jul/11  Resolved: 09/Jul/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.1
Fix Version/s: 2.0.7, 2.1.1, 2.2
Security Level: All

Type: Bug Priority: Minor
Reporter: Stephen Lang Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Zend Server 5.1.0, PHP 5.3.5, Apache 2.2.10, Linux (SUSE)



 Description   

If lifecycle callbacks are added to XML metadata like so:

	<lifecycle-callbacks>
		<lifecycle-callback type="prePersist" method="validate" />
		<lifecycle-callback type="preUpdate" method="validate" />
	</lifecycle-callbacks>

The validate() method will appear twice in an entity generated from this metadata.



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

Fixed





[DDC-1251] EntityGenerator uses non-existing constant T_AMPERSAND Created: 05/Jul/11  Updated: 09/Jul/11  Resolved: 09/Jul/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.1
Fix Version/s: 2.0.7, 2.1.1, 2.2
Security Level: All

Type: Bug Priority: Blocker
Reporter: Jordi Boggiano Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Irrelevant



 Description   

As per http://www.php.net/manual/en/tokens.php - the T_AMPERSAND token does not exist. I'm not sure what was the intent, but the entity generator fails on the following code:

            $elems = array_map(function($el) {
                return $el;
            }, $elems);

Due to the way notices are handled in Symfony, this basically stops the execution of the generator entirely. Not so great.

  [ErrorException]                                                                                            
  Notice: Use of undefined constant T_AMPERSAND - assumed 'T_AMPERSAND' in ./vendor/doctrine/lib/Doctrine/ORM/Tools/EntityGenerator.php line 454

Commenting out the offending line makes it work fine though, so I think it's just choking while expecting a function that takes args by reference or something.



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

Fixed





[DDC-1240] Missing exception message Created: 01/Jul/11  Updated: 12/Jul/11  Resolved: 12/Jul/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.x
Fix Version/s: 2.0.7, 2.1.1
Security Level: All

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


 Description   

Message in constructor should be assigned to exception message

Index: OptimisticLockException.php
===================================================================
— OptimisticLockException.php (revision 5)
+++ OptimisticLockException.php (working copy)
@@ -33,6 +33,7 @@

public function __construct($msg, $entity)

{ + $this->message = $msg; $this->entity = $entity; }

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

Fixed





[DDC-1230] entity state is not set to STATE_REMOVED when removing an entity Created: 27/Jun/11  Updated: 28/Jun/11  Resolved: 28/Jun/11

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

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


 Description   

The UnitOfWork never sets the state to STATE_REMOVED in the map when scheduling an entity for delete. This means that the UnitOfWork will never tell you that the entity is in STATE_REMOVED when asking for its state but will return STATE_MANAGED



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

Fixed





[DDC-1224] QueryBuilder delete issues CREATE TEMPORARY TABLE error on PostgreSQL Created: 22/Jun/11  Updated: 26/Jun/11  Resolved: 26/Jun/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.1
Fix Version/s: 2.0.7, 2.1
Security Level: All

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

PostgreSQL 8.4



 Description   

When I try to issue a delete an Class Table Inheritance Entity using QueryBuilder and I'm using schemas on tablename (for Postgres), I got the following error from postgres:

SQLSTATE[42P16]: Invalid table definition: 7 ERROR: temporary tables cannot specify a schema name

This occurs because Doctrine\ORM\Mapping\ClassMetadataInfo::getTemporaryIdTableName() returns just "$this->table['name'] . '_id_tmp'", and when my entity is declared with @Table(name="feed.tb_feed"), obviously I will got error.

Temporary tables are created in a special schema in Postgres, and I'm thinking to convert the tablename from the class metadata from feed.tb_feed to feed_tb_feed into the getTemporaryIdTableName method with a single str_replace. That works for Postgres, but I don't mind what can happen in another DBMS.

Any suggestions?



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

Fixed





[DDC-1211] Expr::literal problem with numeric value 0 Created: 16/Jun/11  Updated: 19/Jun/11  Resolved: 19/Jun/11

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

Type: Bug Priority: Major
Reporter: Gustavo Falco Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Apache 2.2.16
PHP 5.3.3
Ubuntu 11



 Description   

Hi,

I'm using master branch of Doctrine 2. Including an Expr with a numeric 0 value (not a string):

$value = 0;

$qb->expr()->gte($field, $qb->expr()->literal($value));

Expr::literal method will return an empty string ('') instead of '0', which causes that this expression be something like:

entity.myField >=  

instead of:

entity.miField >= '0''

This makes the query fail. Tracking the issue down I've found this on Expr\Base::add method:

    public function add($arg)
    {
         if ( ! empty($arg) || ($arg instanceof self && $arg->count() > 0)) {
            // If we decide to keep Expr\Base instances, we can use this check
            if ( ! is_string($arg)) {
                $class = get_class($arg);

                if ( ! in_array($class, $this->_allowedClasses)) {
                    throw new \InvalidArgumentException("Expression of type '$class' not allowed in this context.");
                }
            }

            $this->_parts[] = $arg;
        }
    }

The problem is that empty function returns true if you pass '0', so a call to Expr\Base::add would end on NOT adding '0' to $this->_parts array. That's why it finally returns ''.

I wanted to make the fix for this but I'm having issues running the phing build task. Which are the steps to follow to run the tests? Running phing build task I get on the "test" task:

Could not create task/type: 'nativephpunit'. Make sure that this class has been declared using taskdef / typedef.

Thanks!



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

Assigned to guilherme, i suppose we could change the !empty($arg) to $arg !== null ?

Comment by Benjamin Eberlei [ 19/Jun/11 ]

Fixed





[DDC-1195] The orm:convert-mapping is not configurable enough for Symfony2 Created: 05/Jun/11  Updated: 16/Aug/11  Resolved: 16/Aug/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.0.5
Fix Version/s: 2.0.7
Security Level: All

Type: Improvement Priority: Major
Reporter: Fabien Potencier Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

see https://github.com/symfony/symfony/issues/1119

fix here https://github.com/doctrine/doctrine2/pull/66



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

Already fixed.





[DDC-1189] PersistentCollection::clear() does not cause the collection to be initialized Created: 02/Jun/11  Updated: 19/Jun/11  Resolved: 19/Jun/11

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

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

Issue Links:
Duplicate
is duplicated by DDC-849 PersistentCollection::clear() doesn't... Resolved
Reference
relates to DDC-956 PersistentCollection::clear does not ... Resolved

 Description   

If clear() is called on an uninitialized PersistentCollection it needs to set the collection to be initialized.

An example of where this can cause problems:

  • Call clear() on an uninitialized collection
  • Check if an entity is in that collection using contains($entity)

This can return a false positive if the entity was previously in the collection.



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

Fixed.





[DDC-1022] Wakeup behavior difference between proxy and eager-loaded instance Created: 09/Feb/11  Updated: 09/Jul/11  Resolved: 09/Jul/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: Git Master
Fix Version/s: 2.0.7, 2.1.1, 2.2
Security Level: All

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


 Description   

When an object is reconstituted from the persistent storage the unserialize trick is used. That means __wakeup() is called, which is useful to do further initialization as needed.

If the object is lazy loaded a proxy is generated. That proxy is generated with new and thus no _wakeup() is called. When the proxy is eventually initialized still no call to _wakeup() is done, thus initialization code that is "usually" executed is not called when an object is lazy-loaded.

That is a semantical error.



 Comments   
Comment by Benjamin Eberlei [ 26/Feb/11 ]

__wakeup() shouldn't be used as per definition of an entity, http://www.doctrine-project.org/docs/orm/2.0/en/cookbook/implementing-wakeup-or-clone.html

For post initialization "postLoad()" should be used.

Comment by Karsten Dambekalns [ 26/Feb/11 ]

You write shouldn't be used, but that seems somewhat strange, given that the page you point to explicitly says However, it is quite easy to make use of these methods in a safe way by guarding the custom wakeup or clone code with an entity identity check, as demonstrated in the following sections.

And still the issue remains that eager-loaded instances created with the unserialize trick do call wakeup() (of course) but this does not happen when being lazy-loaded. Inconsistency, it screams...

Comment by Benjamin Eberlei [ 09/Jul/11 ]

I changed my mind, this is valid

Comment by Benjamin Eberlei [ 09/Jul/11 ]

Fixed in 2.0.7, 2.1.1 and in master





[DDC-849] PersistentCollection::clear() doesn't clear the collection Created: 31/Oct/10  Updated: 19/Jun/11  Resolved: 19/Jun/11

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

Type: Bug Priority: Minor
Reporter: Jáchym Toušek Assignee: Roman S. Borschel
Resolution: Fixed Votes: 1
Labels: None
Environment:

PHP 5.3.2
Doctrine 2 ORM soure codes form GitHub (2010-10-31)


Attachments: File User.php    
Issue Links:
Duplicate
duplicates DDC-1189 PersistentCollection::clear() does no... Resolved

 Description   

Clearing ManyToMany association doesn't work. I needed to clear the roles of the user (after form submit) and then add the checked roles. Also counting them doesn't work properly.

See the clearRoles method in the attachment.

//EDIT: Don't know if it's important but the association is bidirectional.



 Comments   
Comment by Roman S. Borschel [ 31/Oct/10 ]

Can you provide more context, like the code that is using the entity? Thanks.

Comment by Jáchym Toušek [ 05/Nov/10 ]

Code is something like this:

<?php
//$user is instance of UserEntity from the attachment
$user->clearRoles();

//$role is instance of RoleEntity which is in bidirectional association wirth user
//$role sometimes is one of those previously cleared (assume it is for this example)
if (...) {
    $user->addRole($role);
/* which calles this:
    public function addRole(RoleEntity $entity) {
        //contains method is false positive (the entity was removed by clear, but contains still returns TRUE)
        if (!$this->roles->contains($entity)) {
            $this->roles[] = $entity;
        }
        return $this;
    }
*/
}

//$em is instance of EntityManager
$em->flush();
?>

Ultimately count method returns wrong number and contains is false positive. I know that when i don't use the contains condition it works but that's not the point.

Comment by Benjamin Eberlei [ 13/Nov/10 ]

Sorry, but isn't then PersistentCollection::remove() and ::contains() wrong not clear()?

I think i have a good grasp on the issue and try to reproduce it.

Comment by Benjamin Eberlei [ 15/Nov/10 ]

I added a testcase tests/Doctrine/Tests/ORM/Functional/Ticket/DDC849Test.php that shows everything is working correctly. I cannot reproduce your problem.

Can you try to extend this phpunit testcase to show the failure?

I downgrade to trivial and detach the issue from RC1

Comment by Benjamin Eberlei [ 19/Jun/11 ]

Duplicate to DDC-1189

Comment by Benjamin Eberlei [ 19/Jun/11 ]

Fixed





Generated at Thu Sep 18 07:43:15 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.