[DDC-2148] Many-to-many not working with interface Created: 16/Nov/12  Updated: 22/Nov/12  Resolved: 22/Nov/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: 2.3
Fix Version/s: 2.2

Type: Bug Priority: Major
Reporter: Moritz Kraft Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: dql
Environment:

Linux, PHP 5.3.10, Symfony 2.2



 Description   

First off, here's a pastie with all the code and mappings involved, and a stacktrace: http://pastie.org/5372087

Not sure if this a bug or not, but I think that according to the docs this should work - in a vendor bundle I have an entity defining a unidirectional many-to-many relation to an interface: the entity is Group and defines a many-to-many relation to a UserInterface, which is resolved correctly in the app configuration (as the many-to-one relations using it in the other entities of this vendor bundle work fine).

I'm going by these docs:

http://symfony.com/doc/master/cookbook/doctrine/resolve_target_entity.html

However, when adding a user to a group, I'm getting a weird error:

An exception occurred while executing 'INSERT INTO acme_group_user (group_id, user_id) VALUES (?, ?)' with params

{"1":2,"2":1,"3":2,"4":1}

:

SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not match number of tokens

For some reason it's adding 4 parameters to the statement instead of 2.

Oddly enough, the query generation works perfectly fine when I replace the interface in the mapping with the actual final entity. But that wasn't the point of the exercise... I need to use the interface there.

Also, in other entities in that GroupBundle which are referencing the UserInterface using a different relation type, i.e. many-to-one, the relations work perfectly fine.

The schema validates as well, using doctrine:schema:validate in the console.



 Comments   
Comment by Marco Pivetta [ 16/Nov/12 ]

"many-to-many TO a mapped superclass"? I don't think relations TO mapped superclasses are supported in any way... A mapped superclass should never appear in a `targetEntity` mapping.

Could you please re-formulate the description of the issue? There is no mapped superclass in your examples

Comment by Moritz Kraft [ 16/Nov/12 ]

You are of course right. Edited the issue description/title.

It is a blocker for us, btw., not minor - being able to use a many-to-many relation there is rather central to the code of our app. I'm not seeing a workaround, easy or otherwise.

Comment by Marco Pivetta [ 16/Nov/12 ]

Moritz Kraft yes, but it is not a blocker for the next release Will restore prio.

Comment by Moritz Kraft [ 16/Nov/12 ]

Ah right, yeah, that makes sense. Thank you!

Comment by Moritz Kraft [ 22/Nov/12 ]

Fixed in 1b5f051 - thanks Benjamin!

Comment by Moritz Kraft [ 22/Nov/12 ]

Fixed in 2.3 branch, backported to 2.2 as well





[DDC-1653] command line cache clear commands clear everything from caches including non Doctrine related caches Created: 15/Feb/12  Updated: 03/Mar/12  Resolved: 03/Mar/12

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

Type: Improvement Priority: Major
Reporter: Howard Ha Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

When I run doctrine orm:clear-cache:metadata I noticed that it clears everything within the cache, even items which have nothing to do with Doctrine at all.

In looking into the various driver implementations it seems that the AbstractCache->deleteAll() depends on getIds of each cache driver, yet the getIds of XcacheCache and MemcacheCache drivers seem to just get every single item within the cache.

This has several implications:

  1. clearing metadata cache actually clears query cache and any other Doctrine cache using the same cache driver
  2. clearing Doctrine cache of one project actually clears caches of every project using the same cache container
  3. clearing Doctrine cache clears every object cached within that container, leading to increased risk of cache stampeding

In looking at the stored cache data it seems possible to fix #2 by using the Namespace of that project when executing a cache clear. it also seems possible to use the cache driver's deleteByRegex() to solve #1 by deleting only items listed as metadata cache vs query cache. Fixing #1 and #2 automatically fixes concern #3

Or, as an alternative, I could suggest that deleteAll() in MetaDataCommand should be replaced by:

$cacheIds = $cacheDriver->deleteBySuffix('METADATA');


 Comments   
Comment by Howard Ha [ 02/Mar/12 ]

I think this issue might be resolved in 2.2 since the cache layer seems to have been rewritten.

Comment by Guilherme Blanco [ 03/Mar/12 ]

To address this issue we require the rewrite that was done in 2.2.
Closing as fixed.





[DDC-1641] [Tests] Wrong tearDown() in UnitOfWorkTest Created: 09/Feb/12  Updated: 10/Feb/12  Resolved: 10/Feb/12

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

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


 Description   

root@ubuntu-server-1110:/home/zerkms/src/doctrine2# phpunit
PHPUnit 3.6.10 by Sebastian Bergmann.

Configuration read from /home/zerkms/src/doctrine2/phpunit.xml.dist

.SSSSSS.........................EEEEEEEEEEEEEEEEEEEEEEEEEEEEE 61 / 1472 ( 4%)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE.EEESE...SSSEEEEEEEEEEEEEE 122 / 1472 ( 8%)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE 183 / 1472 ( 12%)
.EEEEEEESSESESEESESEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEFEEEEE 244 / 1472 ( 16%)
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEESE 305 / 1472 ( 20%)
SSSEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEFFFEEEEEEEEEEEEEEEEEE 366 / 1472 ( 24%)
EEEEEEEEEEESSSEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEESSSSSSSSS 427 / 1472 ( 29%)
SSSS...........SEEEEEEEEEEEEEEEEEEEEEEEEEESEEESEEEEEEEEEEEEEE 488 / 1472 ( 33%)
EEEEEEEEEEEEEEEEEEEEEEEEESEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE 549 / 1472 ( 37%)
EEEEEEEEEEEEEEEEEEEEEE.EEEEEEEEEEEEE.EEEEEEEEEEESSEEEEEEEEEEE 610 / 1472 ( 41%)
EEEEEEEEEEEEEEEEEEEEEEEEEE................................... 671 / 1472 ( 45%)
............................................................. 732 / 1472 ( 49%)
............................................................. 793 / 1472 ( 53%)
.............................................S............... 854 / 1472 ( 58%)
......S...................................................... 915 / 1472 ( 62%)
............................................................. 976 / 1472 ( 66%)
............................................................. 1037 / 1472 ( 70%)
............................................................. 1098 / 1472 ( 74%)
............................................................. 1159 / 1472 ( 78%)
............................................................. 1220 / 1472 ( 82%)
............................................................. 1281 / 1472 ( 87%)
............................................................. 1342 / 1472 ( 91%)
...........................S............S.................... 1403 / 1472 ( 95%)
.................................SSSSSSSS.PHP Fatal error: Class 'Doctrine\Tests\Mocks\EntityPersisterMock' not found in /home/zerkms/src/doctrine2/tests/Doctrine/Tests/ORM/UnitOfWorkTest.php on line 55

This (the fatal error) happens because of in ORM/Tools/SetupTest there is a condition in setUp() that marks test as skipped, but tearDown() is being invoked anyway (that is how phpunit works).

So tearDown() should run only in case if setUp() hasn't skipped the test, otherwise tearDown() deletes registered autoloaders

PS: other tests failed because I haven't set up any database



 Comments   
Comment by Benjamin Eberlei [ 10/Feb/12 ]

Fixed.





[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-1617] EntityGenerator does not create uniqueConstraints annotations Created: 24/Jan/12  Updated: 28/Jan/12  Resolved: 28/Jan/12

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

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


 Description   

I have add some uniqueConstraints in ClassMetadataInfo but the EntityGenerator does not create the annotations for this.


private function _generateTableAnnotation($metadata)
{
    $table = array();

    if (isset($metadata->table['schema'])) {
         $table[] = 'schema="' . $metadata->table['schema'] . '"';
    }

    if (isset($metadata->table['name'])) {
        $table[] = 'name="' . $metadata->table['name'] . '"';
    }

    return '@' . $this->_annotationsPrefix . 'Table(' . implode(', ', $table) . ')';
}



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

Fixed





[DDC-1613] Add Pagination Tools Created: 22/Jan/12  Updated: 22/Jan/12  Resolved: 22/Jan/12

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

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


 Description   

We should add pagination tools to the Doctrine\ORM\Tools\Pagination namespace. There are already 3 libraries out there that share the same code-base:

We should merge the currently best one of this into the code soon, as the cost of maintaining them is very high and their code is pretty stable by now.



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

Implemented, using the KNP Code, the PAgerfanta tests and putting a set of functional tests on top.

Merged back into 2.2 aswell as the code can be considered stable and does not affect any other area of the code.





[DDC-1612] Cannot call entityManager->flush($entity) with new entity Created: 19/Jan/12  Updated: 22/Jan/12  Resolved: 21/Jan/12

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

Type: Bug Priority: Major
Reporter: Sascha-Oliver Prolic Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Following works:
$entity = $em->find('Entity', 1);
$entity->setName('newName');
$em->persist($entity);
$em->flush($entity);

Following does NOT work:
$entity = new Entity();
$entity->setName('newName');
$em->persist($entity);
$em->flush($entity);



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

Fixed





[DDC-1610] Associations loaded in 'loadClassMetadata' event are not well initialized inside ClassMetadata Created: 18/Jan/12  Updated: 21/Jan/12  Resolved: 21/Jan/12

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

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


 Description   

Reproduce
---------------

  • I have an entity
  • I'm loading an association (named 'myfield') inside a `LoadClassMetadata` event.

Error
------

Then i get this error : Notice: Undefined index: myfield in /vendor/doctrine/lib/Doctrine/ORM/UnitOfWork.php line 2473

Problem
-----------

It seems that here https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L294 we call the method 'wakeupReflection' before the loadClassMetadata event is dispatched.

A solution
-------------

I've created a patch (all tests pass) here https://github.com/gordonslondon/doctrine2/commit/0823cd54d0b2720f5e72aa9a29d16271904d99f0 that fixed the issue. Do you want a PR ?

Here's the PR : https://github.com/doctrine/doctrine2/pull/264



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

Fixed





[DDC-1609] Weird testerror on PostgreSQL Created: 18/Jan/12  Updated: 22/Jan/12  Resolved: 18/Jan/12

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

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


 Description   

https://github.com/doctrine/doctrine2/commit/3bb803fd697d92d661f5b8cea473f75f46c34857

Git Bisect found this commit to lead to the following error:

$ phpunit -c postgresql.phpunit.xml --filter DDC-742
PHPUnit 3.6.5 by Sebastian Bergmann.

Configuration read from /home/benny/code/php/wsnetbeans/doctrine2/postgresql.phpunit.xml

E

Time: 12 seconds, Memory: 36.00Mb

There was 1 error:

1) Doctrine\Tests\ORM\Functional\Ticket\DDC742Test::testIssue
Exception: [PHPUnit_Framework_Error_Notice] Undefined index: 0000000016f5d67f000000001fa7794e

With queries:
11. SQL: 'INSERT INTO comments (content) VALUES (?)' Params: 'baz'
10. SQL: 'INSERT INTO comments (content) VALUES (?)' Params: 'bar'
9. SQL: 'INSERT INTO comments (content) VALUES (?)' Params: 'foo'
8. SQL: 'ALTER TABLE user_comments ADD CONSTRAINT FK_BF13722AF8697D13 FOREIGN KEY (comment_id) REFERENCES comments (id) NOT DEFERRABLE INITIALLY IMMEDIATE' Params: 
7. SQL: 'ALTER TABLE user_comments ADD CONSTRAINT FK_BF13722AA76ED395 FOREIGN KEY (user_id) REFERENCES users (id) NOT DEFERRABLE INITIALLY IMMEDIATE' Params: 
6. SQL: 'CREATE TABLE comments (id SERIAL NOT NULL, content VARCHAR(100) NOT NULL, PRIMARY KEY(id))' Params: 
5. SQL: 'CREATE INDEX IDX_BF13722AF8697D13 ON user_comments (comment_id)' Params: 
4. SQL: 'CREATE INDEX IDX_BF13722AA76ED395 ON user_comments (user_id)' Params: 
3. SQL: 'CREATE TABLE user_comments (user_id INT NOT NULL, comment_id INT NOT NULL, PRIMARY KEY(user_id, comment_id))' Params: 
2. SQL: 'CREATE TABLE users (id SERIAL NOT NULL, title VARCHAR(100) NOT NULL, PRIMARY KEY(id))' Params: 

Trace:
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/UnitOfWork.php:2171
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:113
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php:95
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/Persisters/AbstractCollectionPersister.php:130
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/Persisters/AbstractCollectionPersister.php:108
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/UnitOfWork.php:310
/home/benny/code/php/wsnetbeans/doctrine2/lib/Doctrine/ORM/EntityManager.php:334
/home/benny/code/php/wsnetbeans/doctrine2/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC742Test.php:63


/home/benny/code/php/wsnetbeans/doctrine2/tests/Doctrine/Tests/OrmFunctionalTestCase.php:359


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

This error depends on the caching layer. Without APC/Memcache this test works for me, not with cache. But it only happens on PGSQL not on MySQL or SQLITE

Comment by Benjamin Eberlei [ 18/Jan/12 ]

It specifically depends on the Memcache driver, test works with APC

Comment by Benjamin Eberlei [ 18/Jan/12 ]

Fixed





[DDC-1608] Lazy load more restrict when consuming PersistentCollection trigger actions to *Persisters Created: 17/Jan/12  Updated: 18/Jan/12  Resolved: 18/Jan/12

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

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


 Description   

Since https://github.com/doctrine/doctrine2/pull/259 we identified an issue with the Persisters that are failing to check for entities that exist in UoW (managed and sched for insert) and are now being checked is they are part of Collection.
Also it missed some tests. It should be easy, just ->persist the entity then triggers Collection actions.



 Comments   
Comment by Guilherme Blanco [ 18/Jan/12 ]

Fixed in https://github.com/doctrine/doctrine2/commit/d39760ba49418f42f235e9befe223896f11de4bd

Comment by Benjamin Eberlei [ 18/Jan/12 ]

Merged back to 2.2





[DDC-1606] Added fix for collection->contains with many-to-many extra lazy fetchMode Created: 17/Jan/12  Updated: 22/Jan/12  Resolved: 17/Jan/12

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

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


 Description   

That case previously triggered a PHP error along the lines of:

Notice: Undefined index: 0000000062a3a7690000000033c91b26 in doctrine/lib/Doctrine/ORM/UnitOfWork.php line 2202
#0 doctrine/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php(267): Doctrine\ORM\UnitOfWork->getEntityIdentifier(Object(Item))
#1 doctrine/lib/Doctrine/ORM/PersistentCollection.php(411): Doctrine\ORM\Persisters\ManyToManyPersister->contains(Object(Doctrine\ORM\PersistentCollection), Object(Item))
#2 Test.php(71): Doctrine\ORM\PersistentCollection->contains(Object(Item))

Associated PR: https://github.com/doctrine/doctrine2/pull/259



 Comments   
Comment by Guilherme Blanco [ 17/Jan/12 ]

Merged in https://github.com/doctrine/doctrine2/commit/c1012f79706491e9dbf6c8741225b62833c6d2ce





[DDC-1604] Implement Common Proxy Created: 16/Jan/12  Updated: 22/Jan/12  Resolved: 16/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2-BETA1, 2.2-BETA2
Fix Version/s: 2.2.0-RC1, 2.2
Security Level: All

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


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

done





[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-1601] Schema Validator wrong on entities with pk as fk Created: 15/Jan/12  Updated: 15/Jan/12  Resolved: 15/Jan/12

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

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


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

Fixed





[DDC-1598] ProxyFactory makes assumptions on identifier getter code Created: 13/Jan/12  Updated: 16/Jan/12  Resolved: 16/Jan/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.1, 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.2-BETA1, 2.2-BETA2, Git Master
Fix Version/s: 2.2, 2.3, 2.x
Security Level: All

Type: Bug Priority: Critical
Reporter: Marco Pivetta Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None


 Description   

As of
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L214
and
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Proxy/ProxyFactory.php#L237
the current ProxyFactory isn't actually checking if the identifier getter has logic in it.
Current checks aren't enough/valid.

In my opinion the check should be matching following:

(public|protected)\s+function\s+getFieldname\s*(\s*)\s+

{\s*\$this\s*->Fieldname\s*;\s*}

Not really experienced with regex, but currently cannot come up with a more secure check.



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

Can you explain why you think this is necessary?

You are right an id method with logic could exist in 4 lines of code, but for what purpose?

Comment by Marco Pivetta [ 15/Jan/12 ]

First of all it is a question of concept. Doctrine shouldn't assume anything about entities outside of their fields. It already introduces a level of complication when we explain how to clone/serialize objects, which was very confusing.

Asking for the purpose of an identifier field getter method is in my opinion again an attempt of making assumptions over user's code...

What if the user wrote something like:

public function getIdentifierField1()

{ return $this->identifierField1? $this->_myInitializationStuff() : null; }

private function _myInitializationStuff()

{ //open files, check stuff, make things difficult for the D2 team :D }

For instance, opening file handlers, sockets, whatever... This is a case that would break the entity because of optimization introduced by the ProxyFactory. (not to mention when getIdentifierField1 does some conversion, like return $this->identifierField1 + self::OFFSET_REQUIRED_BY_WEBSERVICE;

I'm not arguing about the validity of this optimization, but that the checks are too lazy.

I've read something about moving the ProxyFactory to common and using code scanner tools, and the check should be about applying the optimization only when the form is

return $this->identifierField1;

That's why I put the example of the regex. That would probably not be as safe as using some reflection-based tool, but surely more than just checking if the code is <= 4 lines...

Comment by Marco Pivetta [ 15/Jan/12 ]

Also don't know what stuff like EAccelerator (known in this Jira as of it's fantastic idea about stripping comments) would make the check of the 4 lines like.

Comment by Benjamin Eberlei [ 16/Jan/12 ]

This argument is void i just seen

A method:

public function getIdentifierField1()
{
   return $this->identifierField1? $this->_myInitializationStuff() : null;
} 

Will only used when the id is not set anyways.

In any other case Ids are Immutable and changing them in your code would break a lot more than just this smart proxy method generation.

Comment by Marco Pivetta [ 16/Jan/12 ]

Nope, this code actually works only if the ID is set
I'm not talking about changing IDs, it's just that getters and setters don't always reflect the class attributes...

Comment by Marco Pivetta [ 16/Jan/12 ]

As of IRC there's 3 ways (for now) to get this solved:

  • Some code scanner/stronger checks (difficult/problems with private methods/slow)
  • Regex (as of description)
  • Adding configuration (per-entity or per-method. Probably too messy)
  • Documenting it as "magic" of proxies and let the users be aware of it




[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-1588] There is no way to get the Query's result cache impl without going to EM Created: 08/Jan/12  Updated: 09/Jan/12  Resolved: 09/Jan/12

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

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


 Description   

Ok, my problem is this:

I have created a Query object. Now I'd like to get it's result cache driver.

My options:
1) Ask QueryCacheProfile for the driver. I can, but it's never populated by default so I always get just NULL.
2) Ask Query with getResultCacheDriver(), but wait, I can't, that's now deprecated
3) Ask from EM's configuration the result cache driver. This always works.

I propose that either the QueryCacheProfile is always populated with the Query's default result cache impl unless specifically overridden for the QueryCacheProfile

OR

Make getResultCacheDriver() not deprecated. Like the other two related methods, they are not deprecated, why should this one. Calling this could populate the QueryCacheProfile for future use like all the other (get cache ttl, id) methods.

My problem with with option 3) is "leaving the context of my method and the Query" (mentally of course). Why should I have to go poke around in EM's configuration when the result cache IS (or is easily obtainable behind the scenes) in the query object anyways?



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

