Doctrine\ORM\Query\Exec\MultiTableUpdateExecutor works incorrect with query cache enabled.
I execute two similar update-queries with different parameters, but the second query is never executed in database.

There is todo-task in code:

//FIXME (URGENT): With query cache the parameter is out of date. Move to execute() stage.

This is important issue. Much time spent in debugging.

orphanRemoval does not work with oneToOne.
Im getting "duplicate entry" errors after replacing the oneToOne object.
Doctrine seems to insert the new data before removing the old one.
if i remove the unique constraint by hand in the database it works.

/*
Error:
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'UNIQ_9D8DDB05579B502F'
*/

/*
Contact:
  type: entity
  table: contact
  fields:
    _id:
      id: true
      type: integer
      unsigned: true
      nullable: false
      generator:
        strategy: AUTO
      column: id
  oneToOne:
    _standingData:
      targetEntity: StandingData
      mappedBy: _contact
      cascade: ["persist", "merge", "remove"] 
      orphanRemoval: true
*/

class Contact
{
    private $_id;
    private $_standingData;

    public function newStandingData(StandingData $sd)
    {
        $this->_standingData = $sd;
        $sd->setContact($this);
    }
}

/*
StandingData:
  type: entity
  table: standing_data
  fields:
    _id:
      id: true
      type: integer
      unsigned: true
      nullable: false
      generator:
        strategy: AUTO
      column: id
  oneToOne:
    _contact:
      targetEntity: Contact
      inversedBy: _standingData
      joinColumns:
        contact_id:
          referencedColumnName: id
          onDelete: cascade
*/

class StandingData
{
    private $_id;
    private $_contact;

    public function setContact(Contact $c)
    {
        $this->_contact = $c;
    }
}

// Create new Contact
$contact = new Contact();
$contact->newStandingData(new \StandingData());
$em->persist($contact);
$em->flush();

// Try to change StandingData
$contact->newStandingData(new \StandingData());
$em->flush();

Serialization breaks because the cache driver tries to serialize the ClassMetaData instance containing a simplexml element:

