[DDC-1397] Accesing a OneToMany relation with Child Classes and OneToOne relations. Created: 29/Sep/11  Updated: 15/Oct/11  Resolved: 15/Oct/11

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

Type: Bug Priority: Major
Reporter: Gabriel Brunacci Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

Ubuntu 10.10 64bit
PHP 5.3.3
MySQL 5.1.49
Doctrine 2.1.2



 Description   

I am facing a small issue on Doctrine 2 that causes OneToOne relation needed to be part of the parent class. The error occurs when doing $content->getVersions() but not when doing $em->find("Model\Lantern\Content\Version", $id). The error message is:

Warning: Undefined index: summary in ORM/UnitOfWork.php:2012
Fatal error: Call to a member function setValue() on a non-object in ORM/UnitOfWork.php on line 2013

Error replication:

Simply by having a look at the model we can see what's causing the Bug, will avoid class annotations to make it simpler:

class Content{
    /**
    * @OneToMany(targetEntity="Version", mappedBy="content")
    */
    private $versions;
...
}

class Version{
    /**
     * @ManyToOne(targetEntity="Content", inversedBy="versions")
     * @JoinColumn(name="content_id", referencedColumnName="content_id")
     */
    private $content;
...
}

class Article extends Version{
    /** @OneToOne(targetEntity="Model\Lantern\Content\Fieldset\Summary", mappedBy="version", cascade={"persist", "delete"}) */
    private $summary;  
...
}

class Summary{
    /**
     * @OneToOne(targetEntity="Model\Lantern\Content\Version", inversedBy="summary")
     * @JoinColumn(name="version_id", referencedColumnName="version_id")
     */
    private $version;    
...
}

As you can see, Article::$summary targets Summary::$version, but Summary::$version targets Version::$summary. This in OOP is valid as Version is contained inside Article, so doing a downcasting will get Article::summary.

The reason I believe why using $em->find works is that $em->find already knows which child class is before doing map, and relations works fine.
On the other hand, when doing $content->getVersions(), Content::$versions targets Version, and looks like Doctrine does not resolve which child class it before mapping OneToOne relationshipg.

This bug doesn't occur with OneToMany or ManyToMany relationships.



 Comments   
Comment by Gabriel Brunacci [ 29/Sep/11 ]

A side but useful note: when I move @OneToOne relation to the parent class Version, The error doesn't happen.

Comment by Guilherme Blanco [ 04/Oct/11 ]

Should be the Summary::$version pointing to Article::$summary.

Your mapping is wrong conceptually in OOP, because you're referring a non-existing property of Version ($summary is only part of Article).
Please fix the issue and check out if the error still persist.

Comment by Benjamin Eberlei [ 15/Oct/11 ]

The mapping is wrong as guilherme said,

class Summary{
    /**
     * @OneToOne(targetEntity="Model\Lantern\Content\Article", inversedBy="summary")
     * @JoinColumn(name="version_id", referencedColumnName="version_id")
     */
    private $version;    
...
}




[DDC-1392] Merge for not initialized entity proxy object with set ID fails Created: 23/Sep/11  Updated: 26/Sep/11  Resolved: 25/Sep/11

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

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

Attachments: File DDC1392Test.php    

 Description   

Problem is that UnitOfWork::doMerge() calls ClassMetadata::getIdentifierValues() for the entity but that function doesn't have case for not initialized proxy. It just reads the Id properties from the object's reflection.

It should load the proxy or get the ID stored inside the proxy object or doMerge must initialize it maybe.



 Comments   
Comment by Aigars Gedroics [ 23/Sep/11 ]

I have taken the DDC353 test as the base for this test case.
Hopefully it works because I have executed it in slightly different version without the Doctrine tests environment.

Comment by Benjamin Eberlei [ 25/Sep/11 ]

Fixed

Comment by Aigars Gedroics [ 26/Sep/11 ]

I would put the changes inside the method getIdentifierValues not before it's execution.

Isn't it plausible that it is called with not initialized proxy from somewhere else?