Weird, this code looks very strange. I will check and fix that before the 2.2 RC release.

Comment by Benjamin Eberlei [ 09/Jan/12 ]

The default result cache is now passed to any new query cache profile. The following API is now working as expected:

$query->useResultCache(true);
$cache = $query->getQueryCacheProfile()->getResultCacheDriver();
Comment by Matti Niemelä [ 09/Jan/12 ]

That's perfect! Thank you!





[DDC-1585] Doctrine2 doesn't check for the correct entity type on @ManyToOne relations Created: 07/Jan/12  Updated: 15/Jan/12  Resolved: 15/Jan/12

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

Type: Bug Priority: Major
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates DBAL-479 Doctrine2 schema-tool:update doesn't ... Resolved

 Description   

I made a mistake when creating a @ManyToOne entity:

/**

  • @ManyToOne(targetEntity="Entities\EntityA")
    */
    private $test;

However, I was setting Entities\EntityB into $test.

Doctrine2 doesn't check for this, resulting in a hard-to-find issue.



 Comments   
Comment by Guilherme Blanco [ 13/Jan/12 ]

Duplicated

Comment by Benjamin Eberlei [ 15/Jan/12 ]

This is not a duplicate, its a runtime issue in the code when setting the wrong target entity type.

Comment by Benjamin Eberlei [ 15/Jan/12 ]

Implemented an instanceof check.





[DDC-1577] Remove static Reflection dependency from ClassMetadata Created: 03/Jan/12  Updated: 03/Jan/12  Resolved: 03/Jan/12

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

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

Issue Links:
Reference
relates to DCOM-93 Add Reflection Abstraction Resolved

 Description   

See DCOM-93 for more information






[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-1554] GH-235: Allow ExporterDrivers that implement the exportClassMetadata() function to return false Created: 22/Dec/11  Updated: 03/Jan/12  Resolved: 28/Dec/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2-BETA2, 2.2
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/235

Allow ExporterDrivers that implement the exportClassMetadata() function to return FALSE when no content is available/needs to be written to a file by the AbstractExporter, preventing empty files to be generated foreach processed ClassMetadataInfo instance.

I'm currently generating Data Transfer Object class for my Entities, but not all Entities require it. Based on an Annotation I determine which DTO's will be generated and return FALSE otherwise. Currently this 'negative' return is not respected and a lot of empty files are created.






[DDC-1548] One to one entity badly populated Created: 19/Dec/11  Updated: 19/Dec/11  Resolved: 19/Dec/11

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

Type: Bug Priority: Critical
Reporter: Asmir Mustafic Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

ubuntu php 5.3.8


Attachments: File 1548.php    

 Description   

One to one entity over populated



 Comments   
Comment by Asmir Mustafic [ 19/Dec/11 ]

I have created a test.

the bug may be in \Doctrine\ORM\Internal\Hydration\AbstractHydrator at line 246.

i think...