Doctrine\ORM\Mapping\ClassMetadata Object
(
    [fieldMappings] => Array
        (
            [version] => Array
                (
                    [fieldName] => version
                    [type] => integer
                    [columnName] => version
                    [version] => SimpleXMLElement Object
                        (
                            [0] => true
                        )

                    [default] => 1
                    [declared] => path to entity
                )

The fix is simple change in the columnToArray method in the XML driver class:

changing:

$mapping['version'] = $fieldMapping['version'];

to:

$mapping['version'] = $this->evaluateBoolean($fieldMapping['version']);

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

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

Message:

https://github.com/doctrine/dbal/commit/88c1975dda492f3dd93cddea71ebacb40ed7efa5 change seems to make unable to use ``findOneBy()`` method because of ``doctrine_rownum`` added to query.

``findOneBy()`` throws:

>Notice: Undefined index: doctrine_rownum in
...\vendor\doctrine\orm\lib\Doctrine\ORM\Internal\Hydration\SimpleObjectHydrator.php line 183

Given:

• you have a non initialized collection (association between entities)
• you have loaded some entities that are in that collection and changed some fields (without flushing)

If you do a matching using a Criteria on the collection (http://docs.doctrine-project.org/en/latest/reference/working-with-associations.html#filtering-collections), then the Criteria will be executed through a DB query. But the fields you changed are not updated in the DB, so if you filter/order on those fields, then the result of the filter() will be incorrect.

However, if your collection was initialized, the Criteria matching will be done in memory on the ArrayCollection and the result will be correct.

So we have the problem for Criteria filtering on non-initialized collections.

This issue is created automatically through a Github pull request on behalf of jean-gui:

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

Message:

Doctrine should not allow to add an empty Expr to another one. Current code allows that, which can lead to wrong DQL.
Example 1:
```php
$andExpr = $this->_expr->andx();
$andExpr->add($this->_expr->andx());
$andExpr->add($this->_expr->eq(1, 1));
echo $andExpr;
```
will output:
```sql
AND 1 = 1
```
instead of:
```sql
1 = 1
```

Example 2:
```php
echo $andExpr;
```
will output:
```sql
AND AND
```
instead of nothing.

IRC log of the discusion on #doctrine:
```irc
[jeudi 7 mars 2013] [14:36:18] <Jean-Gui> hi
[jeudi 7 mars 2013] [14:36:35] <Jean-Gui> I have a question about Doctrine/ORM/Query/Expr/Base.php
[jeudi 7 mars 2013] [14:37:17] <Jean-Gui> looking at the add function (https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/Expr/Base.php#L89), the first if seems wrong
[jeudi 7 mars 2013] [14:37:39] <Jean-Gui> [[ if ( $arg !== null || ($arg instanceof self && $arg->count() > 0) ) ]]
[jeudi 7 mars 2013] [14:39:49] <Jean-Gui> if $arg is not null, then it will get added even if $arg->count === 0
[jeudi 7 mars 2013] [14:41:03] <ocramius> yes
[jeudi 7 mars 2013] [14:41:42] <Jean-Gui> that doesn't seem right, does it?
[jeudi 7 mars 2013] [14:43:29] <ocramius> why not?
[jeudi 7 mars 2013] [14:43:34] <ocramius> can you elaborate?
[jeudi 7 mars 2013] [14:45:37] <Jean-Gui> that "if" seems to be meaning that the function shouldn't add $arg if $arg->count() equals 0
[jeudi 7 mars 2013] [14:45:45] <Ninj> ocramius: i think Jean-Gui means that the right side of the OR will be called only if the left side is false, which means $arg is null. And if $arg is null it cannot be an object
[jeudi 7 mars 2013] [14:46:07] <Jean-Gui> right
[jeudi 7 mars 2013] [14:46:30] <Ninj> this condition is indeed bugged
[jeudi 7 mars 2013] [14:47:12] <alcuadradoatwork> I see Jean-Gui's point too
[jeudi 7 mars 2013] [14:47:18] <ocramius> write a test case then
[jeudi 7 mars 2013] [14:47:24] <alcuadradoatwork> maybe it works right, but it's confusing
[jeudi 7 mars 2013] [14:48:07] <Ninj> this condition will not throw any error because the "instanceof" will prevent the $arg::count function to be called on a null object, but it is still useless
[jeudi 7 mars 2013] [14:48:20] <Jean-Gui> I think [[ if ( $arg Unable to render embedded object: File (== null && () not found.($arg instanceof self) || ($arg instanceof self && $arg->count() > 0)) ) ]] would work better
[jeudi 7 mars 2013] [14:48:31] * Jean-Gui will look into how to submit bug reports
[jeudi 7 mars 2013] [14:48:49] <alcuadradoatwork> isn't this enough? if ($arg instanceof self && $arg->count() > 0)
[jeudi 7 mars 2013] [14:49:18] <Ninj> i think it is, alcuadradoatwork
[jeudi 7 mars 2013] [14:49:28] <Jean-Gui> no, because if $arg is not an instance of self, I think we still want to add it
[jeudi 7 mars 2013] [14:49:45] <ocramius> alcuadradoatwork: again... if it is a buggy condition, write a small test and open a PR
[jeudi 7 mars 2013] [14:50:03] <alcuadradoatwork> ocramius, it depends on your definition of "buggy"
[jeudi 7 mars 2013] [14:50:32] <alcuadradoatwork> it won't damage the behavior of the software, but it's quality its kind of pour
[jeudi 7 mars 2013] [14:51:19] <ocramius> alcuadradoatwork: yes, still it needs coverage. I didn't say it needs a FAILING test
[jeudi 7 mars 2013] [14:51:38] <alcuadradoatwork> I see your point
[jeudi 7 mars 2013] [14:51:47] <Ninj> if the logic is : "add any non-null object, but if it's self so add it only if count>0" then it must be rewriten
[jeudi 7 mars 2013] [14:52:46] <Jean-Gui> $args should be added if it's an instance of self or $_allowedClasses
[jeudi 7 mars 2013] [14:53:16] <Ninj> hum
[jeudi 7 mars 2013] [14:53:37] <Ninj> $args should be added if it's an instance of self with count > 0 or any other $_allowedClasse
[jeudi 7 mars 2013] [14:53:55] <Jean-Gui> yes, Ninj
[jeudi 7 mars 2013] [14:55:01] <Jean-Gui> thanks for your help guys, I'll submit a bug report with some test cases
[jeudi 7 mars 2013] [14:55:43] <Ninj> your welcome Jean-Gui
```

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

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

Message:

Code explains everything

The SQL Server platform throws an error when you try to run DQL with JOIN statements.

The breaking change was in the DBAL SQL Server platform – it was changed to add a ' WITH (NOLOCK)' to the appendLockHint function. Change was in this rev. The change in DBAL is not wrong, it just highlighted the bug in the ORM...

The ORM SqlWalker runs the appendLockHint function against a generated FROM / JOIN clause in the walkFromClause func here. This is actually the wrong place to append lock hints. This is generating the FROM clause like:

 FROM foo f0_ LEFT JOIN foo_bar f1_ ON f0_.id = f1_.foo_id LEFT JOIN bar b2_ ON f1_.bar_id = b2_.id WITH (NOLOCK)

When it should actually generate something like:

 FROM foo f0_ WITH (NOLOCK) LEFT JOIN foo_bar f1_ WITH (NOLOCK) ON f0_.id = f1_.foo_id LEFT JOIN bar b2_ WITH (NOLOCK) ON f1_.bar_id = b2_.id

It should append lock hints after the table alias.

I think the only reason this hasn't shown up before is that the other lock hint types haven't been applied in this way before, if at all.

It seems like columns of type "bigint" have no consistent PHP type.

If an object is read from the database, the database value seems to be cast to
a PHP string. However, directly after persisting an entity using an id generation strategy of "AUTO" the type is a PHP integer.

I think it would make sense to use a PHP string for both cases as you otherwise can run into problems if you use shallow comparisons such as "===".

I already found a similar issue report but it seems to be not solved completely:

http://doctrine-project.org/jira/browse/DDC-1382

I did something like this (mock): (Metadata cache is OFF)
$someCompositeEntity = new SomeCompositeEntity;
$someCompositeEntity->setUser($userEntity);
$someCompositeEntity->setAnotherRelation($anotherRelationEntity);

// Note: $userEntity & $anotherRelationEntity are managed by UOW.

$uow = $em->getUnitOfWork();
var_dump($uow->getEntityState($someCompositeEntity));

– EXPECTED: –
bool(false)

– ACTUAL RESULT: –
<h1>PHP Error [4096]</h1>
<p>Object of class Application\Model\Db\Entity\User could not be converted to string (/Users/keksnicoh/lokalhorst/FinQ/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:2754)</p>
<pre>#0 unknown(0): CWebApplication->handleError()
#1 /Users/keksnicoh/lokalhorst/FinQ/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(2754): implode()
#2 /Users/keksnicoh/lokalhorst/FinQ/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(1389): Doctrine\ORM\UnitOfWork->tryGetById()
#3 /Users/keksnicoh/lokalhorst/FinQ/Application/Model/Db/Model/AnswerCommentRating.php(42): Doctrine\ORM\UnitOfWork->getEntityState()

As you see the metadatainfo tries to convert the composite objects to strings, instead of getting the identifiers from the objects.

greetz
keksnicoh

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

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

Message:

...ectManagerAware.

I ran into that problem while I had two objects in the identitymap while hydrating a collection: one was new a "real" entity and the other one was an uninitialized proxy. For "real" entities the em is injected in line 2427, for new entities it is injected in 2436->2364, but for proxies this is missing. According to the comment "inject ObjectManager into just loaded proxies." the code in line 2427 should do this, but in fact it is just used if it is a "real" entity or an already initialized proxy. Moving the injection to outside of the condition in line 2411 (if the entity is an unitialized proxy) solves this.