[DDC-1381] Typo in ClassMetadataFactory Created: 19/Sep/11  Updated: 25/Sep/11  Resolved: 25/Sep/11

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

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


 Description   

https://github.com/doctrine/doctrine2/blob/2.1.x/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L343 `$className` should be `$class->name` this is fixed in master.



 Comments   
Comment by Benjamin Eberlei [ 25/Sep/11 ]

Fixed





[DDC-1337] Rollback doesn't work on transactional multi table update with mysql Created: 18/Aug/11  Updated: 25/Sep/11  Resolved: 25/Sep/11

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

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

Mysql 5.1.54-1ubuntu4



 Description   

When doing transactional multi table update using DQL query the changes are not rolled back after exception is raised after the update.

$em->transactional(function($entityManager) {
    $dql = "UPDATE ..."; // some multi table update DQL
    $query = $entityManager->createQuery($dql);
    $query->execute();

    throw new Exception();
});

This is because Doctrine executes "DROP TABLE" for temporary table created for the update but MySQL is doing commit right after DROP and CREATE statements automatically.

From PHP documentation:

"Some databases, including MySQL, automatically issue an implicit COMMIT when a database definition language (DDL) statement such as DROP TABLE or CREATE TABLE is issued within a transaction. The implicit COMMIT will prevent you from rolling back any other changes within the transaction boundary."



 Comments   
Comment by Aigars Gedroics [ 18/Aug/11 ]

I have done temporary workaround just by commenting out the line

165: $conn->executeUpdate($this->_dropTempTableSql);

from class Doctrine\ORM\Query\Exec\MultiTableUpdateExecutor.

I guess it is not correct solution for all platforms, is it?

Comment by Benjamin Eberlei [ 18/Aug/11 ]

This is a problem with MySQL and Inheritance. Not sure how we can fix this.

Comment by Aigars Gedroics [ 19/Aug/11 ]

Partial workaround is not dropping the temporary tables at all when on MySQL (at least) platform. These tables are session based and will be dropped automatically.

Still it can't be predicted when a temporary table will be needed inside the transaction, so we cannot make sure the CREATE TEMPORARY TABLE won't be called inside transaction after something has been updated already.

I think the best solution would be to raise exception when temporary table must be created or dropped while inside the transaction. Developer should call temporary table creation and removal manually before/after the transactional code part if it might be needed by the Doctrine.

In my opinion this is really important issue because no warning or exception was raised by the code in the case of rollback, still it didn't work as expected.

Comment by Aigars Gedroics [ 19/Aug/11 ]

Additionally needed to change temporary table name generation function ClassMetadataInfo::getTemporaryIdTableName() by adding incrementing property suffix:

return str_replace('.', '_', $this->table['name'] . '_id_tmp_' . $this->counter++);

after removed temporary table drop execution.

Comment by Benjamin Eberlei [ 27/Aug/11 ]

This seems very tricky:

  • A solution would mean: Open a new connection, create a "real" table. Use that from the original connection.
  • Another would be to create the temporary table BEFORE starting the transaction. However how do we know this?
  • An immediate and simple fix would be to throw an exception and prevent UPDATE and DELETE on joined table inheritance entities when run inside an transaction.
Comment by Benjamin Eberlei [ 04/Sep/11 ]

I wouldnt consider the php documentation to be a good source on MySQL.

If you read http://dev.mysql.com/doc/refman/5.1/en/implicit-commit.html

You get:

ALTER TABLE, CREATE TABLE, and DROP TABLE do not commit a transaction if the TEMPORARY keyword is used. (This does not apply to other operations on temporary tables such as CREATE INDEX, which do cause a commit.) However, although no implicit commit occurs, neither can the statement be rolled back. Therefore, use of such statements will violate transaction atomicity: For example, if you use CREATE TEMPORARY TABLE and then roll back the transaction, the table remains in existence.

Comment by Benjamin Eberlei [ 04/Sep/11 ]

Verified that transactions do not get committed when you CREATE or DROP temporary tables. That is also with MySQL 5.1.54 / Ubuntu

You seem to have some other kind of error or something?

Comment by Aigars Gedroics [ 04/Sep/11 ]

I'm almost sure that updated data was committed in my situation, but will check and provide the test case if possible.

Comment by Aigars Gedroics [ 19/Sep/11 ]

Found the problem!
It's because the Doctrine calls "DROP TABLE" instead of "DROP TEMPORARY TABLE" when getting rid of the temporary tables.

To prove this strange MySQL behaviour, such PHP script can be executed:

$pdo = new PDO('mysql:dbname=test', 
        'root', 
        'root', 
        array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));

$pdo->exec('DROP TABLE IF EXISTS a');
$pdo->exec('CREATE TABLE a (a INT) ENGINE = innodb');

$pdo->beginTransaction();

$pdo->exec('INSERT INTO a VALUES (1)');
$pdo->exec('CREATE TEMPORARY TABLE c (b int) ENGINE = innodb');
$pdo->exec('DROP TABLE c');
$pdo->exec('INSERT INTO a VALUES (2)');

$pdo->rollBack();

$st = $pdo->prepare('SELECT * FROM a');
$st->execute();
$row = $st->fetch(PDO::FETCH_ASSOC);

var_dump($row);

The dump should output "false", still the first inserted record is output.

This is actual at least on Mysql 5.1.54-1ubuntu4 and PHP 5.3.6.

The solution is trivial - use "DROP TEMPORARY TABLE" syntax instead.

Comment by Benjamin Eberlei [ 25/Sep/11 ]

Verified, even on mysql console client.

Thanks for investigating, big thumbs up.

Comment by Benjamin Eberlei [ 25/Sep/11 ]

Fixed.





[DDC-1367] Include path not passed to ClassLoader when autoloading Doctrine library from directory Created: 08/Sep/11  Updated: 25/Sep/11  Resolved: 25/Sep/11

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

Type: Bug Priority: Critical
Reporter: Lucas Brown Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Found while trying to write a Doctrine 2.1 module for Kohana.



 Description   

The bug is in ORM\Tools\Setup.php in the function registerAutoloadDirectory($directory), specificially the following line:

$loader = new ClassLoader("Doctrine");

Which should actually be:

$loader = new ClassLoader("Doctrine", $directory);

As it stands the actual directory location is not being passed to the ClassLoader while attempting to autoload the Doctrine from that specified directory. Under certain circumstances this causes loading to completely fail (although in cases where this function is being called from a parent directory to Doctrine this seems to go unnoticed - perhaps why this was not picked up sooner?)



 Comments   
Comment by Benjamin Eberlei [ 25/Sep/11 ]

Fixed and merged into 2.1.x





[DDC-1321] OrphanRemoval with bi-directional one-to-one on inverse sides Created: 06/Aug/11  Updated: 25/Sep/11  Resolved: 06/Sep/11

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

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


 Description   

Something is weird here, example: Remove CmsUser that has CmsAddress



 Comments   
Comment by Guilherme Blanco [ 06/Sep/11 ]

This commit fixes the issue: https://github.com/doctrine/doctrine2/commit/2cfc61db8445be0696003cda2f9c55d70bec6480

Please merge in 2.1. =)

Comment by Benjamin Eberlei [ 25/Sep/11 ]

Merged





[DDC-1031] Cascade ALL Case-Sensitive in Annotations Driver? Created: 13/Feb/11  Updated: 14/Sep/11  Resolved: 14/Sep/11

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

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


 Comments   
Comment by Guilherme Blanco [ 06/Sep/11 ]

Is this issue still valid?

In ClassMetadataInfo (around line 839), there's a prevention for this:

$cascades = isset($mapping['cascade']) ? array_map('strtolower', $mapping['cascade']) : array();

If not valid anymore, please close.

Comment by Guilherme Blanco [ 14/Sep/11 ]

No response, closing. If it is still valid, please reopen.





[DDC-869] repositoryClass poperty not possible on MappedSuperClass Created: 09/Nov/10  Updated: 08/Sep/11  Resolved: 08/Sep/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.0-BETA4
Fix Version/s: 2.1.2
Security Level: All

Type: Improvement Priority: Major
Reporter: John Kleijn Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

It would be both practical and intuitive to support the "repositoryClass" metadata property on a MappedSuperClass. Any subclasses would inherit that custom Repo class, optionally overriding it.

With the current situation one would have to add the property to every subclass, which may lead to a lot of duplicate meta data.



 Comments   
Comment by Guilherme Blanco [ 08/Sep/11 ]

Fixed by this commit https://github.com/doctrine/doctrine2/commit/7ebfc67d5a477380cd3ebac0e03e715d7a5f290c





[DDC-1356] DQL does not accept a parameter containing Entities Created: 01/Sep/11  Updated: 04/Sep/11  Resolved: 01/Sep/11

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

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


 Description   

Currently, it is impossible to provide an argument that is a collection of Entities. Example:

$userA = new CmsUser;
$userA->name = 'Benjamin';
$userA->username = 'beberlei';
$userA->status = 'developer';
$this->_em->persist($userA);
        
$userB = new CmsUser;
$userB->name = 'Roman';
$userB->username = 'romanb';
$userB->status = 'developer';
$this->_em->persist($userB);

$this->_em->flush();
$this->_em->clear();

$query = $this->_em->createQuery("SELECT u FROM Doctrine\Tests\Models\CMS\CmsUser u WHERE u IN (?0)");
$query->setParameter(0, array($userA, $userB));

Returns this error currently:

Object of class Doctrine\Tests\Models\CMS\CmsUser could not be converted to string


 Comments   
Comment by Guilherme Blanco [ 01/Sep/11 ]

Fixed in https://github.com/doctrine/doctrine2/commit/3b3186ee98392802a44118cd421a3530119aa7ea

Comment by Benjamin Eberlei [ 04/Sep/11 ]

Merged





[DDC-1354] ClassName proxy classes has includes '\' in front of namespace while other don't Created: 31/Aug/11  Updated: 04/Sep/11  Resolved: 01/Sep/11

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

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

All?



 Description   

The classname given to the EntityPersister by the ProxyFactory includes a backslash '\' in front of the namespace while normal classes and the proxy itself don't have this. This issue causes it impossible to persist proxyclasses, because of the string comparison in UnitOfWork::executeUpdates in the statement [ get_parent_class($entity) == $className ] this will do 'some\namespace\someclass' == '\some\namespace\someclass'

Aftter some debugging work it seems the '\' is trimmed of when getting the ClassMetadata while this isn't done when a the proxyfactory creates the proxy. So it is probably fixed by placing:

$className = ltrim($className, '\');

at the start of ProxyFactory::getProxy where '\' is actually a double backslash but that cannot be posted here



 Comments   
Comment by Guilherme Blanco [ 01/Sep/11 ]

That was not the issue, but it was a good starting point.
The actual problem was during mapping that targetEntity never ltrim'ed the entity name referred there.
Internally, Hydrator and UnitOfWork consume the ProxyFactory directly, so it lead to a wrong hashmap key for persisters.

By fixing the targetEntity value, everything is fixed. =)

https://github.com/doctrine/doctrine2/commit/ecc556f6872c0d44fff5678dc38e068422962aa0

Comment by Benjamin Eberlei [ 04/Sep/11 ]

merged into 2.1.x





[DDC-1350] Github-PR-112 by Ringosan: Mismatch in method signature when compared to method calls. Created: 30/Aug/11  Updated: 30/Aug/11  Resolved: 30/Aug/11

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

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


 Description   

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

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

Message:

Can either be changed here or in the method calls depending on your preference.



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

Fixed





[DDC-1225] Invalid SQL generated (extra comma) when joining to entity with composite PK Created: 23/Jun/11  Updated: 29/Aug/11  Resolved: 15/Aug/11

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

Type: Bug Priority: Critical
Reporter: Glen Ainscow Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: None

Attachments: Zip Archive models.zip     Zip Archive models.zip    

 Description   
            $qb->from('Tournaments_Model_StageBracketTeamRegistration', 'r')
               ->innerJoin('r.teamSelection', 'ts')
               ->innerJoin('ts.players', 'tsp')
               ->select('r, ts, tsp')
               ->where('r.stageBracket = ?1')
               ->andWhere('r.opponentIsReserve = false')
               ->orderBy('r.registrationDateTime')
               ->setParameter(1, $bracket);

Generates:

SELECT s0_.id AS id0, s0_.opponent_is_reserve AS opponent_is_reserve1, s0_.opponent_checked_in AS opponent_checked_in2, s0_.registration_date_time AS registration_date_time3, t1_.id AS id4,, s0_.type AS type5, s0_.stage_bracket_id AS stage_bracket_id6, s2_.team_selection_id AS team_selection_id7, t1_.team_id AS team_id8, t3_.team_selection_id AS team_selection_id9, t3_.player_id AS player_id10
FROM stage_bracket_team_registrations s2_
INNER JOIN stage_bracket_registrations s0_ ON s2_.id = s0_.id
INNER JOIN team_selections t1_ ON s2_.team_selection_id = t1_.id
INNER JOIN team_selection_players t3_ ON t1_.id = t3_.team_selection_id
WHERE s0_.stage_bracket_id = 22 AND s0_.opponent_is_reserve = 0
ORDER BY s0_.registration_date_time ASC

Note the 2nd comma after "t1_.id AS id4". TeamSelectionPlayer uses a composite PK. I have attached the relevant entity classes.



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

Fixed

Comment by Glen Ainscow [ 12/Aug/11 ]

Where can I find the changeset? Would it be easy for me to apply the changes to 2.1.0?

Comment by Glen Ainscow [ 12/Aug/11 ]

No worries, found the changes here: https://github.com/doctrine/doctrine2/commit/196632978cf39bc3914e14739767cb5b72a8df9d

Comment by Glen Ainscow [ 13/Aug/11 ]

This is still an issue:

            $qb->from('Tournaments_Model_StageBracketRegisteredPlayer', 'p')
               ->select('p')
               ->where('p.stageBracket = ?1')
               ->andWhere('p.player = ?2')
               ->setParameter(1, $bracket)
               ->setParameter(2, $player)
               ->getQuery()
               ->getOneOrNullResult();

Results in:

SELECT , s0_.stage_bracket_id AS stage_bracket_id0, s0_.player_id AS player_id1, s0_.game_account_id AS game_account_id2 FROM stage_bracket_registered_players s0_ WHERE s0_.stage_bracket_id = 14 AND s0_.player_id = 5
Comment by Guilherme Blanco [ 14/Aug/11 ]

Hi,

I attempted to create a failing test case for this issue, but either the provided entities are not enough or the issue is not reproducible anymore (it was already fixed in latest 2.2-DEV).

Could you please try to compile everything into a test case?

Cheers,

Comment by Glen Ainscow [ 15/Aug/11 ]

Hi Guilherme,

I'll attach 2 simple entities for testing. You can run the following query:

        $qb->from('App_Model_TestEntity1', 'te1')
           ->select('te1')
           ->where('te1.testEntity2 = ?1')
           ->setParameter(1, 0)
           ->getQuery()
           ->getOneOrNullResult();

I'm running this against 2.1.0 + this change.

Thanks.

Comment by Guilherme Blanco [ 15/Aug/11 ]

Fixed in this commit https://github.com/doctrine/doctrine2/commit/6857134f36097187ab2f0d932f4f1d9ffab12854

Thanks for the report!

Comment by Benjamin Eberlei [ 29/Aug/11 ]

Merged into 2.1.x





[DDC-1341] MultiTableUpdateExecutor does not bind parameters properly Created: 21/Aug/11  Updated: 28/Aug/11  Resolved: 28/Aug/11

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

Type: Bug Priority: Blocker
Reporter: Pavel Kučera Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Hi, I found really annoing bug in multi table update executor, it doesn't bind parameters properly. I have following structure of entities (afaik not really important, bug should appear with any class inheritance structure)