remove
if ( ! isset($rowData[$dqlAlias][$cache[$key]['fieldName']]) || $value !== null) {

and replace with :

if ( ! isset($rowData[$dqlAlias][$cache[$key]['fieldName']]) && $value !== null) {

this will fix the bug

Comment by Guilherme Blanco [ 19/Dec/11 ]

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

Thanks a lot for the report and patch! =D

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Update fix version, this was merged into 2.1.5





[DDC-1547] GH-228: Fixed testsuite Created: 19/Dec/11  Updated: 03/Jan/12  Resolved: 28/Dec/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2-BETA2, 2.2
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/228






[DDC-1546] another incorrect mapping not detected by orm:validate-schema Created: 18/Dec/11  Updated: 19/Dec/11  Resolved: 19/Dec/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.1.1
Fix Version/s: 2.2

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

Linux Debian Squeeze, MySQL



 Description   

Several lines like this one:

<field name="upgrades" type="int" column="Upgrades"/>

Were not flagged by orm:validate-schema as incorrect. Updating a related entity revealed the problem ("int" not being a proper type) at runtime.

Bug: orm:validate-schema should throw an error on incorrect column type.



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

Keep it coming, very valuable

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Fixed, but referenced with wrong ticket in master right now.





[DDC-1545] Update on loaded association not detected upon flush() Created: 18/Dec/11  Updated: 19/Dec/11  Resolved: 19/Dec/11

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

Type: Bug Priority: Critical
Reporter: Bernhard Schussek Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

If an association is joined during fetching and then updated in-memory, the update is not detected during flushing. I made the following test cases:

Association is joined:

  • change NULL → entity: does not work
  • change entity → NULL: works
  • change entity1 → entity2: does not work

Assocation is not joined:

  • change NULL → entity: works
  • change entity → NULL: works
  • change entity1 → entity2: works


 Comments   
Comment by Bernhard Schussek [ 18/Dec/11 ]

See here for the test case: https://github.com/bschussek/doctrine-orm/tree/DDC-1545

Comment by Guilherme Blanco [ 19/Dec/11 ]

Increasing priority

Comment by Guilherme Blanco [ 19/Dec/11 ]

Issue fixed since this commit:

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

Thanks a lot for the bug reporting. It was the second time someone reported me this issue and I could not reproduce! =)

Comment by Benjamin Eberlei [ 19/Dec/11 ]

This issue is referenced in Github Pull-Request GH-229
https://github.com/doctrine/doctrine2/pull/229

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/229

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Fixed properly now. Will be merged into 2.1.x

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Update fix version, this was merged into 2.1.5





[DDC-1544] Interfaces as target entity + event to resolve them to an implementation Created: 17/Dec/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

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


 Description   

Idea is:

/**
 * @ManyToOne(targetEntity="UserInterface")
 */

Would fire "onResolveTargetEntity" which is supposed to return details for resolving the interface to an actual implementation.



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

This issue is referenced in Github Pull-Request GH-222
https://github.com/doctrine/doctrine2/pull/222

Comment by Benjamin Eberlei [ 17/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/222

Comment by Benjamin Eberlei [ 17/Dec/11 ]

This issue is referenced in Github Pull-Request GH-223
https://github.com/doctrine/doctrine2/pull/223

Comment by Benjamin Eberlei [ 17/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/223





[DDC-1541] ClassMetadataBuilder has some name discrepancy in calls to AssociationBuilder methods Created: 16/Dec/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

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


 Description   

ClassMetadataBuilder class has some methods defined that call methods on AssociationBuilder class by different names, specifically the (set) part . e.g.

ClassMetadataBuilder method addManyToOne, calls setInversedBy, but is defined in AssociationBuilder as inversedBy. This trows a call to undefined method.

Which one is it ?



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

Fixed.





[DDC-1539] QueryException occurs when parentheses exist on the left-hand of comparison Created: 14/Dec/11  Updated: 20/Dec/11  Resolved: 20/Dec/11

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

Type: Bug Priority: Minor
Reporter: Koji Ando Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

When I executed the following DQL, I get an error.

 
> php scripts/doctrine.php orm:run-dql "select o from OrderDetail o where (o.price + o.tax) * o.count > 10000"

  [Doctrine\ORM\Query\QueryException]
  [Syntax Error] line 0, col 69: Error: Expected =, <, <=, <>, >, >=, !=, got ')'

When I swap the left-hand expression and right-hand one, no error occurs.

> php scripts/doctrine.php orm:run-dql "select o from OrderDetail o where 10000 < (o.price + o.tax) * o.count"

array
  empty


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

This issue is referenced in Github Pull-Request GH-233
https://github.com/doctrine/doctrine2/pull/233

Comment by Guilherme Blanco [ 20/Dec/11 ]

Fixed in https://github.com/doctrine/doctrine2/commit/4bc014c6961be2e24b131d06d25c885fdf07bc3b

Comment by Benjamin Eberlei [ 20/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/233





[DDC-1537] GH-214: Fixed typo in the XmlDriver Created: 13/Dec/11  Updated: 14/Dec/11  Resolved: 14/Dec/11

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

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


 Description   

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



 Comments   
Comment by Guilherme Blanco [ 14/Dec/11 ]

Merged





[DDC-1536] GH-213: QueryBuilder::getQuery Created: 13/Dec/11  Updated: 14/Dec/11  Resolved: 14/Dec/11

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

Hi there,
I'm wondering myself if the QueryBuilder::getQuery is a good method name.
Actually, a getMethodObject makes me think that I can use many times the getMethodObject and work with the same object.
e.g :

```php
$qb->getQuery()->useResultCache (true);
$qb->getQuery()->execute();
```
In my code, the problem is that getQuery return a new instance of Query each time that I call getQuery.
Furthermore, the getQuery method invoke a createQuery method.

So, maybe the QueryBuiler::getQuery can store a reference to the created Query instance, and if the QueryBuilder::getQuery is call many times without any change return the stored instance.
If the QueryBuilder::getQuery have to generate a new Query, throw an exception or something like that.

Because of a change to QueryBuilder::createQuery is a major change, I don't think that It could be the solution, but it's a reflexion around this.

What do you think about that ?



 Comments   
Comment by Guilherme Blanco [ 14/Dec/11 ]

This includes a BC break.
Marking as won't fix.





[DDC-1531] Documentation references no-longer available constant Lexer::T_ABS Created: 13/Dec/11  Updated: 14/Dec/11  Resolved: 14/Dec/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Documentation
Affects Version/s: Git Master
Fix Version/s: 2.2

Type: Documentation Priority: Major
Reporter: Erik Bernhardson Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Line 645 of https://github.com/doctrine/orm-documentation/blob/master/en/reference/dql-doctrine-query-language.rst

Best i can tell this has been re-named to Lexar::T_IDENTIFIER by looking at other functions in the distribution



 Comments   
Comment by Guilherme Blanco [ 14/Dec/11 ]

Fixed in https://github.com/doctrine/orm-documentation/commit/373090f2232a59b7c4cb35212a1c1d5843bc8be7





[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





[DDC-1524] NamedQueries annotation doesn't work with just one NamedQuery Created: 09/Dec/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

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

Attachments: File AnnotationDriver.php    

 Description   

NamedQueries annotation doesn't work with just one NamedQuery

the problem is locale in the class Doctrine\ORM\Mapping\Driver\AnnotationDriver line 179.

Is needed validate if var $namedQueriesAnnot->value is an array before try perform foreach statement.

Please I'm sorry for my bad English.

Thank you



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

Why dont you define the named queries as array? just @NamedQuery(

{...}

) ?

Also please consider attaching a diff of your patch, not the whole changed class.

Comment by Benjamin Eberlei [ 17/Dec/11 ]

Added better validations.





[DDC-1523] Coalesce() does not work with functions Created: 09/Dec/11  Updated: 10/Dec/11  Resolved: 10/Dec/11

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

Type: Bug Priority: Major
Reporter: Martin Prebio Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

I wanted to use COALESCE in DQL with a function (e.g. CURRENT_TIMESTAMP()). If I run this DQL, I receive a syntax error exception like this one:

montbook:marlow mprebio$ php scripts/doctrine.php orm:run-dql "select COALESCE(CURRENT_TIMESTAMP()) from Project\Entity\User user"

[Doctrine\ORM\Query\QueryException]
[Syntax Error] line 0, col 33: Error: Expected Doctrine\ORM\Query\Lexer::T_CLOSE_PARENTHESIS, got '('

I've traced this error to Doctrine\ORM\Parser::ScalarExpression() which tries to interpret the current_timestamp function as a SimpleArithmeticExpression or as a StateFieldPathExpression (first if). As far as I understand this part of the parser, the function call should lead to the if part with $this->_isFunction(). Therefore I added a "and !$this->_isFunction()" to the first if clause. After this change everything works as expected: The above query returns the current timestamp (many times because of the from since DQL needs a from part).

Reordering the ifs should work too.



 Comments   
Comment by Martin Prebio [ 09/Dec/11 ]

Also the documentation at http://www.doctrine-project.org/docs/orm/2.1/en/ only mentions COALESCE in the EBNF but not in the real documentation part. At first I thought that Doctrine doesn't support coalesce at all.

Comment by Guilherme Blanco [ 10/Dec/11 ]

COALESCE does not exist on 2.1.
COALESCE is a 2.2-DEV, so use latest master.

Marking as invalid, since we won't change 2.1 to support this.





[DDC-1517] find/getReference break on invalid or missing identifier fields Created: 01/Dec/11  Updated: 01/Dec/11  Resolved: 01/Dec/11

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

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





[DDC-1508] ClassMetadataBuilder only accepts ClassMetadata not *Info Created: 23/Nov/11  Updated: 09/Dec/11  Resolved: 09/Dec/11

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

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


 Comments   
Comment by Guilherme Blanco [ 09/Dec/11 ]

Fixed since https://github.com/doctrine/doctrine2/commit/0febf0611439e05abbb1bf4b4e9668f7ad125c67





[DDC-1503] Add support for executing custom SQL functions on custom types Created: 02/Jun/10  Updated: 09/Mar/12  Resolved: 21/Nov/11

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

Type: New Feature Priority: Minor
Reporter: Dylan Arnold Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 6
Labels: None

Attachments: File 022-doctrine-basic-entity-persister.diff     File 024-doctrine-many-to-many-persister.diff     File 025-doctrine-unit-of-work.diff     File 029-doctrine-query.diff     File doctrine-type.diff    
Issue Links:
Duplicate
is duplicated by DBAL-53 Missing convertToDatabase-calls when ... Resolved

 Description   

I have created a custom type called point but need a way to have a function called on columns of this type when fetching / updating / inserting entities.

For example:

Consider I have an entity which has a column called the_geom

This is associated with my custom type point

A basic select statement for this entity is as follows:

SELECT id, name, the_geom FROM points where id = 1

The problem is the_geom is encoded and on the PHP side I want it in human readable form. I would like a way to specify custom functions on SELECT / INSERT / UPDATE for columns of this custom type.

When selecting my entity I would like to execute the function ST_AsText(the_geom)

SELECT id, ST_AsText(the_geom) FROM points where id = 1

The same goes for updates and inserts. I would like to surround the column SQL with other custom functions, to encode my human readable text back to the encoded value for the DB.

Possibly this could be integrated into Doctrine\DBAL\Types\Type ?

// Modify the column SQL for insert
public function getSqlInsertColumn(....)
// Modify the column SQL for update
public function getSqlUpdateColumn(....)
// Modify the column SQL for select
public function getSqlSelectColumn(....)
// A possible example of getSqlSelectColumn(...)
public function getSqlSelectColumn($doctrineSql)
{
    // $doctrineSql == "p0_.the_geom"
    return 'ST_AsText(' . $doctrineSql . ')';
}


 Comments   
Comment by Benjamin Eberlei [ 04/Jun/10 ]

You can only fetch entities using the normalized value of any field, that means you have to find a common transformation that is saved in your entities and then converted on the fly.

There is a default converting method from database to PHP and back you could use, however this is only in one direction. You could define a class for the Point and convert from and to this Call in your Type. This way you could encapsualte all the converting logic in an object and your entities only use the object.

You can extend DQL to have additional queries, however when you select additional fields in DQL and apply a function to them, they are retrieved as scalar and not inside your entity. How to do this is detailed in the manual and the cookbook.

Comment by Benjamin Eberlei [ 04/Jun/10 ]

Closed, there are already extension points that help with this matter-

Comment by Dylan Arnold [ 04/Jun/10 ]

Hi Benjamin.

Thanks for your response.

I don't fully understand what you mean. As far as I can tell this is a specific use case that is not supported by doctrine.

What I have tried is creating an entity that contains a field named $point. This is of my custom type PointType which extends Doctrine\Dbal\Types\Type

In this method I intended to create my own Geometry\Point object by parsing a human readable value returned from the database and seamlessly converting to and from this value in convertToDatabaseValue($value, AbstractPlatform $platform) and convertToPHPValue($value, AbstractPlatform $platform)

The problem is that the column is in binary format and I need the database to decode it for me.

I also understand about extending DQL to use custom functions. If I went down this route, every time I fetch my entities, I would have to do an extra step to parse the scalar. Suddenly my domain logic is not encapsulated within my entity and I have a feeling this could end up being messy.

There is also another possibility as far as I can tell, using a NativeQuery, however this would mean that every time I fetch an entity I would have to do field mapping, and any time I didn't map the field to a function my entity would fail to decode the point and break, this route would also mean a lot of extra coding and care.

I am happy to accept that this use case may not be useful to a large portion of doctrine users and therefore may not be a justified addition to doctrine. I do however believe that this is a feature that would be nice to have, and others will miss it in the future, particularly in postgis integration.

Doctrine already has custom DQL and custom types. As a new user my opinion is that there is definitely some room for some advanced functionality in this area. However, you guys are the core devs, you understand the project and its internals so if this is a feature that should be left out then so be it. (I may just have to look into my own hack).

Kind regards

Comment by Benjamin Eberlei [ 12/Jul/10 ]

Re-opened, although this might possibly be a better ORM than DBAL extension. We have to re-evaluate this for 2.1

Comment by Benjamin Eberlei [ 20/Sep/10 ]

DBAL-53 highlightes a possible problem, how to handle foreign keys in this regard?

Comment by Benjamin Eberlei [ 24/Dec/10 ]

Idea: For each type, wrap the column in a possible conversion snippet:

class Type
{
    public function convertToDatabaseValueSQL($sqlExpr, $platform)
    {
        return $sqlExpr;
    }

    public function convertToPHPValueSQL($sqlExpr, $platform)
    {
        return $sqlExpr;
    }
}

Example:

class IPAddress extends Type
{
    public function convertToDatabaseValueSQL($sqlExpr, $platform)
    {
        return "INET_ATON($sqlExpr)";
    }

    public function convertToPHPValueSQL($sqlExpr, $platform)
    {
        return "INET_PTON($sqlExpr)";
    }
}

Conversion inside the ORM would take place at the following locations:

1. When generating SELECT SQL inside the persister, use the conversion in the SELECT clause.
2. When generating SELECT SQL from a DQL, use conversion in the SELECT clause.
3. When updating an entity inside the persister use this in the SET clause and WHERE clause for the ID.
4. When inserting an entity inside the persister use this in the VALUES clause.

Open questions:

1. Should conversion also be done for occurances in any other clauses other than SELECT?
2. Can we bear the performance impact of this on SQL generation.

Comment by Benjamin Eberlei [ 24/Dec/10 ]

Acttually thinking about it. It has to be everywhere when 3 is necessary (and DELETE WHERE also needs this) then of course the values should be converted for SELECT clauses WHERE also.

One Exception might be JOIN clauses WHERE its better to have:

a.foo = b.foo

vs

FUNC(a.foo) = FUNC(b.foo)
Comment by Benjamin Eberlei [ 10/Mar/11 ]

I think we can optimize the performance of this considerably in the ORM by adding a field option "requiresSQLConversion" that is only set if a boolean method "requiresSQLConversion()" on the type returns true. This method gets a default implementation in abstract type of:

public function requiresSQLConversion()
{
  return false;
}

Every complex type would need to overwrite this method.

Then inside ORM we would only need to check if (isset($field['requiresSQLConversion'])) to determine if we have to modify the SQL or not. Also caching structure would only grow by this option if the variable is actually true.

Comment by Lars Strojny [ 02/May/11 ]

As DBAL-53 has been closed as a duplicate of this one, I'm attaching our patches to make type conversion work

Comment by Benjamin Eberlei [ 15/May/11 ]

Thanks Lars, this is something else what i would implement though.

This ticket gets high priority for 2.2, i will implement and check in directly after 2.1 will be released end of next month.

Comment by Benjamin Morel [ 14/Oct/11 ]

Added a missing type hint in DBAL\Types\Type.php

Will this feature be implemented soon? convertToDatabaseValueSQL() and convertToPHPValueSQL() are not used anywhere yet...

Comment by Benjamin Eberlei [ 21/Nov/11 ]

Implemented.

Comment by Benjamin Morel [ 09/Mar/12 ]

What about the missing type hint on convertToPHPValueSQL() ?

Is there a reason for the inconsistency in these method declarations:

public function convertToDatabaseValueSQL($sqlExpr, AbstractPlatform $platform)
public function convertToPHPValueSQL($sqlExpr, $platform)





[DDC-1502] SQLite should eat prefixed tables (since they dont exist) Created: 21/Nov/11  Updated: 21/Nov/11  Resolved: 21/Nov/11

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

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


 Description   

People use schema or many databases, however SQLite does not support the foo.bar syntax, so there is no way to run the tests in sqlite memory against these setups.



 Comments   
Comment by Benjamin Eberlei [ 21/Nov/11 ]

Implemented





[DDC-1492] Fatall error: Cannot use object as array in ORM\Internal\Hydration\ObjectHydrator.php on line 314 Created: 13/Nov/11  Updated: 15/Nov/11  Resolved: 15/Nov/11

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

Type: Bug Priority: Blocker
Reporter: Konstantin Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Symfony2, Doctrine 2.1.1 (also bug present on 2.1.3-dev - latest revison of 2.1.x branch)



 Description   

My entities

event
eveht.event_area_id=event_area.id (1:1)
event_area.event_id=event.id (1:1)
event_area.area.id=area.id (one area has many event_area's)
area.parent_id=area_id (hierarchial)
event.author_id=user.id (one user has many events)

area - STI: District/City/Region/Country/etc.

SELECT
	r, ra, a, ap, au, DATE(r.eventTime) AS event_date
FROM OloloEventsBundle:Event r
	LEFT JOIN r.eventArea ra
		LEFT JOIN ra.area a
			LEFT JOIN a.parent ap
	INNER JOIN r.author au WHERE r.eventTime <= :r_eventtime AND ra.area IN(:ra_area)
GROUP BY r
ORDER BY event_date DESC

This DQL caused an error "Cannot use object of type District as array in ORM\Internal\Hydration\ObjectHydrator.php on line 314". When I'm removing `ap` friom fetching - it works. Mapping are correct - there are many other places where it works correctly.



 Comments   
Comment by Benjamin Eberlei [ 13/Nov/11 ]

On 2.1.1 line 314 is a "}". Can you restate the line and add a stack trace if possible (xdebug or phpunit can help there).

Comment by Konstantin [ 13/Nov/11 ]

Sorry, line was changed cause I've updated to 2.1.3-dev.

( ! ) Fatal error: Cannot use object of type Ololo\Bundle\TerritorialBundle\Entity\District as array in Z:\home\dev\Ololo\code\vendors\Doctrine\Orm\lib\Doctrine\ORM\Internal\Hydration\ObjectHydrator.php on line 308
Call Stack
#	Time	Memory	Function	Location
1	0.0006	333520	{main}( )	..\index_dev.php:0
2	0.0254	1435584	Symfony\Component\HttpKernel\Kernel->handle( )	..\index_dev.php:20
3	0.2454	3634168	Symfony\Bundle\FrameworkBundle\HttpKernel->handle( )	..\Kernel.php:171
4	0.2454	3634576	Symfony\Component\HttpKernel\HttpKernel->handle( )	..\HttpKernel.php:44
5	0.2454	3634576	Symfony\Component\HttpKernel\HttpKernel->handleRaw( )	..\HttpKernel.php:71
6	0.3589	5534264	call_user_func_array ( )	..\HttpKernel.php:117
7	0.3590	5534448	Ololo\Bundle\DistrictsBundle\Controller\DistrictController->EventsPastAction( )	..\HttpKernel.php:0
8	1.1606	13782464	Ololo\Bundle\EventsBundle\Entity\EventRepository->getPastEventsByAreasIds( )	..\DistrictController.php:145
9	1.1607	13783520	Ololo\Bundle\EventsBundle\Entity\EventRepository->getEventsSliceBySpecification( )	..\EventRepository.php:385
10	1.2010	14224216	Doctrine\ORM\AbstractQuery->getResult( )	..\EventRepository.php:477
11	1.2010	14224368	Doctrine\ORM\AbstractQuery->execute( )	..\AbstractQuery.php:392
12	3.3409	14781264	Doctrine\ORM\Internal\Hydration\AbstractHydrator->hydrateAll( )	..\AbstractQuery.php:594
13	3.3412	14785824	Doctrine\ORM\Internal\Hydration\ObjectHydrator->_hydrateAll( )	..\AbstractHydrator.php:99
14	3.3413	14798576	Doctrine\ORM\Internal\Hydration\ObjectHydrator->_hydrateRow( )	..\ObjectHydrator.php:140
                    $parentObject = $this->_resultPointers[$parentAlias][key($first)]; // trouble here, $this->_resultPointers[$parentAlias] is object of District
Comment by Guilherme Blanco [ 14/Nov/11 ]

Hi.

If you change this line:

$parentObject = $this->_resultPointers[$parentAlias][key($first)];

To this:

$parentObject = $first[key($first)];

Does it work for you?

Comment by Konstantin [ 14/Nov/11 ]

yes, with this line of code this query works.

Comment by Guilherme Blanco [ 15/Nov/11 ]

https://github.com/doctrine/doctrine2/commit/77e076f1fdbe24fdb2f5a1fb1842c0b9cb7d95a4

This issue was fixed in master.
I requested Benjamin to merge this with 2.1 branch.

Thanks





[DDC-1491] Bug in SchemaValidator diffing join columns Created: 13/Nov/11  Updated: 13/Nov/11  Resolved: 13/Nov/11

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

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


 Comments   
Comment by Benjamin Eberlei [ 13/Nov/11 ]

Fixed in 2.2-dev as its only relevant in an error message displaying





[DDC-1490] Generated Ids with Sequence/Auto Increment Generators not always casted to int Created: 13/Nov/11  Updated: 13/Nov/11  Resolved: 13/Nov/11

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

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


 Description   

The Id Generators don't necessarily cast ids to integer values when generating them.



 Comments   
Comment by Benjamin Eberlei [ 13/Nov/11 ]

Fixed





[DDC-1482] GH-160: Allow to unset one-to-one relation with generated class Created: 08/Nov/11  Updated: 07/Jun/12  Resolved: 13/Nov/11

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

Type: Improvement 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/160

Added <variableDefault> on generated class.
This generate methods like:
```function setGroup(Group $group = null){
}
```

that allow to remove "Group" association if the relation is one-to-one.

Plus some indentation issue



 Comments   
Comment by Benjamin Eberlei [ 13/Nov/11 ]

Merged

Comment by Benjamin Eberlei [ 07/Jun/12 ]

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

Comment by Benjamin Eberlei [ 07/Jun/12 ]

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





[DDC-1481] GH-158: Collapsed cascade elements, if cascade-all. Created: 08/Nov/11  Updated: 06/Jun/12  Resolved: 18/Nov/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2
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/158

Collapsed cascade elements, if cascade-all.
(better readability for generated xml)



 Comments   
Comment by Benjamin Eberlei [ 18/Nov/11 ]

implemented

Comment by Benjamin Eberlei [ 06/Jun/12 ]

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





[DDC-1479] GH-169: preFlush event and lifecycle callback Created: 08/Nov/11  Updated: 10/Jul/12  Resolved: 13/Nov/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2
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/169

For now, we have `@PrePersist`, `@PreUpdate` and `@PreRemove` callbacks. But it's not enough, cuz in some cases we need to run some entity method just before *every* `EntityManager#flush()` call (examples - translatable behavior and file uploading routines).

I've added and tested new `@PreFlush` event, which occurs during the start of the `EntityManager#flush()`, before any changeset gets calculated. This gives users ability to hook into flush process and prepare their entities to save even if they were not changed.



 Comments   
Comment by Benjamin Eberlei [ 13/Nov/11 ]

Merged into master

Comment by Benjamin Eberlei [ 09/Jul/12 ]

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

Comment by Benjamin Eberlei [ 10/Jul/12 ]

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





[DDC-1478] GH-175: added EntityRepository::getClassName() Created: 08/Nov/11  Updated: 03/Feb/14  Resolved: 13/Nov/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2
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/175

added EntityRepository::getClassName() to fullfill the ObjectRepository interface

see https://github.com/doctrine/common/pull/70



 Comments   
Comment by Benjamin Eberlei [ 13/Nov/11 ]

Merged

Comment by Doctrine Bot [ 03/Feb/14 ]

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





[DDC-1476] Yaml Driver doesn't default field types to string Created: 08/Nov/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

Type: Bug Priority: Minor
Reporter: Anton Stoychev Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None
Environment:

All



 Description   

Doctrine documentation states that a field default value is a string.
The annotation driver behaves so but the Yaml driver doesn't.

The Yaml driver requires that a field is set a type explicitly.

Why is this different among drivers and what is the actual default behaviour?



 Comments   
Comment by Benjamin Eberlei [ 14/Nov/11 ]

Merged





[DDC-1472] WHERE <<function>> IN ... doesn't work Created: 06/Nov/11  Updated: 04/Dec/11  Resolved: 04/Dec/11

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

Type: Bug Priority: Minor
Reporter: Christoph Krämer Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

I have a query which is supposed to compare a result of a user defined function with a set of possible results
SELECT ... WHERE YEAR(w.date) IN (.......)

But I get the error:
[Syntax Error] line 0, col 49: Error: Expected Doctrine\ORM\Query\Lexer::T_IN, got '('

If I only compare the result of the function with a single value everything works as aspected:
SELECT ... WHERE YEAR(w.date) = 2011
.. works!

I also testet it with other functions like DATE_DIFF, etc. but always get the same error.



 Comments   
Comment by Guilherme Blanco [ 04/Dec/11 ]

Fixed in master since this commit: https://github.com/doctrine/doctrine2/commit/0380d5ae580dcbefd63051028fc1ab78599fda6c





[DDC-1468] Exception verbose: Id in a mapped-superclass Created: 04/Nov/11  Updated: 20/Dec/13  Resolved: 19/Dec/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.1
Fix Version/s: 2.2

Type: Improvement Priority: Minor
Reporter: Francois Mazerolle Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   

Some exception could/should be more precise (I've lost a lot of time figuring out why I was having an error)

When you have an id field inside a mapped-superclass, you get the following exception:

[ErrorException]
Notice: Undefined index: IdealTech\OnlineSystem\GeoBundle\Entity\AbsAddress in /Users/fmazerolle/Sites/it/os/vendor/doctrine/lib/Doctrine/ORM/Mapping/Driver/AbstractFileDriver.php line 121

The exception should be more verbose and tell the real cause of the error.



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

This issue is referenced in Github Pull-Request GH-219
https://github.com/doctrine/doctrine2/pull/219

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/219

Comment by Guilherme Blanco [ 19/Dec/11 ]

Fixed in https://github.com/doctrine/doctrine2/commit/f6d9344d892e5e959b4474437258b02777b41eb1

Comment by Doctrine Bot [ 03/Dec/13 ]

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

Comment by Doctrine Bot [ 20/Dec/13 ]

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





[DDC-1463] Inner join eagerly loaded entities if possible Created: 31/Oct/11  Updated: 31/Oct/11  Resolved: 31/Oct/11

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

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


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

Merged





[DDC-1461] Possible Regression with OneToOne relation Created: 31/Oct/11  Updated: 13/Nov/11  Resolved: 13/Nov/11

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-1506 Possible Regression with OneToOne rel... Sub-task Open Benjamin Eberlei  

 Description   

I have the following relations:

namespace Model;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity(repositoryClass="Model\Repository\UserRepository")
 * @ORM\ChangeTrackingPolicy("DEFERRED_EXPLICIT")
 * @ORM\HasLifecycleCallbacks
 * @ORM\Table(name="users")
 */
class User
{
    /**
     * @ORM\OneToOne(targetEntity="Model\TwitterAccount", orphanRemoval=true, fetch="EAGER", cascade = {"persist"}, inversedBy="user")
     * @var TwitterAccount
     */
    private $twitterAccount;
}

/**
 * @ORM\Entity(repositoryClass = "Model\Repository\TwitterAccountRepository")
 * @ORM\Table(name = "twitter_accounts")
 * @ORM\ChangeTrackingPolicy("DEFERRED_EXPLICIT")
 */
class TwitterAccount
{
    /**
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     * @ORM\Column(type="integer")
     */
    private $id;

    /**
     * @ORM\OneToOne(targetEntity="Model\User", fetch="EAGER")
     */
    private $user;
}

now when I add a new account, the user-side is not updated with the id of the account, but the account is still saved to the database.

$twitterAccount = new TwitterAccount();
$user->setTwitterAccount($twitterAccount);
$em->persist($user);
$em->flush();

The twitterAccount_id of the users table is empty, but the new account is added to the "twitter_accounts" table with the correct user_id.



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

Do you know when this started to happen ?

Comment by Johannes Schmitt [ 31/Oct/11 ]

I have reverted some commits of the ORM, but it doesn't seem to have happened recently, or it is a combination of different changes in one of the repositories.

What's weird is that the error does not occur when the user is new, but only if it already exists. It seems like somehow the UOW does not detect that it has changed.

Comment by Benjamin Eberlei [ 13/Nov/11 ]

This is deferred explicit related it seems.

Comment by Benjamin Eberlei [ 13/Nov/11 ]

Verified

Comment by Benjamin Eberlei [ 13/Nov/11 ]

Hm no, it works for me.

See https://github.com/doctrine/doctrine2/commit/e8eda4aeae3a24c52a0b69d01946b93c5a9cba27 and reopen if you can make it fail.





[DDC-1458] Issue with tracking entity changes Created: 28/Oct/11  Updated: 11/Nov/11  Resolved: 10/Nov/11

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

Type: Bug Priority: Critical
Reporter: Maxim Assignee: Alexander
Resolution: Fixed Votes: 0
Labels: None
Environment:

linux/ubuntu, nginx, php-cgi, symfony framework



 Description   

Flushing at point #2 has no effect (outputs int(1)), flushing at point #1 works as expected (outputs int(5)).
this issue comes only when i trying to set boolean value on managed assotiated entity

upd. same issue with datetime properties

/**
 * @ORM\Entity
 */
class TestEntity
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
    /**
     * @ORM\Column(type="integer")
     */
    protected $value;
    /**
     * @ORM\OneToOne(targetEntity="TestAdditionalEntity", inversedBy="entity", orphanRemoval="true", cascade={"persist", "remove"})
     */
    protected $additional;
}

/**
 * @ORM\Entity
 */
class TestAdditionalEntity
{
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;
    /**
     * @ORM\OneToOne(targetEntity="TestEntity", mappedBy="additional")
     */
    protected $entity;
    /**
     * @ORM\Column(type="boolean")
     */
    protected $bool;
    
    public function __construct()
    {
        $this->bool = false;
    }
}

$test = new \TestEntity();
$test->setValue(1);
$test->setAdditional(new \TestAdditionalEntity());

$em->persist($test);
$em->flush();
$em->clear();

$test = $em->getRepository('Bundle:TestEntity')->find(1);
$test->setValue(5);

// point #1
$test->getAdditional()->setBool(true);
// point #2

$em->flush();

var_dump($test->getValue());


 Comments   
Comment by Alexander [ 08/Nov/11 ]

Looking into this.

Comment by Benjamin Eberlei [ 09/Nov/11 ]

formatting

Comment by Alexander [ 10/Nov/11 ]

Fixed in master:
https://github.com/doctrine/doctrine2/pull/187

Comment by Benjamin Eberlei [ 11/Nov/11 ]

Merged into 2.1.x





[DDC-1457] Wrong return annotation for UnitOfWork::getEntityPersister() method Created: 26/Oct/11  Updated: 04/Dec/11  Resolved: 04/Dec/11

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

Type: Documentation Priority: Minor
Reporter: Aigars Gedroics Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

It is

@return Doctrine\ORM\Persisters\AbstractEntityPersister

should be (I suppose)

@return \Doctrine\ORM\Persisters\BasicEntityPersister

or

@return Persisters\BasicEntityPersister


 Comments   
Comment by Guilherme Blanco [ 04/Dec/11 ]

Fixed in trunk

Commit ref: https://github.com/doctrine/doctrine2/commit/a26990c3e8693134a2789c4c7c57d6f053f01fcf





[DDC-1456] Sequence doesn't work correctly when sequence is defined second in a composite key Created: 26/Oct/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

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

Oracle



 Description   

When using a sequence in Oracle as part of a composite key and the sequence is defined second, Doctrine retrieves from the sequence correctly but incorrectly assigns to the first key (which in this case is not the correct column)

Example:

/Entity/ItemModel.php
/**
 * @Column(name="submission_id", type="integer")
 * @Id
 */
private $submissionId;

/**
 * @Column(name="model_id", type="integer")
 * @Id
 * @GeneratedValue(strategy="AUTO")
 * @SequenceGenerator(sequenceName="model_id_seq", initialValue=1, allocationSize=1)
 */
private $modelId;

Doctrine correctly retrieves the sequence, however it then attempts to set the first identifier field (in this case submission_id) instead of the sequence key.

The problem appears in /Doctrine/ORM/UnitOfWork.php line 613.
$class->indentifier is hard coded to item 0.

$this->entityIdentifiers[$oid] = array($class->identifier[0] => $idValue);

You can workaround this issue by defining the sequence first in the entity.



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

This is not allowed currently, there is a PR for custom id generators, but so long i am closing this as invalid.

Also i added an error exception which makes this kind of setup fail.





[DDC-1455] Selecting association id (FK) without join Created: 26/Oct/11  Updated: 07/Nov/11  Resolved: 07/Nov/11

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

Type: New Feature Priority: Major
Reporter: Wladimir Coka Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

It might be a missing feature or I might be doing something wrong. I need to select an association (FK) without the need of a join.

I'm trying something like this:

select i.client.id , count(i) as total 
from \Invoice i 
GROUP BY i.client

But I get this error:
Error: Expected Doctrine\ORM\Query\Lexer::T_FROM, got '.'



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

Try

SELECT i.client, count(i) AS total
Comment by Guilherme Blanco [ 07/Nov/11 ]

This is already supported in 2.2-DEV through IDENTITY() DQL function.

SELECT IDENTITY(i.client), count(i) as total 
  FROM \Invoice i 
 GROUP BY i.client




[DDC-1452] ObjectHydrator bug: hydration of entity with self (cyclic) relation through ref entity Created: 24/Oct/11  Updated: 15/Nov/11  Resolved: 14/Nov/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.2
Security Level: All

Type: Bug Priority: Critical
Reporter: Piotr Śliwa Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Attachments: File DDC1452Test.php     File DDC1452Test.php    

 Description   

ObjectHydrator has bug in hydrate entities with relation to entity of this same class throught reference entity. Example Model:

EntityA

  • id
  • title (string)
  • entitiesB (annotation: @ORM\OneToMany(targetEntity="EntityB", mappedBy="entityAFrom"))

EntityB

  • id
  • entityAFrom (annotation: @ORM\ManyToOne(targetEntity="EntityA", inversedBy="entitiesB"))
  • entityATo (annotation: @ORM\ManyToOne(targetEntity="EntityA"))
  • type (string)

Scenario:

Execution of dql query 'SELECT a, b, ba FROM EntityA AS a LEFT JOIN a.entitiesB AS b LEFT JOIN b.entityATo AS ba' with max results set to "1" and data in database:

EntityATable:
id | title
1 | a
2 | b

EntityBTable:
id | entityAFromId | entityAToId | type
1 | 1 | 2 | type

Resume:

I expected collection of EntityA object (size=1 becouse I set max results to 1) with hydrated entitiesB collection (size=1 becouse in db is only 1 record) and hydrated entityTo object. entitiesB property of entityTo object should be empty PersistCollection (ready to lazy load) but is null...

I can provide TestCase for this issue.



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

Attached a working testcase.

Please put it into tests/Doctrine/Tests/ORM/Functional/Ticket and run:

phpunit --group DDC-1452

Please make that test fail from your perspective, i think it reproduces your test-case exactly.

Comment by Piotr Śliwa [ 29/Oct/11 ]

Ok, I have fixed testcase to situation that I was talking about.

I have hardly debuged this issue, problem is in ObjectHydrator::_getEntity() method. This method delegates to UnitOfWork::createEntity() and passes $hints array. In $hints array, data about fetching associations is stored. In situation when one entity is joined throught two different associations (as in this testcase, first time DDC1452EntityA is used in from clause, second time in join clause) hydrator "minds" that objects from second association have have loaded association that is connecting entities of the same type. In testcase this is "entitiesB" association of "ba" aliased entity. That occurs, becouse $hints['fetched']['Namespace\DDC1452EntityA']['entitiesB'] has already been set on true while hydrating DDC1452EntityA objects from "FROM" clause. If in testcase had not been set limit for results, then this test would have to pass, becouse second object of DDC1452EntityA ($a2) would have to be load propertly as entity from "FROM" clause.

Comment by Benjamin Eberlei [ 29/Oct/11 ]

The explaination makes sense. I will dig into it.

Comment by Benjamin Eberlei [ 14/Nov/11 ]

This is fixed, but only in master. The code change necessary was pretty serious so i dont want to merge it into the stable branch without more people testing it.

Comment by Piotr Śliwa [ 15/Nov/11 ]

Great job, thanks!





Current event system is not flexible enough (DDC-1431)

[DDC-1449] Create postFlush event Created: 23/Oct/11  Updated: 23/Oct/11  Resolved: 23/Oct/11

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

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Create postFlush event



 Comments   
Comment by Benjamin Eberlei [ 23/Oct/11 ]

See https://github.com/doctrine/doctrine2/pull/168 - merged





[DDC-1448] Add a base entity to allow users to skip writing boilerplate code Created: 22/Oct/11  Updated: 19/Nov/11  Resolved: 19/Nov/11

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

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


 Description   

For forward compatibility with https://gist.github.com/1034079 we want to add a "BaseEntity" into the core that handles boilerplate code through implementing "__call" and using the metadata to generate getter/setter/adder/is methods on the fly.



 Comments   
Comment by Alexander [ 30/Oct/11 ]

Had some discussion about this on IRC:

  • the BaseEntity shouldn't do __callStatic since there are already repositories that do stuff like this
  • for php 5.3 it would be shipped as a class that can be extended
  • maybe some task that generates the trait from the class or the other way around
Comment by Benjamin Eberlei [ 19/Nov/11 ]

Implemented in Doctrine\Common\Persistence\PersistentObject.

This can be generically used by all ObjectManagers.





[DDC-1447] <orphan-removal /> BC? Created: 22/Oct/11  Updated: 15/Nov/11  Resolved: 15/Nov/11

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

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


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

This is not a bc, <orphan-removal /> was invalid all along, <n-to-m orphan-removal="true/false" /> is defined in the XSD mapping.





[DDC-1446] Evaluate to configure default "persist cascade" for all enties. Created: 22/Oct/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

Type: Improvement Priority: Major
Reporter: Benjamin Eberlei Assignee: Guilherme Blanco
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

.



 Comments   
Comment by Guilherme Blanco [ 14/Nov/11 ]

As we already discussed on IRC, this automation would open a can of worms. It cannot be implemented.





[DDC-1442] SimpleObject hydratation mode with inheritance Created: 20/Oct/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

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

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


 Description   

SimpleObject hydratation mode with inheritance, it appear that it's not working.

The problem start in SimpleObjectHydrator.php line 129 when calling UnitOfWork->createEntity(NULL, Array, Array).



 Comments   
Comment by Benjamin Eberlei [ 20/Oct/11 ]

in what context are you using simpleobjecthydrator?

Comment by Thomas Tourlourat - Armetiz [ 20/Oct/11 ]

It was just for testing this feature.

I have build this queryBuilder :

$queryBuilder	= $entityManager->createQueryBuilder();
$queryBuilder->select ("user");
$queryBuilder->from ("Entity\User", "user");
$queryBuilder->where ("user.idUser = 916");
$queryBuilder->getQuery()->execute (array(), \Doctrine\ORM\AbstractQuery::HYDRATE_SIMPLEOBJECT);

Entity\User extends an other Entity.

Comment by Benjamin Eberlei [ 27/Oct/11 ]

Can you maybe show how the User and Other entity are mapped? It seems your discriminator map could contain a problem, i couldnt reproduce it with our Joined Table Inheritance test entities so far.

Comment by Alexander [ 08/Nov/11 ]

Lowered the priority of this issue until we receive more feedback.

Comment by Benjamin Eberlei [ 18/Nov/11 ]

This was fixed recently by throwing an error message telling the user that his discriminator mapping is wrong.





[DDC-1439] Saving many to many association with composed keys. Created: 20/Oct/11  Updated: 31/Oct/11  Resolved: 31/Oct/11

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

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


 Description   

I have a problem with saving many to many realtion. My entities are.

calss Entity1 {
		
	/**
	 * @Id @column
	 */
	protected $key1;

	/**
	 * @Id @column
	 */
	protected $key2;
	
	/**
	 * @ManyToMany (targetEntity="Entity2")
	 * @JoinTable (name="Entity1Entity2",
	 *      joinColumns={@JoinColumn(name="key1", referencedColumnName="key1")},
	 *      inverseJoinColumns={@JoinColumn(name="key3", referencedColumnName="key3")}
	 *      )
	 */
	protected $entity2;
}

class Entity2 {
	
	/**
	 * @Id @column
         * @GeneratedValue(strategy="AUTO")
	 */
	protected $key3
}

So in the middle table that i keep the keys from the other 2 i need to save only key1 and key3. And key2 need to be ignored.
But when i try to save instead of saving the proper values it try to save the value for key2 instead of the value of key1 in the middle table.
After some debuging i found that in Doctrine\ORM\Persisters\ManyToManyPersister in the private function _collectJoinTableColumnParameters lies the problem.
Instead of taking the key by the name you are doing array_pop. And you are making a check for composite keys but you presume that bouth of the keys will be
in the middle table, but that is not the case for me.
The quick fix that i did was to remove the current check for isComposite and get the keys like we are in the isComposite case always.

Tanks in advance for the great work.

Have a nice day!



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

This kind of mapping is not supported right now, the CLI tool "orm:validate-schema" should throw a compile time error on it as well.

I am not sure if just changing that line is enough for this to work, or if there are other obstacles as well.

Comment by victor Velkov [ 28/Oct/11 ]

well that is the code so you can see what exactly i have removed

/**
     * Collects the parameters for inserting/deleting on the join table in the order
     * of the join table columns as specified in ManyToManyMapping#joinTableColumns.
     *
     * @param $coll
     * @param $element
     * @return array
     */
    private function _collectJoinTableColumnParameters(PersistentCollection $coll, $element)
    {
        $params = array();
        $mapping = $coll->getMapping();
        $isComposite = count($mapping['joinTableColumns']) > 2;

        $identifier1 = $this->_uow->getEntityIdentifier($coll->getOwner());
        $identifier2 = $this->_uow->getEntityIdentifier($element);

       // if ($isComposite) {
            $class1 = $this->_em->getClassMetadata(get_class($coll->getOwner()));
            $class2 = $coll->getTypeClass();
        //}

        foreach ($mapping['joinTableColumns'] as $joinTableColumn) {
            if (isset($mapping['relationToSourceKeyColumns'][$joinTableColumn])) {
                //if ($isComposite) {
                    if ($class1->containsForeignIdentifier) {
                        $params[] = $identifier1[$class1->getFieldForColumn($mapping['relationToSourceKeyColumns'][$joinTableColumn])];
                    } else {
                        $params[] = $identifier1[$class1->fieldNames[$mapping['relationToSourceKeyColumns'][$joinTableColumn]]];
                    }
//                } else {
//                    $params[] = array_pop($identifier1);
//                }
            } else {
                //if ($isComposite) {
                    if ($class2->containsForeignIdentifier) {
                        $params[] = $identifier2[$class2->getFieldForColumn($mapping['relationToTargetKeyColumns'][$joinTableColumn])];
                    } else {
                        $params[] = $identifier2[$class2->fieldNames[$mapping['relationToTargetKeyColumns'][$joinTableColumn]]];
                    }
//                } else {
//                    $params[] = array_pop($identifier2);
//                }
            }
        }

        return $params;
    }
Comment by Benjamin Eberlei [ 28/Oct/11 ]

i did find that already and also think its a good change to do sometihng along this lines (there is a better solution), however i dont knöow if that is even enough to get your use-case working across the whole ORM. We have zero test-cases for this kind of mapping, so i cannot guarantee you this works at all. This is why the orm:validate-schema gives you an error for this aswell (since some commits ago, this was missing earlier).

Comment by Benjamin Eberlei [ 31/Oct/11 ]

I checked the code again, this mapping is invalid. You have to define all id columns as join columns or otherwise the core will explode somewhere.

Since i cannot know and guarantee where it works and where it doesnt the SchemaValidator throws an exception about this problem. I added tests to master and 2.1.x that this mapping error is indeed given as an error.

Comment by Benjamin Eberlei [ 31/Oct/11 ]

sorry, i coudlnt fix it in 2.1.x, just in 2.2





[DDC-1437] Strange behavior with proxied classes,expected to get entity, but returned identifier. Created: 19/Oct/11  Updated: 19/Oct/11  Resolved: 19/Oct/11

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

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


 Description   

I have the following xml mapping:

 
User:
  <entity name="User" table="user">
    <id name="id" type="integer" column="id">
      <generator strategy="SEQUENCE"/>
    </id>
    <field name="name" type="string" column="name"/>
   </entity>

SuperUser:
  <entity name="SuperUser" table="superuser">

    <id name="user" type="integer" column="user_id" association-key="true"/>

    <one-to-one field="user" target-entity="User">
      <join-columns>
        <join-column name="user_id" referenced-column-name="id"/>
      </join-columns>
    </one-to-one>

  </entity>

From this mapping i have generated the php classes.

In my application, when the SuperUser class is proxied, SuperUser::getUser() method looks like this:

 
public function getUser(){

        if ($this->__isInitialized__ === false) {
            return $this->_identifier["user"];
        }
        $this->__load();
        return parent::getUser();
}

When i call $usperuser->getUser() the expected return value is the User class instance; but the current implementation returns only user id (contained in $this->_identifier["user"]).

In this behavior is also involved private function ProxyFactory::isShortIdentifierGetter($method, $class)

Some solutions proposed by me, can be:

  • remove this behavior
  • during proxy generation, add in this case a method called getUserId, and this method can return user id (but in this case, the behavior continues to be strange because is available only for proxied classes).

(sorry for my english)



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

very recent bug in master, i will fix it.

Comment by Benjamin Eberlei [ 19/Oct/11 ]

fixed in master





[DDC-1430] GROUP BY $alias in Oracle Created: 18/Oct/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

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

Type: Bug Priority: Minor
Reporter: Juan M Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux 64bits + Oracle 11g



 Description   

When creating a query with the QueryBuilder, the groupBy with only the alias doesn't work as expected.

It creates the group by with the ID only, but Oracle need all the fields to work.

The ORA-00979: not a GROUP BY expression error is returned.

From my SlotRepository I do:

$query = $this->createQueryBuilder('s')
    ->select('s, COUNT(a.id) AS agendas_count')
    ->leftJoin('s.agenda_slots', 'l')
    ->leftJoin('l.agenda', 'a')
    ->groupBy('s')
;

The SQL generated is:

SELECT s0_.id AS id0, s0_.hour_start AS hour_start1, s0_.hour_end AS hour_end2, s0_.active AS active3, COUNT(a1_.id) AS sclr4 FROM slot s0_ LEFT JOIN agenda_slot a2_ ON s0_.id = a2_.slot_id LEFT JOIN agenda a1_ ON a2_.agenda_id = a1_.id GROUP BY s0_.id

The SQL expected is:

SELECT s0_.id AS id0, s0_.hour_start AS hour_start1, s0_.hour_end AS hour_end2, s0_.active AS active3, COUNT(a1_.id) AS sclr4 FROM slot s0_ LEFT JOIN agenda_slot a2_ ON s0_.id = a2_.slot_id LEFT JOIN agenda a1_ ON a2_.agenda_id = a1_.id GROUP BY s0_.id, s0_.hour_start, s0_.hour_end, s0_.active

As workaround I include all fields manually.

Thank you,
Juan Manuel



 Comments   
Comment by Juan M [ 15/Nov/11 ]

Fabio: If you have any questions or you can't reproduce the problem, let me know.

Comment by Fabio B. Silva [ 15/Nov/11 ]

Thanks Juan,

I think I understand your problem,
I created one PR with a possible solution in github

Comment by Benjamin Eberlei [ 15/Nov/11 ]

To add to this, although i merged the PR i am not sure if this is enough.

SELECT u FROM User u GROUP BY u

I think there will be a problem if User has foreign keys, because they appear in the SELECT clause, but not in the GROUP BY.

Comment by Fabio B. Silva [ 15/Nov/11 ]

Are you right Benjamin,

I'm testing with the following dql :


SELECT u FROM Doctrine\Tests\Models\CMS\CmsUser u GROUP BY u
SELECT c0_.id AS id0, c0_.status AS status1, c0_.username AS username2, c0_.name AS name3, c0_.email_id AS email_id4 FROM cms_users c0_ GROUP BY c0_.id, c0_.status, c0_.username, c0_.name


SELECT e FROM Doctrine\Tests\Models\CMS\CmsEmployee e GROUP BY e
SELECT c0_.id AS id0, c0_.name AS name1, c0_.spouse_id AS spouse_id2 FROM cms_employees c0_ GROUP BY c0_.id, c0_.name

What you thing about iterate Association Mappings to get foreign keys?

Comment by Benjamin Eberlei [ 15/Nov/11 ]

yes the code has to behave exactly like the select clause generation. Maybe even use that code (if thats possible).

Comment by Benjamin Eberlei [ 18/Nov/11 ]

fixed





ORA-00972: identifier is too long (DDC-1384)

[DDC-1427] Fix for columns Created: 17/Oct/11  Updated: 08/Nov/11  Resolved: 08/Nov/11

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

Type: Sub-task Priority: Major
Reporter: Benjamin Eberlei Assignee: Alexander
Resolution: Fixed Votes: 0
Labels: None


 Description   

Fix for generating sql with columns that are exactly MAX IDENTIFIER SIZE long.



 Comments   
Comment by Alexander [ 08/Nov/11 ]

Fixed over here:

https://github.com/doctrine/doctrine2/pull/167





[DDC-1424] Make order in DQL SELECT clause matter for hydration Created: 16/Oct/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

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

Issue Links:
Reference
is referenced by DDC-1096 "You may have observed that in a mixe... Resolved

 Description   

The order of the DQL Select clause should matter for the result hydration:

SELECT u.id, u, u.name FROM User u => result keys: id, 1, name
SELECT u.id, u.id FROM User u => result keys: id, or numerical hydration 0, 1
SELECT u.id, u AS user FROM User u => result keys: id, user


 Comments   
Comment by Guilherme Blanco [ 14/Nov/11 ]

Implemented!!!

https://github.com/doctrine/doctrine2/commit/81cc6d9da83d217ea62bd467053fd9885d1083cd





[DDC-1422] Do not load entities when an identifier is retrieved from a proxy Created: 15/Oct/11  Updated: 15/Oct/11  Resolved: 15/Oct/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: 2.2

Type: Improvement Priority: Minor
Reporter: Alexander Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Comments   
Comment by Guilherme Blanco [ 15/Oct/11 ]

Fixed as of https://github.com/doctrine/doctrine2/commit/ba38f3e1e9d725224998af9fce42186b5ccb9641





[DDC-1418] Integrate Simplified XML/YML Drivers from Symfony Created: 13/Oct/11  Updated: 13/Oct/11  Resolved: 13/Oct/11

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

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


 Comments   
Comment by Benjamin Eberlei [ 13/Oct/11 ]

Merged this stuff from Symfony, thanks!





[DDC-1417] entity generator does not support nullable relationship Created: 13/Oct/11  Updated: 18/Nov/11  Resolved: 18/Nov/11

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.1.2
Fix Version/s: 2.2

Type: Bug Priority: Minor
Reporter: Marcel Dejean Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

With a nullable relationship, e.g.

  manyToOne:
    bar:
      targetEntity: Bar
      joinColumns:
        bar_id:
          referencedColumnName: id
          nullable: true

the setter generated for the relationship

   public function setBar(\Acme\FooBarBundle\Entity\Bar $bar)
    {
        $this->bar = $bar;
    }

can not take null as an argument.

It should generate

    public function setBar(\Acme\FooBarBundle\Entity\Bar $bar = null)
    {
        $this->bar = $bar;
    }


 Comments   
Comment by Benjamin Eberlei [ 18/Nov/11 ]

This was fixed in a recent PR.





[DDC-1416] bug in simple test with sub query Created: 13/Oct/11  Updated: 04/Dec/11  Resolved: 04/Dec/11

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

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

Linux/Ubuntu 10.10 PHP 5.3.3-1ubuntu9.5



 Description   

For exemple :

$query = $em->createQuery("SELECT * FROM address WHERE :aValue IN (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)");
$query->getQuery()->getSQL();

Doctrine throw that error : Doctrine\ORM\Query\QueryException: [Semantical Error] line 0, col xxx near ':aValue': Error: ':aValue' is not defined.

But in SQL this type of request is posible.



 Comments   
Comment by Guilherme Blanco [ 04/Dec/11 ]

Fixed in trunk: https://github.com/doctrine/doctrine2/commit/0380d5ae580dcbefd63051028fc1ab78599fda6c





[DDC-1411] onCascade property gets wrong value when entities are generated Created: 10/Oct/11  Updated: 15/Oct/11  Resolved: 15/Oct/11

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

Type: Bug Priority: Major
Reporter: Vinícius Borriello Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Unix/Apache/PHP 5.3/MySQL



 Description   

I'm using this cmd to generate entities "/path/to/php path/to/doctrine orm:generate-entities --generate-annotations="1" ~/some/path".

The CASCADE option for ONDELETE columns is being wrongly generated, the right would be: onDelete="CASCADE" but it is being generated as onDelete=true



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

Fixed





[DDC-1404] Named Queries not inherited in JOINED Inheritance Created: 06/Oct/11  Updated: 14/Nov/11  Resolved: 14/Nov/11

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

Type: Bug Priority: Minor
Reporter: Rafael Dohms Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None


 Description   

When using the JOINED Inheritance (@ORM\InheritanceType("JOINED")) any Named Queries defined in the parent entity are not recognized by the repositories of the children.

So if we have ParentEntity as the parent and ChildEntity a class that extends ParentEntity in table inheritance also. Accessing the ChildEntityRepository and asking for a named query defined via annotation in ParentEntity results in "query does not exist"



 Comments   
Comment by Benjamin Eberlei [ 14/Nov/11 ]

Merged





[DDC-1396] [APC Cache] "clear-cache" commands do not work with cli Created: 27/Sep/11  Updated: 03/Oct/11  Resolved: 03/Oct/11

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

Type: Bug Priority: Critical
Reporter: Jérôme Forêt Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

in php.ini
apc.enable_cli = 1



 Description   

Commands for clear-cache:result, clear-cache:query, clear-cache:metadata do not work with cli and APC Cache

Revert some correction not tested by guilhermeblanco by adding

if ($cacheDriver instanceof \Doctrine\Common\Cache\ApcCache)
{
    throw new \LogicException("Cannot clear APC Cache from Console, its shared in the Webserver memory and not accessible from the CLI.");
}


 Comments   
Comment by Guilherme Blanco [ 03/Oct/11 ]

Fixed in https://github.com/doctrine/doctrine2/commit/8efae0b232210b27200f2709e7fcb24c7f02c5de

Thanks for the report. =)





[DDC-1395] [Doctrine cache clear-result] - wrong function is used Created: 27/Sep/11  Updated: 03/Oct/11  Resolved: 03/Oct/11

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

Type: Bug Priority: Major
Reporter: Jérôme Forêt Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

lib\Doctrine\ORM\Tools\Console\Command\ClearCache\ResultCommand.php

Fixing

 
$cacheDriver = $em->getConfiguration()->getQueryCacheImpl();
by
$cacheDriver = $em->getConfiguration()->getResultCacheImpl();

Fixing

 
output->write('Clearing ALL Query cache entries' . PHP_EOL);
by
output->write('Clearing ALL Result cache entries' . PHP_EOL);


 Comments   
Comment by Guilherme Blanco [ 03/Oct/11 ]

Fixed in https://github.com/doctrine/doctrine2/commit/cd2805137056688fc0848f7fa76b479d681a3cb6





[DDC-1385] INDEX BY doesn't work for selects with scalars only Created: 21/Sep/11  Updated: 01/Apr/12  Resolved: 08/Nov/11

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

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


 Description   

By scalars-only-selects I mean this:

SELECT c.id, c.name FROM GLocalityBundle:Country c  INDEX by c.id 

The result won't be indexed by c.id, as opposites to this:

SELECT c FROM GLocalityBundle:Country c  INDEX by c.id 

Assuming that GLocalityBundle:Country has several hunders of fields, and you need only two of them, this is very disappointing

After diving in the code, due to rigorous separation of entities on objects and scalars, it looks practically impossible even to implement this feature
What is this? Bad design?



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

I agree it seems very complex to implement for the Object and ArrayHydrator, however it should be very easy for the getScalarResult() hydrator.

Even more I think there is a general bug with INDEX BY and scalars in Object and ArrayHydrator that has to be evaluated.

Comment by Benjamin Eberlei [ 31/Oct/11 ]

This PR will fix this issue https://github.com/doctrine/doctrine2/pull/151, it is scheduled for 2.2

Comment by Benjamin Eberlei [ 08/Nov/11 ]

This is fixed in master

Comment by Oleg Namaka [ 01/Apr/12 ]

This behavior has not changed in the latest 2.2.1. getArrayResult returns an indexed result. getScalarResult returns zero based result. Do I need to create a separate ticket for that issue?





[DDC-1384] ORA-00972: identifier is too long Created: 19/Sep/11  Updated: 30/Oct/11  Resolved: 30/Oct/11

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

Type: Bug Priority: Major
Reporter: Matheus Luis Ramos de Souza Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-1427 Fix for columns Sub-task Resolved Alexander  
DDC-1428 Fix for tables Sub-task Resolved Alexander  

 Description   

Hi,

When the query is executed the follow problem occur:
ORA-00972:identifier is too long
The problem occur because a column name has 30 characters and the
Doctrine creates an alias with <column_name>+<position_in_select>
becoming 31 characters, in Oracle the max allowed characters in the name
is 30.
Is there any configuration that disable this mechanism?
How can I solve this issue?
Thanks!
Regards,

Matheus Souza.



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

This is tricky. No way for you to reduce the column length to < 30 chars? The problem with a fix for this would be that we would need to execute a bunch of functions for every database vendor and every column alias used in every SQL statement: quite some overhead

Comment by Matheus Luis Ramos de Souza [ 26/Sep/11 ]

I get it.
I don't know the implementation, but is there a possibilty to create a property that disable the "suffix field position" in alias, staying just <column_name>?

Tks!

Comment by Benjamin Eberlei [ 15/Oct/11 ]

The following workaround will get you around this problem until i find a better solution.

1. Create a MyOraclePlatform extends \Doctrine\DBAL\Platforms\OraclePlatform
2. Override the "getSQLResultCasing($string)" to do:

$val = parent::getSQLResultCasing($string);
return substr($val, -30);

This substrings every result alias to 30 chars.

Comment by Matheus Luis Ramos de Souza [ 17/Oct/11 ]

But how does the Doctrine will know about my implementation?
I will have to change the Driver too?

Thanks!

Comment by Benjamin Eberlei [ 17/Oct/11 ]

no, you can pass the "platform" into the DriverManager::create method as "platform" parameter for the $params AFAIK, relevant code is Doctrine\DBAL\Connection::__construct if you want to check it out.

Comment by Matheus Luis Ramos de Souza [ 17/Oct/11 ]

In some cases it works, but it doesn't work when the SqlWalker is invoked, I think that the problem is in walkSelectClause($selectClause) method in the else clause for this verification:

if ($class->isInheritanceTypeSingleTable() || $class->isInheritanceTypeJoined()) {
if ($class->isInheritanceTypeSingleTable() || $class->isInheritanceTypeJoined()) {
...
} else {
                // Add foreign key columns to SQL, if necessary
                if ($addMetaColumns) {
                    $sqlTableAlias = $this->getSqlTableAlias($class->table['name'], $dqlAlias);
                    foreach ($class->associationMappings as $assoc) {
                        if ($assoc['isOwningSide'] && $assoc['type'] & ClassMetadata::TO_ONE) {
                            foreach ($assoc['targetToSourceKeyColumns'] as $srcColumn) {
                                $columnAlias = $this->getSqlColumnAlias($srcColumn);
                                $sql .= ', ' . $sqlTableAlias . '.' . $srcColumn . ' AS ' . $columnAlias;
                                $columnAlias = $this->_platform->getSQLResultCasing($columnAlias);
                                $this->_rsm->addMetaResult($dqlAlias, $this->_platform->getSQLResultCasing($columnAlias), $srcColumn);
                            }
                        }
                    }
                }
            }
        }

the problem is in the follow lines, because the getSQLResultCasing has no effect in $sql variable that is returned:

$columnAlias = $this->getSqlColumnAlias($srcColumn);
$sql .= ', ' . $sqlTableAlias . '.' . $srcColumn . ' AS ' . $columnAlias;
$columnAlias = $this->_platform->getSQLResultCasing($columnAlias);

The correct would be this way, wouldn't be?

$columnAlias = $this->getSqlColumnAlias($srcColumn);
$columnAlias = $this->_platform->getSQLResultCasing($columnAlias);
$sql .= ', ' . $sqlTableAlias . '.' . $srcColumn . ' AS ' . $columnAlias;
  • In the version of Doctrine that I'm using, there is no DriverManager::create method, I'm using
    DriverManager::getConnection(array $params,Configuration $config = null,EventManager $eventManager = null) instead.

Tks!!

Comment by Benjamin Eberlei [ 17/Oct/11 ]

Narf, sorry that this doesn't work.

This is rather unreliable if this fails here, can we trust it in other places? I think i have to work on this by hard, its just very problematic to test this, it may be easy to miss a location.

Comment by Benjamin Eberlei [ 17/Oct/11 ]

we found a simple way to fix this, expect a patch for this soon!

Comment by Alexander [ 26/Oct/11 ]

The issue should be fixed with the code over here:
https://github.com/doctrine/doctrine2/pull/167

I haven't been able to test it on a real Oracle DB yet. Maybe you guys can give it a go?

Comment by Benjamin Eberlei [ 30/Oct/11 ]

Fixed, however will not be merged into 2.1.x because the patch is really large





[DDC-1383] Inheritance superclass object is created after merging entity referencing to discriminated entity Created: 19/Sep/11  Updated: 15/Oct/11  Resolved: 15/Oct/11

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

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

Ubuntu 11.04, MySQL 5.1.54-1ubuntu4, PHP 5.3.5-1ubuntu7.2


Attachments: File DDC1383Test.php    

 Description   

Problem is that after merging the object with a reference to some other entity with inheritance (is one of the superclass's discriminator map), the referenced object has wrong instance (it is Proxy object). It is instance of the superclass not the extended class.

In my test case I have joined inheritance model with only two entities to make things simple as possible.

First is the base entity (I have even marked it as abstract):

/**
 * @Entity
 * @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="discr", type="integer")
 * @DiscriminatorMap({1 = "Entity"})
 */
abstract class AbstractEntity

and one entity which extends from the first one:

/**
 * @Entity
 */
class Entity extends AbstractEntity {
	/**
	 * @ManyToOne(targetEntity="AbstractEntity")
	 * @var AbstractEntity
	 */
	protected $reference;

In this scheme I've got 2 objects, first referencing to the second. They both are inserted in the database with no problems.

$child = new Entity();
$parent = new Entity();
$child->setReference($parent);

After the flush I try merging the child entity into the entity manager, the parent entity reference is not instance of Entity\Entity anymore.

You can see full test case in the archive attached.



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

Attached standardized test case.

Comment by Benjamin Eberlei [ 15/Oct/11 ]

Fixed.





[DDC-1368] incorrect mapping not detected by orm:validate-schema Created: 08/Sep/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

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

Linux, Debian Lenny, PHP 5.3.8



 Description   

The following incorrect mapping was not detected by orm:validate-schema, instead running it resulted in:

$ doctrine orm:validate-schema
[Mapping] OK - The mapping files are correct.

<doctrine-mapping>
...
<one-to-many field="duchies" target-entity="Duchy" mapped-by="realm">
<order-by>
<order-by-field name="name" direction="ASC" />
</order-by>
</one-to-many>
...
</doctrine-mapping>

and the inverse side:

<doctrine-mapping>
<one-to-one field="realm" target-entity="Realm" inversed-by="duchies">
<join-column name="Realm" referenced-column-name="ID" />
</one-to-one>
</doctrine-mapping>

obviously, the inverse side should be many-to-one and not one-to-one. Interesting bugs in the code resulted. Obviously a coder mistake, but orm:validate-schema should have detected that the association has incompatible mappings.



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

Fixed





[DDC-1365] Use getQuotedTableName() consistently in all SQL Created: 06/Sep/11  Updated: 25/Sep/11  Resolved: 07/Sep/11

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

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


 Description   

Its missing in some of the persisters/sql walker code.



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

Committed in https://github.com/doctrine/doctrine2/commit/e3d133af045815167bdbb0e47a496cc49c86fc23

Please merge in 2.1.





[DDC-1360] Reserved words escaping fails when using multiple reserved words Created: 03/Sep/11  Updated: 03/Jan/12  Resolved: 31/Dec/11

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

Type: Bug Priority: Blocker
Reporter: Elnur Abdurrakhimov Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux, PostgreSQL



 Description   

Everything works fine when I use the @Table annotation like this: @Table(name="`user`"). But when the user table is in the user schema and I try to use the annotion in this way: @Table(name="`user`.`user`") — everything falls apart.

A quick look into the code showed that it checks if the table name starts with `, and if it does, it sets the quoted parameter to true and removes the ` characters on the both sides. So, if I quote the both words like @Table(name="`user`.`user`"), the table name becomes "user`.`user" and it, of course, fails. If I quote it just like @Table(name="`user.user`"), the table name becomes "user.user", which fails too.

If Doctrine allows to escape the reserved words, it should take into account this kind of usage as well.



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

By now, it's currently impossible to do cross database joins in an easy way.
We have planned it through the schema support in @Table.

I'll be working on this support for 2.2, but until there, my only recommendation is to not use a keyword as a table name.

Cheers,

Comment by Elnur Abdurrakhimov [ 05/Sep/11 ]

It's not cross database; it's just schema.table in PostgreSQL. It works when not using reserved words, but fails with them.

Comment by Benjamin Eberlei [ 28/Oct/11 ]

How much of this ticket does your commit from some weeks ago cover guilherme?

Comment by Benjamin Eberlei [ 16/Nov/11 ]

Fixed for 2.2

Comment by Elnur Abdurrakhimov [ 21/Dec/11 ]

It still doesn't work. Tried on master.

Comment by Benjamin Eberlei [ 21/Dec/11 ]

what kind of error do you get?

Comment by Benjamin Eberlei [ 28/Dec/11 ]

could reproduce the problem with table names and sequence names.

Comment by Benjamin Eberlei [ 28/Dec/11 ]

Fixed.

Comment by Elnur Abdurrakhimov [ 29/Dec/11 ]

I've just got fresh clones of doctrine-doctrine2, doctrine-dbal and doctrine-common — all on their master branches.

My entity has this annotation:

@ORM\Table(name="`user`.`user`")

I'm getting the following exception:

SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "user.user" 
does not exist LINE 1: ... is_private9,
u0_.created_at AS created_at10 FROM "user.user... 

So, it's translating `user`.`user` to "user.user", while it should be "user"."user".

Comment by Elnur Abdurrakhimov [ 29/Dec/11 ]

What changed is that earlier `user`.`user` was translated to "user`.`user", while now it's translated to "user.user", but should be to "user"."user".

I saw the commit related to this ticket (https://github.com/doctrine/doctrine2/commit/959a68694e5827a74ad5b8c8216996ffff6196ba) and I want to note that I'm getting this error not when creating a table, but when querying it. I don't use Doctrine for creating tables anyway — I do it via plain SQL.

Comment by Benjamin Eberlei [ 31/Dec/11 ]

I keep trying until i fixed this, now with a commit into DBAL: https://github.com/doctrine/dbal/commit/4cb8a99b65fb08e01fbc02cf9c0e07255e3f8463

Will be included in Beta 2

Comment by Elnur Abdurrakhimov [ 31/Dec/11 ]

Now `user`.user, `user`.`user` and `user.user` get escaped properly, ending up as "user"."user". Interestingly enough, even only the beginning tick like in `user.user ends up as "user"."user".

user.`user`, though, results in user.`user` — that is, nothing gets escaped. I don't think this is a big deal, because if I can escape both schema and table name parts, then I won't run into problems. I'm pointing this out in case it was intended to affect the escaping too.

Good job, thanks.





[DDC-1358] Native Query hydration ignores empty entity doublons Created: 02/Sep/11  Updated: 16/Oct/11  Resolved: 16/Oct/11

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

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

Debian 6, Symfony 2, Doctrine 2



 Description   

My case is the follwing :

In a range of dates, I want to know if an entity has been defined for each day. So the raw SQL result would looks like :

DATE              ID NAME
--------- ---------- -------------
19-SEP-11          4 [Entity Name]
20-SEP-11          1 [Entity Name]
21-SEP-11          2 [Entity Name]
22-SEP-11          3 [Entity Name]
23-SEP-11       NULL NULL
24-SEP-11       NULL NULL
25-SEP-11       NULL NULL
26-SEP-11       NULL NULL
27-SEP-11          7 [Entity Name]
28-SEP-11          6 [Entity Name]
29-SEP-11          5 [Entity Name]

11 rows selected.

The range calculation forced me to use Native Query, but I stumbled upon a strange behavior : the Result array showed less records than the raw SQL would provide. After some dirty debugging, I found out that during hydration, an array of previously hydrated object keys was stored ObjectHydrator->_identifierMap. The key of null elements (the gap in the SQL result above) is stored too. The problem is that when there is multiple empty elements, hydration only keeps one, and forget the others, thus reducing the overall size of the output result.

I've already come up with a quick n'dirty fix wich suits my current needs, but it would be better if this issue was addressed at a more global level.

Here's the one-liner fix :

Doctrine/ORM/Internal/Hydration/ObjectHydrator.php line 397 was :
                if ( ! isset($this->_identifierMap[$dqlAlias][$id[$dqlAlias]]) ) {
Doctrine/ORM/Internal/Hydration/ObjectHydrator.php line 397 now :
                if ( ! isset($this->_identifierMap[$dqlAlias][$id[$dqlAlias]]) || str_replace( '|', '', $id[$dqlAlias]) == '') {


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

Doesnt he still hydrate an empty object for this row then? Why are you even using the object hydrator? I rather tend to go and throw an exception if for a query using the ObjectHydrator $id[$dqlAlias] is empty, because frankly this is just not supported.

Comment by Benjamin Lorteau [ 04/Sep/11 ]

He does hydrate one empty object for the first line with empty ID, but he does not hydrate further empty object.

Thus, instead of having an array with the following objects :

 
Entity(id=4)
Entity(id=1)
Entity(id=2)
Entity(id=3)
Entity(id=)
Entity(id=)
Entity(id=)
Entity(id=)
Entity(id=7)
Entity(id=6)
Entity(id=5)

I got :

 
Entity(id=4)
Entity(id=1)
Entity(id=2)
Entity(id=3)
Entity(id=)
Entity(id=7)
Entity(id=6)
Entity(id=5)
Comment by Benjamin Eberlei [ 04/Sep/11 ]

Yes, but can you show me your DQL statement?

Comment by Benjamin Lorteau [ 05/Sep/11 ]

I'm using Native Query, so I guess it's not DQL, but here's the query (Oracle SQL)

SELECT *
FROM (
    SELECT to_date(:date_start,\'dd-mm-yyyy\') + rownum -1 as period_date
    FROM all_objects
    WHERE rownum <= to_date(:date_end,\'dd-mm-yyyy\') - to_date(:date_start,\'dd-mm-yyyy\')+1
)
LEFT JOIN entity ON period_date = entity_date',
Comment by Benjamin Eberlei [ 15/Oct/11 ]

For the Array- and ObjectHydrator the ID is a required result.

I am not sure how to proceed with this, i think the right behavior is to return null as the object when no id is found. What do you think?

Is the Date a scalar value of the result?

Comment by Benjamin Lorteau [ 15/Oct/11 ]

The expected results would be, in order of preference :

  • Entity without id set (like in my example above)
  • null value

And yes, the Date was an additional scalar value for which I needed the Native Query

Comment by Benjamin Eberlei [ 16/Oct/11 ]

Your example lacks details but, for case one. Did the queries return values for the non-id columns of this entity?

Comment by Benjamin Lorteau [ 16/Oct/11 ]

Sorry for the concision, I didn't wanted to flood my comment with unrelated data.

The fact is the queries returned values for the non-id columns when the ID was set, and null values when not. I will update my comment.

Comment by Benjamin Eberlei [ 16/Oct/11 ]

I will go with adding NULL values there. This is more consistent, since null represents a non-existent entity.

Fixed and merged back into 2.1.x





[DDC-1351] Github-PR-111 by Gregwar: [Tools] Added entityRepository support in yaml exporter 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.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 Gregwar:

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

Message:

Adds support for custom entity repository class in the yaml exporter






[DDC-1344] Command Tool does not display the directory name when "destination directory" error occurs Created: 24/Aug/11  Updated: 27/Aug/11  Resolved: 27/Aug/11

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

Type: Bug Priority: Minor
Reporter: Başar Aykut Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

When any generate command fails because of the destination directory error, directory name shown on the displayed message is always empty.

This is because realpath() function returns false when directory does not exist.

Taken  from the file GenerateRepositoriesCommand.php

        // Process destination directory
        $destPath = realpath($input->getArgument('dest-path'));

        if ( ! file_exists($destPath)) {
            throw new \InvalidArgumentException(
                sprintf("Entities destination directory '<info>%s</info>' does not exist.", $destPath)
            );
        }


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

Fixed





[DDC-1343] Github-PR-105 by domnikl: DDC-1278 - EntityManager::clear($entity) support Created: 21/Aug/11  Updated: 17/Oct/11  Resolved: 17/Oct/11

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

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


 Description   

domnikl created a pull request on Github:

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

added cascade detach operation only for entites with the same name when $entityName on clear() was specified. I am still unsure where to put my tests for that.



 Comments   
Comment by Guilherme Blanco [ 17/Oct/11 ]

Fixed in this commit https://github.com/doctrine/doctrine2/commit/22a04fd6de3ffa44cc3cd817d65cf112b1df7b53





[DDC-1339] New DQL function: IDENTITY(SingleValuedAssociationPathExpression) Created: 19/Aug/11  Updated: 08/Sep/11  Resolved: 08/Sep/11

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

Type: New Feature Priority: Minor
Reporter: Guilherme Blanco Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Suppose the association: User N:1 Group and user wants to be able to retrieve "users.group_id" without joining the Group entity.
This lead us to create a new DQL function:

SELECT IDENTITY(u.Group) AS group_id FROM User u WHERE u.id = ?0


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

Implemented https://github.com/doctrine/doctrine2/commit/a7f3af8328b031a6f006eef1062554bf9f57e1df





[DDC-1338] @Entity(repositoryClass) could support short namespace support Created: 19/Aug/11  Updated: 19/Aug/11  Resolved: 19/Aug/11

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

Type: Improvement Priority: Minor
Reporter: Guilherme Blanco Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

Like association mapping, we could take advantage of short namespacing of entity repository class.

Example:

namespace Foo\Bar\Red;

/**
 * Used to be "Foo\Bar\Red\WooRepository"
 * @Entity(repositoryClass="WooRepository")
 */
class Woo { ... } 


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

Fixed by https://github.com/doctrine/doctrine2/commit/736443f6c23c772bf10cf2839c3812f43b251929





[DDC-1331] Add IN(...) support to INSTANCE OF Created: 14/Aug/11  Updated: 15/Aug/11  Resolved: 15/Aug/11

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

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


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

Implemented in latest 2.2-DEV by commit: https://github.com/doctrine/doctrine2/commit/f148912a28601d9c6234d59661f0e4ad1ae0c138

Cheers,





[DDC-1330] Doctrine CLI and additional things like Migrations Created: 14/Aug/11  Updated: 17/Dec/11  Resolved: 17/Dec/11

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

Type: Bug Priority: Minor
Reporter: Timo A. Hummel Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

I'm currently trying out Migrations. However, it seems to me that it is not possible to easily add migrations to a system-wide installed Doctrine2 ORM.

This bug is probably 50% documentation issue and 50% code issue.

What I'm basically trying to do is to add the migrations project.

Problem One: The $cli object

The documentation for both migrations and ORM state about the $cli object. However, it is never explained how the $cli object is instanciated.

It isn't obvious that $cli is either defined by the doctrine command (=doctrine.php which comes with the sandbox and is eventually installed system-wide) or actually needs to be defined by the developer himself. It might be obvious when you read the complete manual first (like a book, which actually nobody does - at least not anybody I know), but this isn't helpful because the manuals are all reference manuals.

So the manuals need to be changed so that it actually explains where $cli comes from.

http://www.doctrine-project.org/docs/orm/2.1/en/reference/tools.html
http://www.doctrine-project.org/projects/migrations/2.0/docs/reference/introduction/en#introduction

Problem Two: Defining a custom doctrine.php file

As there's no code - at least not which I could have found easily - to add CLI commands to system's doctrine.php without modifying it, developers are forced to duplicate the code of doctrine.php and add their own CLI commands.

The problem could be easily avoided by allowing the users to define something like $additionalCommands in their cli-config.php which could then appended via $cli->addCommands() in the master doctrine.php file.



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

Added a part on setiing up the CLi into the ORM docs.





[DDC-1325] Adding @Target to annotations Created: 10/Aug/11  Updated: 14/Aug/11  Resolved: 14/Aug/11

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

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


 Description   

Now that the annotation parser has support for the @Target annotation, we should also add it to the annotations of the ORM.

I have looked through the mapping file, but I'm not familiar with all the annotations, so someone else is probably better suited to add them.

Usage is as follows:

@Target("CLASS") for a single target
@Target(

{"CLASS", "METHOD", "PROPERTY", "ANNOTATION"}

) for multiple targets (annotation if it can be used as a nested annotation)



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

Resolved





[DDC-1295] Sandbox Sample Code which shall go into cli-config.php and index.php for EntityManager working with yaml is wrong Created: 25/Jul/11  Updated: 09/Dec/11  Resolved: 09/Dec/11

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

Type: Documentation Priority: Major
Reporter: Sven Zahrend Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

LINUX doctrine2.git



 Description   

In http://www.doctrine-project.org/docs/orm/2.1/en/tutorials/getting-started-xml-edition.html
in Section: Obtaining the EntityManager
the Code:

//$driverImpl = new Doctrine\ORM\Mapping\Driver\XmlDriver(_DIR_."/config/mappings/xml");
$driverImpl = new Doctrine\ORM\Mapping\Driver\XmlDriver(_DIR_."/config/mappings/yml");
//$driverImpl = $config->newDefaultAnnotationDriver(_DIR_."/entities");

produces:

PHP Fatal error: Class 'Sandbox\Doctrine\ORM\Mapping\Driver\XmlDriver' not found in ..

Should be corrected to:
$driverImpl = new \Doctrine\ORM\Mapping\Driver\XmlDriver(_DIR_."/config/mappings/yml");

produces:

PHP Fatal error: Uncaught exception 'Doctrine\ORM\Mapping\MappingException' with message 'No mapping file found named 'Entities.User.dcm.xml' ..

Should be corrected to:
$driverImpl = new \Doctrine\ORM\Mapping\Driver\YamlDriver(_DIR_."/config/mappings/yml");

and finally, following the xml yaml Entities folder structure in the sandbox, should be corrected to:

$driverImpl = new \Doctrine\ORM\Mapping\Driver\YamlDriver(_DIR_."/yaml");

With this configuration I was able to create Entities from yaml through these commands:

  1. doctrine orm:generate-entities ./
  2. doctrine orm:schema-tool:create


 Comments   
Comment by Guilherme Blanco [ 09/Dec/11 ]

This issue was already solved in 2.2....
The tutorial code changed due to the new support introduced in 2.2, so I'm marking as fixed and assigning to this middle point version.

Cheers,





[DDC-1293] Update DQL function signature in documentation Created: 25/Jul/11  Updated: 09/Dec/11  Resolved: 09/Dec/11

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

Type: Bug Priority: Minor
Reporter: Menno Holtkamp Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

The documentation concerning the new DQL Date functions is outdated, as the 'unit' of the interval is not described.

 
DATE_ADD(date, days) - Add the number of days to a given date.
DATE_SUB(date, days) - Substract the number of days from a given date.

Should be

 
DATE_ADD(date, interval, unitOfInterval)

for example:

 
DATE_ADD(CURRENT_DATE(), 1, 'DAY');
DATE_SUB(CURRENT_DATE(), 4, 'MONTH');

UPDATE: it appears parameters are not injected properly when using the DATE functions:

 
$qb->where("x._lastMutationDateTime < DATE_ADD(CURRENT_DATE(),?1,'day')");
$qb->setParameter(1, 5);

Results in:

//DQL
SELECT x FROM Entity p WHERE x._lastMutationTimestamp < DATE_ADD(CURRENT_DATE(),?1,'day')
//SQL:
SELECT x0_.id AS id0, x0_.last_mutation_timestamp AS last_mutation_timestamp1
WHERE x0_.last_mutation_timestamp < DATE_ADD(CURRENT_DATE, INTERVAL 0 DAY)


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

Marked as bug

Comment by Guilherme Blanco [ 09/Dec/11 ]

This issue was already fixed, maybe docs should be regenerated.
Marking as fixed for now.





[DDC-1290] Version fields do not accept smallint and bigint Created: 24/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.2
Security Level: All

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


 Description   

In ClassMetadataInfo there is a method called setVersionMapping.

It sets default values for the version fields, but only for integer and datetime.
As I expected that smallint and bigint would be handled the same way, I would consider the fact they are missing as a bug.

So instead of

if ($mapping['type'] == 'integer') {

it should probably be

if (in_array($mapping['type'], array('integer', 'smallint', 'bigint'))) {



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

I call it improvement and its fixed in master, will be in 2.2





[DDC-1288] Column Name Created: 22/Jul/11  Updated: 16/Aug/11  Resolved: 16/Aug/11

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

Type: New Feature Priority: Major
Reporter: salomao santos Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None


 Description   

Hello, I am starting development with symfony Doctrine ORM, and I'm one big question: the company where I work, there is a table in a database whose field (column) must be called "call-limit", (I repeat, have to have this name), but I can not for the Doctrine does not allow ... Is there any way to treat this? I've tried using the alias, but to no avail ... If someone can help me ... Hug.



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

Just map your @Column providing the db field name.

/**
 * @Column(name="my-desired-name")
 */
protected $otherName;

The only question you should check then is if your RDBMS supports the dashes as a valid column name.

Cheers,





[DDC-1286] Change typo in ORMException Created: 22/Jul/11  Updated: 14/Aug/11  Resolved: 14/Aug/11

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

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


 Description   

Doctrine\ORM\ORMException, like 42:
"however this entity has no ientity itself. You have to call EntityManager#persist() on the related entity " .

should be:
"however this entity has no identity itself. You have to call EntityManager#persist() on the related entity " .



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

This issue is already solved in latest 2.2-DEV.

Thanks for the report.





[DDC-1285] Select by multiple ids Created: 22/Jul/11  Updated: 11/Sep/13  Resolved: 11/Sep/13

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

Type: Improvement Priority: Major
Reporter: Serge Smertin Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: None


 Description   

How do you look at adding findByIds(array $ids) to EntityManager and UnitOfWork? This would allow fetching multiple entities from a database at one request and would be very useful for caching - there would be even some kind of IdentityMap kept in memcached or any other caching engine, that supports multiple id retrieval: i've been using sujhjhjch an architecture in multiple projects and it turned out to be very effective. There were two basic methods - findIdsByFilter(array $filter) and findEntitiesByIds(array $ids). The latter one had a caching proxy, replicating entities to a cache storage. If this idea proceeds - I'd be glad to cover it with more details.

This topic on StackOverflow could also help:
http://stackoverflow.com/questions/276709/design-pattern-for-memcached-data-caching



 Comments   
Comment by Guilherme Blanco [ 20/Dec/11 ]

Updating fix version

Comment by Benjamin Eberlei [ 11/Sep/13 ]

This is implemented on the Repository since 2.1 or 2.2 with findBy(array('id' => array(1, 2, 3, 4, 5));





[DDC-1284] Inheritance fails in JOIN query Created: 21/Jul/11  Updated: 14/Aug/11  Resolved: 14/Aug/11

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

Type: Bug Priority: Major
Reporter: Carlos Ayala Assignee: Guilherme Blanco
Resolution: Can't Fix Votes: 0
Labels: None
Environment:

Ubuntu 10.10



 Description   

Hi!
Sorry for my english, I'm working on that.
I've this code:

/**
 * @Entity
 * @Table(name="entity") 
 * @InheritanceType("JOINED")
 * @DiscriminatorColumn(name="entityTypeId", type="smallint")
 * @DiscriminatorMap({0 = "Bank",  1 = "Dealer", 2 = "Debtor", 3 = "Repo", 4 = "Appraiser", 5 = "Transport"})
 */
class Entities
{
     /**
     * @Id @GeneratedValue
     * @Column(type="integer")
     * @var integer
     */
    protected $id;

   /**
     * @Column(type="string", length=40)
     * @var text
     */
    protected $name;

    ............................................................
    ............................................................
}

------------------------------------------------------------------------------------------------------------------------------------
/** 
 * @Entity(repositoryClass="Model\Entity\Repository\DebtorRepository")
 * @Table(name="debtor") 
 */ 
class Debtor extends Entities{
    
}

------------------------------------------------------------------------------------------------------------------------------------
 
/**
 * @Entity(repositoryClass="Model\Entity\Repository\PlacementRepository")
 * @Table(name="placement")
 */
class Placement
{
      
    /**
     * @Id
     * @Column(type="smallint")
     * @var integer
     */
    protected $id;


       /**
     * @ManyToOne(targetEntity="Debtor", inversedBy="placements")
     * @JoinColumn(name="debtorId", referencedColumnName="id")
     */
    protected $debtor;
 
........................................
.......................................
}

The DQL query:

"SELECT t1 FROM Model\Entity\Placement t1 INNER JOIN t1.debtor d WITH d.name = 'test' "

fails and show the message

"SQLSTATE[42S22]: Column not found: 1054 Unknown column 'e2_.name' in 'on clause'"

I hope somebody know how fix this, I can't fixing this.



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

Can you call $query->getSQL() and show me the generated SQL statement? or grab it from a log file

Comment by Guilherme Blanco [ 14/Aug/11 ]

Hi,

This issue is impossible to be fixed by Doctrine side.
The inheritance requires Doctrine to make additional JOINs to also include the inherited Entities, but it's not possible at that stage to determine which JOIN-ON clause your WITH would be part of, it generates a broken SQL.

That's your situation. Since in your individual situation you're doing INNER JOINs, you are pretty much able to fix this by doing a WHERE clause. From Doctrine perspective, this issue is not fixable.

Cheers,





[DDC-1278] EntityManager::clear($entity) support Created: 14/Jul/11  Updated: 16/Oct/11  Resolved: 16/Oct/11

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

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

Sub-Tasks:
Key
Summary
Type
Status
Assignee
DDC-2850 Allow cascaded clearing of Entities a... Sub-task Open Benjamin Eberlei  

 Description   

It was originally planned that EntityManager::clear() would also support an optional argument - $entity -, which would remove only the reference to an existent entity (maybe also consider a new cascade to allow graph clearing) from UoW.
Currently, it's win or wall. You can't clear a specific portion of Entities.



 Comments   
Comment by Dominik Liebler [ 13/Aug/11 ]

I implemented this (https://github.com/doctrine/doctrine2/pull/104) but forgot to consider also cascade detach. What do you think about adding an additional parameter $entityName to both cascadeDetach() and doDetach()?

Comment by Benjamin Eberlei [ 16/Oct/11 ]

Merged into 2.2-master

Comment by Alexander [ 16/Oct/11 ]

By merging the new PR: https://github.com/doctrine/doctrine2/pull/105.





[DDC-1277] BasicEntityPersister::expandParameters() will check associations Created: 14/Jul/11  Updated: 14/Aug/11  Resolved: 14/Aug/11

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

Type: Improvement Priority: Minor
Reporter: Jasper N. Brouwer Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None

Attachments: File BasicEntityPersister.php-fixed.diff     File BasicEntityPersister.php.diff    

 Description   

When executing a EntityRepository::findBy() or EntityRepository::findOnyBy() with criteria that contain a field/value pair where the field is an association-name and the value is an array, some (for me) unexpected behavior occurs.

First an example to make my statement a bit more clear:
I have an entity User and Group where Group has many Users (User many-to-one Group).

When I call UserRepository->findBy( array( 'group' => 1 )), all goes well.
When I call UserRepository->findBy( array( 'group' => array( 1, 2, 3 ))), I get an notice and no results (Notice: Array to string conversion in /opt/local/www/doctrine2/lib/vendor/doctrine-dbal/lib/Doctrine/DBAL/Connection.php on line 613)

I've tracked the "problem" down to the BasicEntityPersister:

BasicEntityPersister::_getSelectEntitiesSQL(), which uses BasicEntityPersister::_getSelectConditionSQL(), correctly creates a query containing something like WHERE t0.group_id IN ( ? ).
But BasicEntityPersister::expandParameters() doesn't implode the array to some string that can be bound to the query. This is because it doesn't take into account that the field could be an association.

I don't know if this is intended behavior, but I would think not. I've therefor altered the BasicEntityPersister::expandParameters() a bit:

private function expandParameters($criteria)
    {
        $params = $types = array();

        foreach ($criteria AS $field => $value) {
            if ($value === null) {
                continue; // skip null values.
            }

            $type = null;
            if (isset($this->_class->fieldMappings[$field])) {
                $type = Type::getType($this->_class->fieldMappings[$field]['type'])->getBindingType();
            // BEGIN: Jasper N. Brouwer (14-07-2011)
            } else if (isset($this->_class->associationMappings[$field])) {
                if ($this->_class->associationMappings[$field]['isOwningSide']) {
                    $targetClass = $this->_em->getClassMetadata($this->_class->associationMappings[$field]['targetEntity']);
                    $targetField = $this->_class->associationMappings[$field]['joinColumns'][0]['referencedColumnName'];
                    if (isset($targetClass->fieldMappings[$targetField])) {
                        $type = Type::getType($targetClass->fieldMappings[$targetField]['type'])->getBindingType();
                    }
                }
            // END: Jasper N. Brouwer (14-07-2011)
            }
            if (is_array($value)) {
                $type += Connection::ARRAY_PARAM_OFFSET;
            }
            
            $params[] = $value;
            $types[] = $type;
        }
        return array($params, $types);                                                                                  
    }

I hope this bit of code also clarifies what I'm trying to explain a bit more...



 Comments   
Comment by Jasper N. Brouwer [ 11/Aug/11 ]

I found an error in my fix

$this->_class->associationMappings[$field]['joinColumns'][0]['referencedColumnName']; refers to a column-name, not a field-name. I made a new patch:

private function expandParameters($criteria)                                                                            
{
    $params = $types = array();

    foreach ($criteria AS $field => $value) {
        if ($value === null) {
            continue; // skip null values.
        }

        $type = null;
        if (isset($this->_class->fieldMappings[$field])) {
            $type = Type::getType($this->_class->fieldMappings[$field]['type'])->getBindingType();
        // BEGIN: Jasper N. Brouwer (11-08-2011)
        } else if (isset($this->_class->associationMappings[$field])) {
            if ($this->_class->associationMappings[$field]['isOwningSide']) {
                $targetClass = $this->_em->getClassMetadata($this->_class->associationMappings[$field]['targetEntity']);
                $targetColumn = $this->_class->associationMappings[$field]['joinColumns'][0]['referencedColumnName'];
                if (isset($targetClass->fieldNames[$targetColumn])) {
                    $type = Type::getType($targetClass->fieldMappings[$targetClass->fieldNames[$targetColumn]]['type'])->getBindingType();
                }
            }
        // END: Jasper N. Brouwer (11-08-2011)
        }
        if (is_array($value)) {
            $type += Connection::ARRAY_PARAM_OFFSET;
        }

        $params[] = $value;
        $types[] = $type;
    }
    return array($params, $types);
}

I'll attach a new diff to.

Comment by Guilherme Blanco [ 14/Aug/11 ]

Hi,

Thanks a lot to report this issue and attempt to fix it.
I extracted parts of your patch to resolve this issue, thanks again for investing your time on this.

This issue is not fixed on trunk by commit https://github.com/doctrine/doctrine2/commit/63a2f02f4ddea1ab9191b0e4acfd1d790d2247c7

Cheers,





[DDC-1272] Ability to choose another column name than ID as automatic record identifier in generate:doctrine:crude Created: 12/Jul/11  Updated: 14/Aug/11  Resolved: 14/Aug/11

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

Type: New Feature Priority: Major
Reporter: yofab Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None
Environment:

Symfony RC4, php5.3



 Description   

I got a message while crude generating because of my column names in the database model. They are not "id" named. Could be nice to get a parameter for that ?



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

This is a Symfony bug, not related to Doctrine\ORM package.

Closing since it's not related to this tool, please open the issue report on correct place.

Cheers,





[DDC-1271] Failing tests for PostgreSQL Created: 11/Jul/11  Updated: 31/Jul/11  Resolved: 31/Jul/11

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

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

Ubuntu 10.10 x86_64
PostgreSQL 8.4.4
PHP 5.3.3 & pdo_pgsql



 Description   

The pgsql.phpunit.xml file:

<php>
    <!-- "Real" test database -->
    <var name="db_type" value="pdo_pgsql"/>
    <var name="db_host" value="localhost" />
    <var name="db_username" value="root" />
    <var name="db_password" value="root" />
    <var name="db_name" value="doctrine_tests" />
    <var name="db_port" value="5432"/>

    <!-- Database for temporary connections (i.e. to drop/create the main database) -->
    <var name="tmpdb_type" value="pdo_pgsql"/>
    <var name="tmpdb_host" value="localhost" />
    <var name="tmpdb_username" value="root" />
    <var name="tmpdb_password" value="root" />
    <var name="tmpdb_name" value="doctrine_tests_tmp" />
    <var name="tmpdb_port" value="5432"/>
</php>

root is a user created by me, with SUPERUSER provileges:

ALTER ROLE root WITH SUPERUSER INHERIT NOCREATEROLE CREATEDB LOGIN PASSWORD 'root';

Test output:

PHPUnit 3.5.10 by Sebastian Bergmann.

.SSSSSS......................................F...............   61 / 1137 (  5%)
............................S................................  122 / 1137 ( 10%)
.............................................................  183 / 1137 ( 16%)
.............................................................  244 / 1137 ( 21%)
........................................F....................  305 / 1137 ( 26%)
..........................SSS................................  366 / 1137 ( 32%)
S............................................................  427 / 1137 ( 37%)
....................SS.......................................  488 / 1137 ( 42%)
.............................................................  549 / 1137 ( 48%)
............................................................S  610 / 1137 ( 53%)
..................S..........................................  671 / 1137 ( 59%)
.............................................................  732 / 1137 ( 64%)
.............................................................  793 / 1137 ( 69%)
.............................................................  854 / 1137 ( 75%)
.............................................................  915 / 1137 ( 80%)
.............................................................  976 / 1137 ( 85%)
............................................................. 1037 / 1137 ( 91%)
............................................................. 1098 / 1137 ( 96%)
.................

Time: 57 seconds, Memory: 145.25Mb

There were 2 failures:

1) Doctrine\Tests\ORM\Functional\BasicFunctionalTest::testRemove
Failed asserting that <integer:3> matches expected <integer:2>.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Functional/BasicFunctionalTest.php:161

2) Doctrine\Tests\ORM\Functional\QueryDqlFunctionTest::testDateDiff
Should be roughly -10 (or -9)
Failed asserting that <string:-10 days> matches expected <integer:-10>.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Functional/QueryDqlFunctionTest.php:280

--

Deprecated PHPUnit features are being used

47, ommited by me :)

--

There were 15 skipped tests:

1) Doctrine\Tests\ORM\Query\DqlGenerationTest::testSelect
Not yet implemented.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Criteria/DqlGenerationTest.php:40

2) Doctrine\Tests\ORM\Query\DqlGenerationTest::testSelectDistinct
Not yet implemented.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Criteria/DqlGenerationTest.php:40

3) Doctrine\Tests\ORM\Query\DqlGenerationTest::testSelectJoin
Not yet implemented.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Criteria/DqlGenerationTest.php:40

4) Doctrine\Tests\ORM\Query\DqlGenerationTest::testSelectWhere
Not yet implemented.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Criteria/DqlGenerationTest.php:40

5) Doctrine\Tests\ORM\Query\DqlGenerationTest::testSelectWhereIn
Not yet implemented.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Criteria/DqlGenerationTest.php:40

6) Doctrine\Tests\ORM\Query\DqlGenerationTest::testDelete
Not yet implemented.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Criteria/DqlGenerationTest.php:40

7) Doctrine\Tests\ORM\Functional\CompositePrimaryKeyTest::testCompositeCollectionMemberExpression
How to test this?

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Functional/CompositePrimaryKeyTest.php:83

8) Doctrine\Tests\ORM\Functional\SchemaTool\MySqlSchemaToolTest::testGetCreateSchemaSql
The Doctrine\Tests\ORM\Functional\SchemaTool\MySqlSchemaToolTest requires the use of mysql.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Functional/SchemaTool/MySqlSchemaToolTest.php:15

9) Doctrine\Tests\ORM\Functional\SchemaTool\MySqlSchemaToolTest::testGetCreateSchemaSql2
The Doctrine\Tests\ORM\Functional\SchemaTool\MySqlSchemaToolTest requires the use of mysql.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Functional/SchemaTool/MySqlSchemaToolTest.php:15

10) Doctrine\Tests\ORM\Functional\SchemaTool\MySqlSchemaToolTest::testGetCreateSchemaSql3
The Doctrine\Tests\ORM\Functional\SchemaTool\MySqlSchemaToolTest requires the use of mysql.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Functional/SchemaTool/MySqlSchemaToolTest.php:15

11) Doctrine\Tests\ORM\Functional\Ticket\DDC1050Test::testPerformance
performance skipped

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC1050Test.php:15

12) Doctrine\Tests\ORM\Functional\Ticket\DDC758Test::testManyToManyMergeAssociationAdds
Destroys testsuite

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC758Test.php:17

13) Doctrine\Tests\ORM\Functional\Ticket\DDC758Test::testManyToManyMergeAssociationRemoves
Destroys testsuite

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Functional/Ticket/DDC758Test.php:17

14) Doctrine\Tests\ORM\Mapping\PHPMappingDriverTest::testDiscriminatorColumnDefaults
PHP Mapping Drivers have no defaults.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Mapping/AbstractMappingDriverTest.php:284

15) Doctrine\Tests\ORM\Mapping\StaticPHPMappingDriverTest::testDiscriminatorColumnDefaults
PHP Mapping Drivers have no defaults.

/mnt/fs/doctrine/github/Infranology/doctrine2/tests/Doctrine/Tests/ORM/Mapping/AbstractMappingDriverTest.php:284


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

I don't get the first error, but the second is fixed now.





[DDC-1260] Enable nesting of OR and AND statements in DQL queries Created: 08/Jul/11  Updated: 08/Aug/11  Resolved: 08/Aug/11

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

Type: Improvement Priority: Major
Reporter: Andreas Förthner Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Dependency
is required for DDC-1299 Allow for nested Andx and Orx in Quer... Resolved
Duplicate
is duplicated by DDC-1255 Can't add instance of Andx to QueryBu... Resolved

 Description   

Currently it is not allowed to nest AND and OR conditions in themselves. However, this comes in handy if you try to do a dynamic query rewriting, where you want to add some more conditions without knowing the original query before.

The fix is trivial, just allow to add AND in AND. The same needs to be done for OR. Patch will follow in a second...



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

This can lead to unpredictable situations inside QueryBuilder.
Maybe we can add a "merge" function to Expr\Composite, I'm not sure.

I need to actually test it on every driver to make sure if it doesn't break anything. It was not originally designed to hold same instances. If you pay attention:

((a AND b) AND c) 

Is the same as:

a AND b AND c

Can't you make a check internally and use addMultiple?
In the meantime, I can make tests to check if it doesn't break anything else.

Comment by Guilherme Blanco [ 08/Aug/11 ]

In this commit: https://github.com/doctrine/doctrine2/commit/816ce41f638d28934c79a12ef27f954124b2639e
I applied the support to this improvement, since it does not mess with generated code.





[DDC-1258] Add Debug Listener for UnitOfWork Created: 08/Jul/11  Updated: 09/Jul/11  Resolved: 09/Jul/11

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

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


 Description   

Sometimes you need to debug complex scenarios where cascade operations fail or something weird happens in the UnitOfWork. There should be a listener that dumps the state of the identity map in "onFlush" so that you can more easily see whats going on.






[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-1236] GROUP BY does not work with functions Created: 29/Jun/11  Updated: 02/Dec/11  Resolved: 02/Dec/11

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

Type: Improvement Priority: Major
Reporter: Andreas Hörnicke Assignee: Guilherme Blanco
Resolution: Fixed Votes: 4
Labels: None


 Description   

The following query fails with Cannot group by undefined identification variable (yes CAST-Function was added). Would be nice to have such a feature,

SELECT ...
FROM Task t
...
WHERE
  ...
GROUP BY
  CAST(t.scheduledDate as date)


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

This is documented in the EBNF of DQL that this not works.

Marked as improvement.

Comment by Wladimir Coka [ 18/Oct/11 ]

Is there any workaround?

Comment by Andreas Hörnicke [ 18/Oct/11 ]

Using a native query is a workaround.

Comment by Benjamin Eberlei [ 18/Oct/11 ]

There is another workaround that should work:

SELECT ...,   CAST(t.scheduledDate as date) AS castedDate
FROM Task t
...
WHERE
  ...
GROUP BY
castedDate
Comment by Wladimir Coka [ 18/Oct/11 ]

I tried this:

SELECT ... ,MONTH(t.fechaCreacion) as mes 
FROM Tramite t 
...
WHERE 
... 
GROUP BY 
mes 

But I get this error:

Message: [Semantical Error] line 0, col 202 near 'mes ': Error: 'mes' does not point to a Class.

Comment by Benjamin Eberlei [ 18/Oct/11 ]

Then only native query is a workaround for now

We work on this for 2.2

Comment by Wladimir Coka [ 18/Oct/11 ]

Ok I'll need to move my code to native query... Hope you can fix this with 2.2 or earlier ... Thanks

Comment by Alex Barnes [ 03/Nov/11 ]

BTW I have put in a fix and so far have had no issues.... but this should be considered hack as I'm not very familiar with the internal workings of Doctrine.

See doctrine-dev groups:
https://groups.google.com/d/topic/doctrine-dev/QZMMnYV4V_8/discussion

HTH

Alex

Comment by Guilherme Blanco [ 02/Dec/11 ]

Since this commit: https://github.com/doctrine/doctrine2/commit/2642daa43851878688d01625f272ff5874cac7b2
This issue is solved through the SelectExpression + Hidden + ResultVariable refer.

SELECT 
    ..., CAST(t.scheduledDate as date) AS HIDDEN groupDate
FROM Task t
    ...
WHERE
    ...
GROUP BY
    groupDate




[DDC-1235] Provide fluent interfaces in stub methods Created: 28/Jun/11  Updated: 01/Apr/14  Resolved: 01/Apr/14

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

Type: Improvement Priority: Major
Reporter: Andreas Hörnicke Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Or maybe some template-files could be provided for all stubs.

private static $_setMethodTemplate =
'/**
 * <description>
 *
 * @param <variableType>$<variableName>
 */
public function <methodName>(<methodTypeHint>$<variableName>)
{
<spaces>$this-><fieldName> = $<variableName>;

<spaces>return $this;</spaces>
}';


 Comments   
Comment by Christophe Coevoet [ 29/Oct/12 ]

@beberlei this should be closed as it is the case since 2.2

Comment by Steve Müller [ 01/Apr/14 ]

Fixed in commit: https://github.com/doctrine/doctrine2/commit/2b334977f536e0d4f473ed1faa748d8c37de97db





[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-1213] Make Bit comparsion available Created: 17/Jun/11  Updated: 09/Feb/12  Resolved: 19/Dec/11

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

Type: Improvement Priority: Major
Reporter: Ronald Marske Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None
Environment:

MAC OSX 10.7



 Description   

When you go to compare Bit Values in MySQL Database you can do thiy by "&" or "|" If you do this with Doctrine 2 you got an exception like following:
Message: [Syntax Error] line 0, col 161: Error: Expected =, <, <=, <>, >, >=, != got '&'

So i fixed this problem for me:

Doctrine\ORM\Query\Parser:
Line 2633

    /**
     * ComparisonOperator ::= "=" | "<" | "<=" | "<>" | ">" | ">=" | "!=" | "&" | "|"
     *
     * @return string
     */
    public function ComparisonOperator()
    {
        switch ($this->_lexer->lookahead['value']) {
            case '=':
                $this->match(Lexer::T_EQUALS);

                return '=';

            case '<':
                $this->match(Lexer::T_LOWER_THAN);
                $operator = '<';

                if ($this->_lexer->isNextToken(Lexer::T_EQUALS)) {
                    $this->match(Lexer::T_EQUALS);
                    $operator .= '=';
                } else if ($this->_lexer->isNextToken(Lexer::T_GREATER_THAN)) {
                    $this->match(Lexer::T_GREATER_THAN);
                    $operator .= '>';
                }

                return $operator;

            case '>':
                $this->match(Lexer::T_GREATER_THAN);
                $operator = '>';

                if ($this->_lexer->isNextToken(Lexer::T_EQUALS)) {
                    $this->match(Lexer::T_EQUALS);
                    $operator .= '=';
                }

                return $operator;

            case '!':
                $this->match(Lexer::T_NEGATE);
                $this->match(Lexer::T_EQUALS);

                return '<>';
            /* Changes by SR-RM to make Bit Oprations available */
            case '&':
            	$this->match(LEXER::T_BIT_AND);
            	return '&';
            case '|':
            	$this->match(LEXER::T_BIT_OR);
            	return '|';
            /* Changes by SR-RM End */
            default:
                $this->syntaxError('=, <, <=, <>, >, >=, !=, &, |');
        }
    }

Doctrine\ORM\Query\Lexer:
Line 53

/* Changes SR-RM to make Bit Oprations available */
const T_BIT_AND             = 30;
const T_BIT_OR               = 31;
/* Changes by SR-RM End */

Line 193

/* Changes SR-RM to make Bit Oprations available */
case '&': return self::T_BIT_AND;
case '|': return self::T_BIT_OR;
/* Changes by SR-RM End */

So, maybe you gonna ad this in next Release

Thanks or your good Job



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

This issue is referenced in Github Pull-Request GH-230
https://github.com/doctrine/doctrine2/pull/230

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/230

Comment by Benjamin Eberlei [ 19/Dec/11 ]

This issue is referenced in Github Pull-Request GH-231
https://github.com/doctrine/doctrine2/pull/231

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Related Pull Request was closed: https://github.com/doctrine/doctrine2/pull/231

Comment by Benjamin Eberlei [ 19/Dec/11 ]

Fixed

Comment by Markus Fieber [ 09/Feb/12 ]

I do miss this patch in the recently checked out 2.2 branch. Is there any reason, it was skipped, even if the fix-version here is still 2.2?
I really miss this feature and was unable to get it to work by applying it manually. The parser seems to have troubles applying my parameters :\

Comment by Fabio B. Silva [ 09/Feb/12 ]

Hi Markus

The bit comparisons was been added as DQL functions,
Can you explain your problem ?

Comment by Markus Fieber [ 09/Feb/12 ]

Hi Fabio, thank you for the fast reply and the great Doctrine anyway!

My problem is the following:
I have an @Entity called Picture with some columns and the following

	/** @Column(type = "integer", nullable = false)
	 * @var int */
	private $visibility;

Now I try to fetch entities from the database that satisfy some special bit mask in this visibility attribute by doing the following:

	/** @var $query \Doctrine\ORM\Query */
	$query = $this->entityManager->createQuery('SELECT e FROM Classes\Models\Event e JOIN e.pictures p WHERE p.visibility & :visibility = :visibility ORDER BY p.uploadTime DESC');
	$query->setParameter('visibility', \Classes\Session::instance()->getActualUsersRights());
	return $query->getResult();

The error reported is:

Fatal error:  Uncaught exception 'Doctrine\ORM\Query\QueryException' with message '[Syntax Error] line 0, col 78: Error: Expected end of string, got '='' in ...\Doctrine\ORM\Query\QueryException.php:42
Stack trace:
#0 ...\Doctrine\ORM\Query\Parser.php(380): Doctrine\ORM\Query\QueryException::syntaxError('line 0, col 78:...')
#1 ...\Doctrine\ORM\Query\Parser.php(745): Doctrine\ORM\Query\Parser->syntaxError('end of string')
#2 ...\Doctrine\ORM\Query\Parser.php(213): Doctrine\ORM\Query\Parser->QueryLanguage()
#3 ...\Doctrine\ORM\Query\Parser.php(288): Doctrine\ORM\Query\Parser->getAST()
#4 ...\Doctrine\ORM\Query.php(231): Doctrine\ORM\Query\Parser->parse()
#5 ...\Doctrine\ORM\Query.php(242): Doctrine\ORM\Query->_parse()
#6 in <b>...\Doctrine\ORM\Query\QueryException.php</b> on line <b>42</b><br />

Please note: I applied the above patch by hand to the Doctrine 2.2 code. Before that I got an "expected = got '&'" exception in the query.

Am I wrong, if I look through the code and try to find the suggested lines from Ronald there? They aren't in the downloadable package and even not in the SVN, I checked out this morning from http://svn.github.com/doctrine/doctrine2.git

Comment by Fabio B. Silva [ 09/Feb/12 ]

Hi Markus

The "&" and "|" is not available for database compatibilities
You should use the DQL function BIT_AND or BIT_OR

WHERE BIT_AND( p.visibility, :visibility )
Comment by Markus Fieber [ 09/Feb/12 ]

Thanks a lot Fabio,

stupid me, sorry.

For completeness, I now use:

SELECT e FROM Classes\Models\Event e JOIN e.pictures p WHERE BIT_AND(p.visibility, :visibility) = :visibility ORDER BY p.uploadTime DESC

and seem to get past the critical part.

Now I can go on trying to get the project back to work with the new Doctrine 2.2
I know its worth the work





[DDC-1170] XML Mapping : add attribute "column-definition" for tag "id" Created: 26/May/11  Updated: 05/Dec/11  Resolved: 05/Dec/11

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

Type: New Feature Priority: Minor
Reporter: Nicolas C Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None
Environment:

Linux, Doctrine ORM 2.0.3 on Symfony2, MySQL.



 Description   

XML mapping :

<id name="id" type="integer">
      <generator strategy="IDENTITY"/>
</id>

Generate SQL :

id int auto_increment not null

It's not possible with XML mapping to have :

 id int UNSIGNED not null auto_increment

Because tag "id" doesn't support "column-definition" attribute.
We can have same problem for others types parameters.

I suggest this solution : in file <Doctrine/ORM/Mapping/Driver/XmlDriver.php>

// add this code to line 226 ( in the "Evaluate <id ...>" bloc after the array "mapping" )  :

if(isset($idElement['column-definition'])){
                $mapping['columnDefinition'] = (string)$idElement['column-definition'];
}

New XML mapping :

<id name="id" type="integer" column="id" column-definition="INT unsigned NOT NULL" >
      <generator strategy="IDENTITY"/>
</id>

Warning : "column-definition" must not contains "AUTO_INCREMENT" (added automaticly) :

<id name="id" type="integer" column="id" column-definition="INT unsigned NOT NULL AUTO_INCREMENT" >
      <generator strategy="IDENTITY"/>
</id>

With "AUTO_INCREMENT" in column-definition all foreign keys contain this parameter.



 Comments   
Comment by Guilherme Blanco [ 05/Dec/11 ]

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





[DDC-1165] [ Proposal] entityMethod#find() for Entity with ForeignKey as PrimaryKey, pass entity object instead of id Created: 21/May/11  Updated: 14/Aug/11  Resolved: 14/Aug/11

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

Type: Improvement Priority: Major
Reporter: Jonathan Clus Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

Doctrine 2.1 Beta



 Description   

Hi all, i am currently using Doctrine 2.1Beta because i have an entity with foreignKey as primaryKey:

class IndividualsStatus
{
/**

  • @var Individuals
    *
  • @Id
  • @ManyToOne(targetEntity="Individuals", inversedBy="diagnosers", cascade= {"persist","refresh"})
    * @JoinColumns({ * @JoinColumn(name="individuals_id", referencedColumnName="id") * })
    */
    private $individuals;

    /**
    * @var Diagnosers
    *
    * @Id
    * @ManyToOne(targetEntity="Diagnosers", inversedBy="individuals", cascade={"persist","refresh"}

    )

  • @JoinColumns( { * @JoinColumn(name="diagnosers_id", referencedColumnName="id") * }

    )
    */
    private $diagnosers;

/**

  • @var smallint $status
    *
  • @Column(name="status_individuals", type="smallint")
    */
    private $statusIndividuals;
    }

i use the em find method to get an IndividualsStatus entity, i am expecting to do:

$individuals = $em->find('Individuals', 10);
$diagnosers = $em->find('Diagnosers', 15);

$individualsStatus = $em->find('IndividualsStatus', array('individiduals' => $individuals, 'diagnosers' => $diagnosers));

But i have to do:
$individualsStatus = $em->find('IndividualsStatus', array('individiduals' => $individuals->getId(), 'diagnosers' => $diagnosers->getId()));

It's very trivial but maybe another people was expecting that too.

Cheers



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

This issue is fixed in latest 2.2-DEV by this commit: https://github.com/doctrine/doctrine2/commit/63a2f02f4ddea1ab9191b0e4acfd1d790d2247c7

Cheers,





[DDC-1161] DQL generate duplicate SQL Alias with CTI + oneToOne self referencing Created: 20/May/11  Updated: 16/Oct/11  Resolved: 16/Oct/11

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

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

WAMP , PHP 5.3.5 , MySql 5.5.8
Symfony 2 Beta 1


Attachments: File Content.php     File Page.php    

 Description   

Hi,

I have a Entity "Content" whith several childs entities like "Page" , "Article" in Joined inheritance.
I make DQL directly on entity "Content", that work perfectly with the discriminator map for return/delete/update appropriates objects.
I use "Page" or "Article" entity only for make a new object and persist.

But now I have add a oneToOne self relation in "Content" :
Content#parent_id => Content#id , no cascade.

And now every DQL return :
SQLSTATE[42000]: Syntax error or access violation: 1066 Not unique table/alias: XX
And yes I see in generated SQL that Content's alias is not unique :

For DQL : SELECT c FROM Content WHERE c.status = 1

SQL Result :

SELECT n0_.id AS id0, n0_.name AS name1, n0_.title AS title2, n0_.author AS author3, n0_.author_update AS author_update4, n0_.status AS status5, n0_.type AS type6, n0_.weight AS weight7, n0_.create_on AS create_on8, n0_.update_on AS update_on9, n0_.url AS url10, n0_.zone AS zone11, n0_.children_sort AS children_sort12, n0_.children_sort_type AS children_sort_type13, n0_.path AS path14, n0_.level AS level15, n1_.meta AS meta16, n2_.content AS content17, n3_.description AS description18, n3_.keywords AS keywords19, n3_.gwt AS gwt20, n3_.analytics AS analytics21, n3_.xiti AS xiti22, n0_.class AS class23 FROM ncms_content n0_ LEFT JOIN ncms_page n1_ ON n0_.id = n1_.id LEFT JOIN ncms_article n2_ ON n0_.id = n2_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id LEFT JOIN ncms_website n3_ ON n0_.id = n3_.id LEFT JOIN ncms_content n0_ ON n0_.id = n0_.id WHERE n0_.status =1

=> SQLSTATE[42000]: Syntax error or access violation: 1066 Not unique table/alias: 'n0_'

But if I use getRepository like this :
$em->getRepository('Content')->findBy(array('status'=>1));
It works, and return appropriates objects.
And I can see that "Content" have several unique alias in the SQL query :

SELECT t0.id AS id1, t0.name AS name2, t0.title AS title3, t0.author AS author4, t0.author_update AS author_update5, t0.status AS status6, t0.type AS type7, t0.weight AS weight8, t0.create_on AS create_on9, t0.update_on AS update_on10, t0.url AS url11, t0.zone AS zone12, t0.children_sort AS children_sort13, t0.children_sort_type AS children_sort_type14, t0.path AS path15, t0.level AS level16, t0.parent_id AS parent_id17, t0.class, t18.meta AS meta19, t20.content AS content21, t27.description AS description28, t27.keywords AS keywords29, t27.gwt AS gwt30, t27.analytics AS analytics31, t27.xiti AS xiti32 FROM ncms_content t0 LEFT JOIN ncms_page t18 ON t0.id = t18.id LEFT JOIN ncms_article t20 ON t0.id = t20.id LEFT JOIN ncms_content t22 ON t0.id = t22.id LEFT JOIN ncms_content t23 ON t0.id = t23.id LEFT JOIN ncms_content t24 ON t0.id = t24.id LEFT JOIN ncms_content t25 ON t0.id = t25.id LEFT JOIN ncms_content t26 ON t0.id = t26.id LEFT JOIN ncms_website t27 ON t0.id = t27.id LEFT JOIN ncms_content t33 ON t0.id = t33.id WHERE t0.status =1

Regards,



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

Fixed formatting.

Comment by Benjamin Eberlei [ 05/Jun/11 ]

Can you upload the mapping files and php code? This looks very weird and i dont know where to start debugging from your description.

Comment by Nicolas Badey [ 06/Jun/11 ]

Done, Mapping and Entities (simplified).

I have a little question, how we can acces to the discriminator map in a DQL query or Entity's object ? Because we cannot mappe this field.

Comment by Guilherme Blanco [ 16/Oct/11 ]

Hi Nicholas,

In 2.2-DEV this issue seems to be addressed already.
We did an internal refactoring (that leads us to not merge into 2.1) that addressed this issue.

I added coverage to your issue with this commit and it works nicely: https://github.com/doctrine/doctrine2/commit/33bcf7ad6f67b8641983f51901d0e74cfde8446c

Marking the ticket as fixed in 2.2





[DDC-1150] BasicEntityPersister::expandParameters does not check assiciation mapping when expanding parameters Created: 13/May/11  Updated: 14/Aug/11  Resolved: 14/Aug/11

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

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


 Description   

If you try to find entities, filtering them by field with association mapping (ManyToOne) and use an array as a filter argument it will not work:

    $em->getRepository('EntityBundle:Entity')->findBy(array('child' => array(1,2,3)));
    8 Array to string conversion vendor/doctrine-dbal/lib/Doctrine/DBAL/Connection.php 595

I fixed method BasicEntityPersister::expandParameters:

Index: ../vendor/doctrine/lib/Doctrine/ORM/Persisters/BasicEntityPersister.php
===================================================================
@@ -1300,6 +1300,9 @@
             if (isset($this->_class->fieldMappings[$field])) {
                 $type = Type::getType($this->_class->fieldMappings[$field]['type'])->getBindingType();
             }
+            if (isset($this->_class->associationMappings[$field])) {
+                $type = $this->_class->associationMappings[$field]['type'];
+            }
             if (is_array($value)) {
                 $type += Connection::ARRAY_PARAM_OFFSET;
             }


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

What is $this->_class->associationMappings[$field]['type'] supposed to be? This key does not exist

Comment by Konstantin [ 05/Jun/11 ]

The key exists when ToMany association is used. $field['type'] is a real Doctrine's type of the field, because fieldMappings contains entity type of association.

Checking of this key in Doctrine itself:
https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php#L386

Comment by Benjamin Eberlei [ 11/Jun/11 ]

Yes buts its the type of the association, MANY_TO_ONE ,ONE_TO_MANY, etc, etc..The type of the associated column is not really known.

Comment by Konstantin [ 14/Jun/11 ]

Heh, I was lucky, thanks for pointing it out

In any case we still can find this type by the target class. May be it will be a good to cache it in the associationMappings array (by functions like _validateAndCompleteOneToOneMapping)?

Comment by Benjamin Eberlei [ 14/Jun/11 ]

At that point you still don't have the information since its saved on the related association and we don't access it at this point (otherwise you get a riffling effect and everything is in memory). We could just assume it is PDO::PARAM_STR.

Comment by Guilherme Blanco [ 14/Aug/11 ]

This issue was fixed in https://github.com/doctrine/doctrine2/commit/63a2f02f4ddea1ab9191b0e4acfd1d790d2247c7

Thanks for the report and attempting to fix the issue. =)





[DDC-1131] Couldn't find a class in a subselect Created: 29/Apr/11  Updated: 16/Aug/11  Resolved: 16/Aug/11

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

Type: Bug Priority: Minor
Reporter: Michael Courcy Assignee: Guilherme Blanco
Resolution: Invalid Votes: 0
Labels: None
Environment:

Using symfony 1.4



 Description   

Hi

This dql query work fine

From GrrArea a where a.id not in (select code from Customer where code is not null)

But this

From GrrArea a where a.id not in (select c.code from Customer c where c.code is not null)

Generate this error message : Couldn't find class c, I also try the subselect alone

select c.code from Customer c where c.code is not null 

which works fine



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

This is a Doctrine 1 bug, not a Doctrine 2.

Reopen the ticket and provide more information (like mapping, etc) if it's a Doctrine 2 issue.

Cheers,





[DDC-1116] Sort by association id Created: 15/Apr/11  Updated: 14/Aug/11  Resolved: 14/Aug/11

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

Type: Improvement Priority: Major
Reporter: Thomas Rabaix Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: None


 Description   

For now it is not possible to sort a result by an association field.

ie : SELECT * FROM Post as p ORDER BY p.Author



 Comments   
Comment by Johannes Lauter [ 03/Jun/11 ]

I agree, maybe even make it sortable by a field of the target?

ie: SELECT * FROM Post as p ORDER BY p.Author.Name

Comment by Guillaume Cormier [ 08/Jul/11 ]

I agree with Johannes about sorting by a field of the target.

Without this feature or a decent workaround, I will have to stop using doctrine for my project.

Comment by Guilherme Blanco [ 08/Jul/11 ]

Hi,

I think the first one if doable.
But please take in mind that it's doable if your association is the owning side and is a *ToOne side. I say that because it could generate a SQL like this:

SELECT ... FROM posts p ORDER BY p.author_id

If it's a *ToMany, it's impossible. No way to achieve it.
But if it's the inverse side, it is doable, but it would require a JOIN. We dropped this "auto inclusion" of JOINs back in RC3 because it is not stable and to make it stable would make the overall Parser performance much slow. The other reason is that developer is pretty able to do the join yourself. I'll take the first comment as an example:

SELECT ... FROM Post p INNER JOIN p.Author a ORDER BY a.name

This one is already supported. =)

Cheers,

Comment by Guillaume Cormier [ 08/Jul/11 ]

Thank you Guilherme Blanco, this fixes the issue for me!

Comment by Guilherme Blanco [ 14/Aug/11 ]

Added support to SingleValuedPathExpression in ORDER BY since this commit: https://github.com/doctrine/doctrine2/commit/a0ca506db7e577c55dd89544bfd8ba08962c3cfe

Thanks for the report.

Cheers,





[DDC-1107] Make QueryBuilder's setParameters method mirror the behavior of AbstractQuery's Created: 08/Apr/11  Updated: 14/Aug/11  Resolved: 14/Aug/11

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

Type: Improvement Priority: Minor
Reporter: Jeremiah Dodds Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None
Environment:

platform independent



 Description   

In ORM/QueryBuilder.php,

public function setParameters(array $params, array $types = array())
{
    $this->_paramTypes = $types;
    $this->_params = $params;
    return $this;
}

Makes it so that in order to use the QueryBuilder to conditionally build up a query you have to hold the parameters to be set in a separate variable and call setParameters when you're done building your query, instead of being able to call setParameters at the spot where it would be apparent what that parameter is to someone reading the code. Compare to the method in ORM/AbstractQuery.php:

public function setParameters(array $params, array $types = array())
{
    foreach ($params as $key => $value) {
        if (isset($types[$key])) {
            $this->setParameter($key, $value, $types[$key]);
        } else {
            $this->setParameter($key, $value);
        }
    }
    return $this;
}

which can be called multiple times safely.

It would be awesome if the QueryBuilder's behavior could be modified to match that of AbstractQueries in this regard, but if there's a good reason for the difference in behavior, a mention in the API/Reference docs would be much appreciated.



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

This issue was already fixed on a previous release. Since I could not find the exact commit, marking this item as resolved for 2.2-DEV.





[DDC-1100] INSTANCE OF and IN in QueryBuilder Created: 04/Apr/11  Updated: 15/Aug/11  Resolved: 15/Aug/11

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

Type: New Feature Priority: Major
Reporter: Patrik Votoček Assignee: Guilherme Blanco
Resolution: Fixed Votes: 1
Labels: None


 Description   

I need to obtain specific entity instances. And I don't know how to write better solution for my problem

$nodes = array('Entities\FooNode', 'Entities\BarNode');

$qb->select('Entities\Node', 'n')->where("n.level = 1"); 
$classes = array(); 
foreach ($nodes as $class) { 
        $classes[] = "n INSTANCE OF " . $class; 
} 

$qb->andWhere(call_user_func_array(array($qb->expr(), 'orx'), $classes))); 


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

Implemented in latest 2.2-DEV by commit: https://github.com/doctrine/doctrine2/commit/f148912a28601d9c6234d59661f0e4ad1ae0c138

Cheers,





[DDC-1073] Refactor SqlWalker::walkGroupByItem not to use PathExpression anymore but accept strings (identification variable) aswell Created: 20/Mar/11  Updated: 04/Dec/11  Resolved: 04/Dec/11

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

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

Issue Links:
Reference
is referenced by DDC-1053 GROUP BY crashes Doctrine 2 Resolved

 Description   

Due to DDC-1053 the code in SqlWalker::walkGroupByClause and ::walkGroupByItems() is not as nice as it could be. This is because of the PathExpression type hint.



 Comments   
Comment by Guilherme Blanco [ 04/Dec/11 ]

Issue was resolved by this commit: https://github.com/doctrine/doctrine2/commit/2642daa43851878688d01625f272ff5874cac7b2





[DDC-1071] CASE expressions do not work as documented in EBNF Created: 15/Mar/11  Updated: 08/Aug/11  Resolved: 08/Aug/11

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

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

Issue Links:
Dependency
depends on DDC-3 Support for CASE expressions in DQL Resolved

 Description   

The EBNF definition of DQL on the website (http://www.doctrine-project.org/docs/orm/2.0/en/reference/dql-doctrine-query-language.html) defines the SELECT expression as follows:

SelectExpression ::= IdentificationVariable | PartialObjectExpression | (AggregateExpression | "(" Subselect ")" | FunctionDeclaration | ScalarExpression) [["AS"] AliasResultVariable]

A ScalarExpression, in turn, is defined as follows:

ScalarExpression ::= SimpleArithmeticExpression | StringPrimary | DateTimePrimary | StateFieldPathExpression BooleanPrimary | CaseExpression | EntityTypeExpression

There is already a missing ''|" between "StateFieldPathExpression" and "BooleanPrimary" here.

But ignoring that detail, this definition states that case expressions can show up anywhere in the list of values to be selected in a query, which, of course, would come in handy.

Contrary to this definition, queries like this one will not work:

SELECT someEntity.a, CASE someEntity.b WHEN 1 THEN 'A' ELSE 'B' END FROM \someEntity;

Whereas queries like this one will:

SELECT CASE someEntity.b WHEN 1 THEN 'A' ELSE 'B' END FROM \someEntity;

Both queries should be legitimate, according to the EBNF definition.

In addition, CASE expressions are not allowed in subselects either, although the EBNF definition of the SimpleSelectExpression states that they should be.



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

Case is not fully implemented yet. Its on the roaodmap for 2.1

Comment by Daniel Alvarez Arribas [ 17/Mar/11 ]

I reopen this as a doc issue, as long as the feature is not yet implemented.

At the moment, the Doctrine 2 online documentation is patently misleading with respect to the case statement., It documents the case expression as being supported, when in fact it is not even implemented yet. How is a user supposed to know, by reading the docs, that the feature is not yet implemented? I mean, if something in the EBNF definitions, the normal thing is to expect that it is actually supported. People will choose Doctrine 2, because they believe it does what it is documented to do, and instead end up with something that does not. I know Doctrine 2 comes with no warranty. But this is almost deliberate misdocumentation. This was the case with path expressions, and now with the case statement. It is becoming a bad habit.

Anyway, I am looking forward to full support of case expressions. Until then, I will have to patch my code.

But, PLEASE, PLEASE, fix the docs, to save prospective users some serious pain. It is just unfair to document features that are not there.

Comment by Benjamin Eberlei [ 18/Mar/11 ]

The problem here is that it was planned for 2.0 and its really hard to keep the EBNF and the actual working stuff in sync. I know its not perfect, i will add a note to the docs soonish, but CASE and path expression were the only things that changed and/or didnt get finished for 2.0

Comment by Daniel Alvarez Arribas [ 18/Mar/11 ]

Thanks for taking care.

An option would be to use a parser generator and generate the parser from an EBNF syntax spec, which saves you the process of deriving the EBNF manually from implementation code. As you already opted for maintaining a formal syntax definition, you could as well reap some consequential benefits. Then again, it would probably be a completely different approach. I also do not know a parser gerator capable of generating PHP 5 code.

Another viable option would be making it a habit to update the EBNF definition first, then using it as a starting point for the actual implementation. Then, with each release, simply publish both code and documentation as you normally would. This way the EBNF definition does not run any risk of ever becoming outdated. Unless you find other ways of screwing it, of course

Comment by Benjamin Eberlei [ 20/Mar/11 ]

There is no parser generator for PHP that generates a top-down recursive descent walker as the one we are using. There is a parser generator for bottom-up, but that is targeting php4 and produces ugly code.

We have a convention to always update EBNF and code in conjunction, but given the large EBNF this can just be forgotten sometimes.

Comment by Daniel Alvarez Arribas [ 28/Mar/11 ]

Fixed typo ("EBDF" instead of "EBNF")

Comment by Guilherme Blanco [ 08/Aug/11 ]

In this commit: https://github.com/doctrine/doctrine2/commit/816ce41f638d28934c79a12ef27f954124b2639e
And documented in this commit: https://github.com/doctrine/orm-documentation/commit/189c729f15d2fafecf92662cad9553c2ec3dccd7

This support was FINALLY included. =)





[DDC-1057] The methods of ResultSetMapping should return the current object Created: 04/Mar/11  Updated: 07/Dec/11  Resolved: 07/Dec/11

Status: Resolved
Project: