[DDC-2341] [GH-606] Don't add empty Expr to another one Created: 08/Mar/13  Updated: 13/May/14  Resolved: 12/Mar/13

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

Type: Bug 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 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
```



 Comments   
Comment by Benjamin Eberlei [ 12/Mar/13 ]

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

Comment by Doctrine Bot [ 13/May/14 ]

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





[DDC-2340] Using Criteria matching on non-initialized collections ignore changes made on loaded entities Created: 07/Mar/13  Updated: 12/Mar/13  Resolved: 12/Mar/13

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

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


 Description   

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.



 Comments   
Comment by Benjamin Eberlei [ 12/Mar/13 ]

Fixed and merged for 2.3.3





[DDC-2323] [GH-593] Fix SimpleObjectHydrator behavior when column not exists in fieldMappings, relationMappings and metaMappings Created: 28/Feb/13  Updated: 02/May/14  Resolved: 14/Mar/13

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

Type: Bug 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 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



 Comments   
Comment by Doctrine Bot [ 02/May/14 ]

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





[DDC-2310] Recent changes to DBAL SQL Server platform lock hinting breaks ORM SqlWalker in DQL queries with joins Created: 21/Feb/13  Updated: 20/Aug/14  Resolved: 01/Mar/14

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

Type: Bug Priority: Critical
Reporter: William Schaller Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: dbal, lockhints, orm, sqlserver, sqlsrv
Environment:

SQL Server


Issue Links:
Dependency
depends on DDC-2914 [GH-910] [DDC-2310] Fix SQL generatio... Resolved
Duplicate
duplicates DDC-2675 WITH (NOLOCK) failing when using JOIN Awaiting Feedback
Reference
is referenced by DBAL-783 [GH-508] [DDC-2310] Fix evaluation of... Resolved
is referenced by DBAL-976 [GH-663] [DDC-2310] [2.4] Fix evaluat... Resolved
is referenced by DDC-2919 LockMode::NONE evaluation inconsisten... Resolved

 Description   

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.



 Comments   
Comment by Christophe Coevoet [ 21/Feb/13 ]

I think the line appending the lock should be moved to this place to achieve the result displayed above.

But it may cause issues with some other vendor.

Comment by William Schaller [ 21/Feb/13 ]

@Christophe I considered that too. None of the other platforms implement the appendLockHint function. None of the other platforms implement this because it is handled differently on other platforms – with transaction isolation levels and such.

Comment by Steve Müller [ 13/Jan/14 ]

I don't know why this ticket is marked as "fixed" because it's obviously NOT.
Whatever, here is the patch: https://github.com/doctrine/doctrine2/pull/910

Comment by Steve Müller [ 13/Jan/14 ]

Complementary I provided the following patch to suppress unnecessary NOLOCK hint generation in ORM: https://github.com/doctrine/dbal/pull/508

Comment by Doctrine Bot [ 14/Jan/14 ]

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

Comment by Steve Müller [ 15/Jan/14 ]

This is not resolved, yet.

Comment by Doctrine Bot [ 31/Jan/14 ]

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

Comment by Benjamin Eberlei [ 09/Feb/14 ]

Steve Müller When is it?

Comment by Steve Müller [ 09/Feb/14 ]

Benjamin Eberlei It is fixed in PR: https://github.com/doctrine/doctrine2/pull/910





[DDC-2300] Xmldriver does not convert the version field to boolean but keeps it as a SimpleXMLElement which breaks serialization Created: 16/Feb/13  Updated: 14/Mar/13  Resolved: 14/Mar/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.3.2
Fix Version/s: 2.3.3
Security Level: All

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


 Description   

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']);





[DDC-2282] [GH-572] Fixed SQLServer ORDER BY problem in paginator CountOutputWalker Created: 07/Feb/13  Updated: 08/May/14  Resolved: 12/Mar/13

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

Type: Bug 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 norzechowicz:

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

Message:

Code explains everything



 Comments   
Comment by Doctrine Bot [ 08/May/14 ]

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





[DDC-2246] ORM\UnitOfWork::getEntityState() crash when using a new Entity with association composite key Created: 17/Jan/13  Updated: 20/Jan/13  Resolved: 20/Jan/13

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

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


 Description   

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



 Comments   
Comment by Benjamin Eberlei [ 20/Jan/13 ]

Fixed and merged into 2.3.x branch





[DDC-2243] Inconsistent PHP Type for "bigint" columns Created: 15/Jan/13  Updated: 20/Jan/13  Resolved: 20/Jan/13

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

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


 Description   

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 "===".






[DDC-2231] [GH-546] The EntityManager was not injected in uninitialized proxys which are Obj... Created: 10/Jan/13  Updated: 16/May/14  Resolved: 12/Jan/13

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

Type: Bug 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 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.



 Comments   
Comment by Benjamin Eberlei [ 12/Jan/13 ]

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

Comment by Doctrine Bot [ 16/May/14 ]

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





[DDC-2090] MultiTableUpdateExecutor works incorrect with query cache enabled Created: 19/Oct/12  Updated: 17/Mar/13  Resolved: 17/Mar/13

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

Type: Bug Priority: Major
Reporter: Valera Leontyev Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   

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.



 Comments   
Comment by Valera Leontyev [ 19/Oct/12 ]

Workaround is to disable query cache per every multitable update query: http://stackoverflow.com/questions/12969460/doctrine-query-cache-update

Comment by Fabio B. Silva [ 17/Mar/13 ]

Fixed : https://github.com/doctrine/doctrine2/commit/60b8bc63a1a4819cf112cfbbc7cca06b5792aba6

Comment by Benjamin Eberlei [ 17/Mar/13 ]

Merged into 2.3 for release with 2.3.3





[DDC-1666] orphanRemoval does not work with oneToOne: Duplicate entry Error Created: 23/Feb/12  Updated: 14/Mar/13  Resolved: 14/Mar/13

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

Type: Bug Priority: Major
Reporter: Mario Knippfeld Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

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.

Mysql Error
/*
Error:
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1' for key 'UNIQ_9D8DDB05579B502F'
*/
Models and YAML Mapping
/*
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;
    }
}
Script
// 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();




 Comments   
Comment by Benjamin Eberlei [ 14/Mar/12 ]

This is a necessary restriction for the internals of Doctrine to always work correctly.

Comment by Albert Casademont [ 12/Apr/12 ]

+1 on this one. So what's the point of orphanRemoval in OneToOne if it can never be done? Maybe onetoones should not create a unique index but a normal one.

If it is really a won't fix, then the docs should reflect that.

Comment by Albert Casademont [ 12/Apr/12 ]

BTW, as a workaround, i suggest converting this OneToOne case (where the orphanRemoval is in the inverse side) into a ManyToOne so a normal index will be created, not a unique one. Then the new row is inserted fine and the old one is deleted afterwards.

Comment by Mario Knippfeld [ 04/May/12 ]

+1
like Albert said, if its really a wont fix, the docs should state that.
the example in: http://readthedocs.org/docs/doctrine-orm/en/latest/reference/working-with-associations.html?highlight=orphan#orphan-removal with a (bidirectional) oneToOne orphanRemoval association isnt working with mysql and having doctrine created the tables.
maybe the bidirectional association is the problem?

Comment by Matthieu Napoli [ 11/Feb/13 ]

+1 same for me

If the example of the docs isn't supposed to work (i.e. orphanRemoval with oneToOne isn't supported), then the docs should be updated.

I can do a PR, but I need you to confirm it's really the case Benjamin Eberlei.

Comment by Benjamin Eberlei [ 14/Mar/13 ]

Its indeed a good fix to disable the unique constraint if orphan removal isset.

Comment by Benjamin Eberlei [ 14/Mar/13 ]

Fixed and merged into 2.3

With the change Doctrine will not create unique indexes anymore on Orphan Removal OneToOne associations. You need to change the database schema for this change to take effect essentially.





Generated at Mon Oct 20 11:23:36 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.