/**
* @entity
* @inheritanceType("JOINED")
* @discriminatorColumn(name="type", type="string")
* @discriminatorMap({"NodeEntity", forum = "ForumEntity"})
*/
class NodeEntity
{
  // ... some params
}

/**
* @entity
*/
class ForumEntity
{
/**
* @manyToOne(targetEntity="Author")
*/
private $lastPostAuthor;


/**
* @column(type="datetime")
*/
private $tLastPost;
// ... some params
}

And I'm trying to run following query

$qb = $this->entityManager->createQueryBuilder()
			->update('ForumEntity', 'f')
			->set('f.nPosts', 'f.nPosts + 1')
			->set('f.tLastPost', ':tLastPost')->setParameter('tLastPost', $post->getTCreation()) // $post->getTCreation() returns an instance of DateTime
			->set('f.lastPostAuthor', ':author')->setParameter('author', $post->getAuthor()) // $post->getAuthor() returns an instance of AuthorEntity

			->where('f.lft <= :left')->setParameter('left', $forum->getLft())
			->andWhere('f.rgt >= :right')->setParameter('right', $forum->getRgt())
			->andWhere('f.root = :root')->setParameter('root', $forum->getRoot());

		$qb->getQuery()->execute();

Which fails with "recoverable error", because Doctrine tries to convert value of parameter 'right' to datetime. I have learned why it does so, it is because of line 157 in already mentioned MultiTableUpdateExecutor - while parameters for the insert query are sliced of parameters from update clause, their types are not. And that is a bit problematic.

But that is not the only problem, if you look at line 161, the update query receives parameters as they were binded to QueryBuilder, so when I bind there an object, the update query receives the object instead of his identificator. That leads to error like "object ... could not be converted to string". And also, the update query does not receive any information about type of parameters, but I'm not sure if that is also a bug.

I'm not a native english speaker so if I explain things chaotically, just say so please, I'll try better .



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

Assigned to Guilherme

Comment by Guilherme Blanco [ 28/Aug/11 ]

Fixed since this commit: https://github.com/doctrine/doctrine2/commit/e7f471ef3e1ffa5e180623115a45f423572549e4

Comment by Benjamin Eberlei [ 28/Aug/11 ]

Merged into 2.1.x





[DDC-1348] UnitOfWork::getEntityState bug with pre insert id generators Created: 28/Aug/11  Updated: 28/Aug/11  Resolved: 28/Aug/11

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

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


 Description   

UnitOfWork::getEntityState checks for the state by using the id as one indicator. This can be created using a pre-insert generator though, which means the entity does not have to exist at all, even though an id was already generated.



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

Fixed





[DDC-1113] getCommitOrder misses some relations when used with Inheritance and self-referencing field Created: 12/Apr/11  Updated: 27/Aug/11  Resolved: 27/Aug/11

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

Type: Bug Priority: Critical
Reporter: Illya Klymov Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Let's assume we have an Entity class "ParentClass", which uses a single table inheritance with child classes "ChildOne" and "ChildTwo".
"ParentClass" also have one-to-one unidirectional association with "FooBar" class named "foobar", and a self-referencing association called "parent"

We construct entity of "ChildOne" type, filling "foobar" link with new FooBar object. The same action is made for entity of "ChildTwo" type.
Entity of "ChildOne" type is persisted and flushed.

At this point getCommitOrder builds a commit order. ChildOne <---> FooBar link appears in dependency graph because of "foobar" association.
While processing assocs it reveals "parent" assoc in parent class and builds following links in dependency graph:
ChildOne <---> ChildOne
ChildOne <---> ChildTwo

After that "ChildTwo" entity is persisted and flushed. At this point commit calculator thinks it already have "ChildTwo" in it's storage so no assoc calculation are made for "childTwo" class

If we attemp to delete "ChildTwo" class flush() will fail because of missing link "ChildTwo <-----> Foobar" assoc



 Comments   
Comment by Illya Klymov [ 12/Apr/11 ]

I've opened pull request https://github.com/doctrine/doctrine2/pull/47 with my fix to this issue. I'm new to doctrine development so feel free to make any suggestions how to improve it

Comment by Benjamin Eberlei [ 26/Jul/11 ]

Increased priority, i should really look at this one soon!

Comment by Benjamin Eberlei [ 06/Aug/11 ]

The test with this pull request does not fail even without the applied patch.

Comment by Benjamin Eberlei [ 06/Aug/11 ]

sorry my bad, ran this with SQLite (Which has no FKs)

Comment by Benjamin Eberlei [ 27/Aug/11 ]

Fixed, simplifed a bit since one part was not necessary and this hits performance quite significantly





[DDC-1306] Possible bug in CommitOrderCalculator Created: 30/Jul/11  Updated: 27/Aug/11  Resolved: 27/Aug/11

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

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

Ubuntu 11.04. PHP 5.3.5. MySql 5.1.54



 Description   

(I'm not sure it's a bug, it might be the way I configured Doctrine)

Sometime Doctrine fails to calculate the right commit order, and then it fails when flushing because some db constraints are failing. I hacked the CommitOrderCalculator so that it would print the list of the dependencies, and this is what I found:
(I don't have time to write code now, so I'll try to explain it with words. If it's not clear I'll find some time tomorrow to hack together a test)

Let's say that we have the class User. The class user is connected to other classes (News, Comment, Post) with an unidirectional relation, so that User doesn't know anything about the other class.

Let's say we create a User and we save it. The CommitOrderCalculator will calculate the dependencies on User. This is a partial list, some dependencies won't be there (not sure whether it's because they haven't been loaded yet, whether it's because they are not part of the UnitOfWork or whether it's because User doesn't know about them) ***

Let's say that later, in the same request, we create a News. CommitOrderCalculator will calculate the dependencies for News. However, for User it will use the cached dependencies, and it won't realize that now User is required for News.

      • Could it be a configuration problem?
        Are the dependencies supposed to be incomplete? (it seems reasonable as long as they are calculated for a single UnitOfWork, but it seems wrong if the dependencies are shared with multiple transactions)
        Or am I loading the classes in the wrong way?

Code references:
UnitOfWork::getCommitOrder line ~840
The class is added to $newNodes (the array used to calculate dependencies) only if the CommitOrderCalculator doesn't know the class already

CommitOrderCalculator::getCommitOrder line ~ 83
After getting the order _sorted and _nodeStates are reset, while _classes and _relatedClasses are not.

Basically UnitOfWork register the class only once, and CommitOrderCalculator doesn't forget about the class when the UnitOfWork ends.

Possible fix:

  • Resetting _classes and _relatedClasses seem to fix the problem, but I don't know what was the rationale for not doing it, so I'm unclear whether it's the right think or not.

Example:
Dependencies calculated with the current code
Visiting Users\Model\User
+ Forum\Model\Forum
Visiting Forum\Model\Forum
+ Forum\Model\Forum
+ Forum\Model\Topic
Visiting Forum\Model\Topic
+ Forum\Model\Topic
+ Forum\Model\Topic
Visiting Forum\Model\Post
+ Forum\Model\Forum
+ Forum\Model\Topic
+ Forum\Model\Topic

Dependencies calculated with the reset
Visiting Forum\Model\Topic
+ Forum\Model\Post
Visiting Forum\Model\Post
+ Forum\Model\Topic
+ Forum\Model\Topic
+ Forum\Model\Forum
Visiting Forum\Model\Forum
+ Forum\Model\Topic
+ Forum\Model\Forum
Visiting Users\Model\User
+ Forum\Model\Topic
+ Forum\Model\Topic
+ Forum\Model\Post
+ Forum\Model\Post
+ Forum\Model\Forum



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

Verified.

The Calculator is only populated partially because otherwise it had to calculate the dependencies for all classes all the time, caused through a riffle effect.

Comment by Benjamin Eberlei [ 27/Aug/11 ]

Fixed





Generated at Tue Jul 29 02:50:06 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.