[DDC-1620] Partial merge of PR261 Created: 25/Jan/12  Updated: 25/Jan/12  Resolved: 25/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.2-BETA1, 2.2-BETA2, 2.2.0-RC1
Fix Version/s: 2.1.6, 2.2
Security Level: All

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


 Description   

The PR261 [1] has two commits, but only one (the first one) was merged to 2.1 and 2.2

[1] - https://github.com/doctrine/doctrine2/pull/261



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

fixed

Comment by Miha Vrhovnik [ 25/Jan/12 ]

Hm github is still saying that this is not in 2.2 branch....

Comment by Benjamin Eberlei [ 25/Jan/12 ]

Cherrypick

Comment by Benjamin Eberlei [ 25/Jan/12 ]

ah no, now its up. thanks





[DDC-1619] Missing QueryBuilder::distinct() method Created: 25/Jan/12  Updated: 25/Jan/12  Resolved: 25/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.1.5, 2.2.0-RC1, Git Master
Fix Version/s: 2.1.6, 2.2
Security Level: All

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


 Description   

The QueryBuilder misses a way to make a query distinct.



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

Fixed





[DDC-1618] Query::Iterate() with fetch join exception but no associaiton selected Created: 24/Jan/12  Updated: 24/Jan/12  Resolved: 24/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
Affects Version/s: 2.1.5
Fix Version/s: 2.1.6, 2.2
Security Level: All

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


 Description   

Iterate with fetch join in class Application\Sonata\NewsBundle\Entity\Post using association tags not allowed.

SELECT o FROM Application\Sonata\NewsBundle\Entity\Post o LEFT JOIN o.tags s_tags LEFT JOIN o.author s_author WHERE ( o.id = :field_4f1f118cf04ff_id_0 OR o.id = :field_4f1f118cf04ff_id_1 OR o.id = :field_4f1f118cf04ff_id_2 )

The SqlWalker.php (line 742) does not check if the association is selected ...

The PR : https://github.com/doctrine/doctrine2/pull/271



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

Fixed





[DDC-1603] Unique key name isn't correctly set Created: 16/Jan/12  Updated: 22/Jan/12  Resolved: 17/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.2-BETA2
Fix Version/s: 2.1.6, 2.2.0-RC1, 2.2, 2.3

Type: Bug Priority: Minor
Reporter: Thomas Tourlourat - Armetiz Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Example :

<unique-constraints>
<unique-constraint columns="permalink" />
<unique-constraint columns="code" />
</unique-constraints>

This will create :
CREATE UNIQUE INDEX UNIQ_6C3BF144F286BC32 ON shows (permalink);
CREATE UNIQUE INDEX 1 ON shows (code);

instead of :
CREATE UNIQUE INDEX UNIQ_6C3BF144F286BC32 ON shows (permalink);
CREATE UNIQUE INDEX UNIQ_6C3BF14477153098 ON shows (code);

The problem comme from SchemaTool, and the first key is a valid result because of "==" instead of "===" inside Table.php.

I have create a PR on Github.



 Comments   
Comment by Thomas Tourlourat - Armetiz [ 16/Jan/12 ]

Here the PR for the ORM SchemaTool : https://github.com/doctrine/doctrine2/pull/261
Here the PR for the DBAL Table : https://github.com/doctrine/dbal/pull/94

Comment by Guilherme Blanco [ 17/Jan/12 ]

Merged https://github.com/doctrine/doctrine2/commit/2bb511584e5d37ddad6c669a19d8e6b4a20f7b2b

Comment by Benjamin Eberlei [ 21/Jan/12 ]

DBAL merged back into 2.2 and 2.1.x

Comment by Benjamin Eberlei [ 21/Jan/12 ]

and Merged into 2.2 and 2.1.x ORM





[DDC-1594] Merging serialized entity back to the UnitOfWork Created: 11/Jan/12  Updated: 15/Jan/12  Resolved: 15/Jan/12

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

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

Windows 7, Apache, PHP 5.3.8, Zend Framework



 Description   

(I'm using doctrine 2.1.4.)

I'm trying to merge an Entity back to the UnitOfWork.
The Entity is created from a serialized object (The deserialzed Entity is a valid Entity Object. The only difference
is that it is not managed by Doctrine yet) and I'm using the merge
method of the EntityManager to get it in managed state again.

This results in a call of the Method doMerge() in the UnitOfWork
class.
This method takes the id of my deserialized Entity, that I want to
merge, and looks if an Entity with that id is already in doctrine
cache. If that is the case my deserialized Entity is merged with the
one in the cache. So far so good. But I've got the Problem, that the
Entity, which is in cache, is not initialized yet. It is not initialized because
this Entity has a relation to another Entity that a used earlier in code.
It's there but in uninitialized stat, because I did not access it yet.
So when my deserialized Entity and the one from cache gets merged, some field are
uninitialized (the id field, for example).

I fixed the problem by adding this piece of code in line 1446 in the
UnitOfWork class:
if(! $managedCopy->_isInitialized_)

{ $managedCopy->__load(); }

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

Fixed and merged into 2.2 and 2.1





[DDC-1589] Use of mb_stripos in Composite.php Created: 09/Jan/12  Updated: 09/Jan/12  Resolved: 09/Jan/12

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

Type: Bug Priority: Minor
Reporter: Christopher Nadeau Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

In Doctrine\ORM\Query\Expr\Composite::processQueryPart(), mb_stripos() is used. The mbstring extension should be checked for and fallback on stripos() used, or the requirement on the mbstring extension should be documented.



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

This was fixed in master, that is now backported to 2.1.x





[DDC-1561] GH-239: Fix $qb->expr() PHPDoc @return type. Created: 23/Dec/11  Updated: 20/Dec/13  Resolved: 28/Dec/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.1.6, 2.2-BETA2, 2.2, 2.3
Security Level: All

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


 Description   

Pull-Request was automatically synchronized: https://github.com/doctrine/doctrine2/pull/239

The autocompletion was missing so i was sad.

But hey, it's open source!



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

Fixed

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DDC-1526] Unecessary queries with LEFT JOIN Created: 09/Dec/11  Updated: 23/Oct/12  Resolved: 28/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.1.4
Fix Version/s: 2.1.6, 2.2
Security Level: All

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

PHP 5.3.6


Attachments: Text File trace.txt     Text File trace.txt    
Issue Links:
Duplicate
is duplicated by DDC-1573 Simple relation hydratation not worki... Resolved

 Description   

After upgrading to 2.1.4 (from 2.1.2), the following dql started creating way more queries than necessary :
SELECT m, p, s, c, o
FROM FERMainBundle:Menu m
LEFT JOIN m.page p
LEFT JOIN m.section s
LEFT JOIN m.children c
LEFT JOIN s.position o
ORDER BY m.lft

Details to the code here:
http://pastie.textmate.org/private/z9gtgqe1odwenxcmudywqa
The model looks like that:
http://pastie.textmate.org/private/przxzfimsfyua02cxqcv9a

http://pastie.textmate.org/private/ob1jqiekv89e4xj9bq06q
First query is executed, it should in fact retrieve everything there is about the menu, but then it runs the second query for every menu element I have, generating a lot of queries that didn't occur before.



 Comments   
Comment by Benjamin Eberlei [ 15/Dec/11 ]

Can you profile where exactly the extra queries are executed using xdebug_start_trace? Directly during hydration or later in your code?

Comment by Pascal Burkhard [ 19/Dec/11 ]

xdebug trace start just before I query the database

Comment by Benjamin Eberlei [ 20/Dec/11 ]

Hi Pascal, sorry but this is not enough. I need this query until all the other entities (or at least one) are n+1 joined.

Comment by Pascal Burkhard [ 20/Dec/11 ]

Here the complete trace, started just before the first query. I'm sorry but I can't make heads or tails with that... I hope it can help you pinpoint the problem.

Please also note that I have update Doctrine ORM to 2.1.5 and there was a change in the number of "superfluous" queries done. I am now only left with additional queries to get the relations to "parent", cf the model ( http://pastie.textmate.org/private/przxzfimsfyua02cxqcv9a ).

Comment by Benjamin Eberlei [ 28/Dec/11 ]

Is the trace from before upgrade to 2.1.5 or after?

Comment by Pascal Burkhard [ 28/Dec/11 ]

The "complete" trace, i.e. the one that is 5.94 mb big is from after the upgrade to 2.1.5.

Comment by Benjamin Eberlei [ 29/Dec/11 ]

Can you disable the nested set extension? the other ticket uses it too and i want to rule out that its the extensions fault.

Comment by Pascal Burkhard [ 29/Dec/11 ]

Alright. I deactivated the Tree extension, but there are no changes in the number of queries.

Comment by Benjamin Eberlei [ 28/Jan/12 ]

I found the issue.

Comment by Benjamin Eberlei [ 28/Jan/12 ]

Fixed





Generated at Mon Jul 28 16:25:20 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.