[DDC-3865] [GH-1487] [DDC-3864] Support any ordering of fields in partial object query with embeddable Created: 04/Aug/15  Updated: 04/Aug/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

Current implementation of partial object query with embeddables breaks when first attribute in field set is embeddable attribute:

```SELECT PARTIAL u.

{name.first, id}

FROM User```






[DDC-3864] Support any ordering of fields in partial object query with embeddable Created: 04/Aug/15  Updated: 04/Aug/15

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

Type: Bug Priority: Minor
Reporter: Egidijus Jucevičius Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Current implementation of partial object query with embeddables breaks when first attribute in field set is embeddable attribute:

SELECT PARTIAL u.{name.first, id} FROM User





[DDC-3863] Wrong return if value is null in JsonArrayType Created: 03/Aug/15  Updated: 03/Aug/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: 2.3, 2.4, Git Master, 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Baptiste Clavié Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal, hydrator, orm, type


 Description   

On the JsonArray type, on the conversion from a database value to a php value, if the value is null or empty, it returns an empty array.

The thing is, I have a inherited field (or more specifically two fields with the same name, which is not in the parent entity (as another subentity doesn't need such a field).

Basically, it tries to load the field which appears two times (for a field name called `field`, it has two columns in the `data` array : `field_1` and `field_2`). The value for a entity has one of these null, respectively the `field_1` for the first subentity, and `field_2` for the second subentity.

The JsonArrayType then recognizes the field named `field` in the data, and returns an empty array if the value is null... Then doctrine stores in into cache, but when it comes to the second field (`field_2`), as it sees he has a cache for `field`, it ignores the value as the value is not null.

So basically, the problems lies within the JsonArrayType, which should return null if the value is null ? But I'm not quite sure if this is BC...

I was not sure if this belonged to the orm or the dbal.



 Comments   
Comment by Baptiste Clavié [ 03/Aug/15 ]

Implementation for master's branch





[DDC-3862] Doctrine\ORM\UnitOfWork::orphanRemovals is private Created: 03/Aug/15  Updated: 03/Aug/15  Resolved: 03/Aug/15

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

Type: Improvement Priority: Minor
Reporter: Erik van Velzen Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: orphanRemoval, transactions


 Description   

This variable has no getter (e.g. getScheduledOrphanRemoval) unlike similar properties like Doctrine\ORM\UnitOfWork::entityDeletions.

It would be useful to me if this were exposed.



 Comments   
Comment by Marco Pivetta [ 03/Aug/15 ]

Exposing UoW internals is usually only leading to issues. Exposing it needs a strong use-case (that cannot be achieved otherwise) before being suggested.





[DDC-3861] Incorrect count in Paginator for queries using GROUP BY Created: 03/Aug/15  Updated: 03/Aug/15

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

Type: Bug Priority: Major
Reporter: Przemyslaw Wrobel Assignee: Steve Müller
Resolution: Unresolved Votes: 0
Labels: None


 Description   

When using group by clause Paginator::count() method returns incorrect result. For example, the count metod produces the following query:
SELECT count(DISTINCT d0_.id) AS sclr_0 FROM diet_templates d0_ WHERE d0_.database_id = 3 AND d0_.type_id = 1
GROUP BY d0_.diet_id, d0_.day, d0_.meal_id

This query returns multiple records because it counts the number of records in groups and not the number of groups, eg. 1,1,1,2.
Since the count() method currently does array_sum like this:
$this->count = array_sum(array_map('current', $this->getCountQuery()->getScalarResult()));
The overall result is 5 (1+1+1+2) instead of 4.
When using group by clause the correct result whould be achived with a simple count on the result like this:
$this->count = count($this->getCountQuery()->getScalarResult());






[DDC-3860] PHP7 compatability issues Created: 03/Aug/15  Updated: 03/Aug/15  Resolved: 03/Aug/15

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

Type: Task Priority: Major
Reporter: Denis Chernosov Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: php-7.0


 Description   

sstalle/php7cc (A command-line tool to check PHP 5.3 - 5.6 code compatibility with PHP 7) has been used

$ php bin/php7cc.php ../some_symfony_project

File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/SQLAnywhere/SQLAnywhereConnection.php
Line 164. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/SQLAnywhere/SQLAnywhereStatement.php
Line 214. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 244. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/SQLSrv/SQLSrvStatement.php
Line 239. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 270. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/SQLSrv/SQLSrvConnection.php
Line 93. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php
Line 88. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/IBMDB2/DB2Connection.php
Line 90. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/IBMDB2/DB2Statement.php
Line 211. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 241. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/OCI8/OCI8Connection.php
Line 112. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/Mysqli/MysqliStatement.php
Line 141. Possible array element creation during by-reference assignment: $this->_bindedValues[$param] =& $this->_values[$param];


File: ../some_symfony_project/vendor/doctrine/orm/lib/Doctrine/ORM/Query/Expr.php
Line 53. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 72. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 271. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();



File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Query/QueryBuilder.php
Line 473. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 501. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 779. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 805. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 838. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 872. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 899. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 965. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 981. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 1004. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Query/Expression/ExpressionBuilder.php
Line 74. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 93. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Portability/Connection.php
Line 144. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php
Line 904. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/SQLServerPlatform.php
Line 1021. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/MySqlPlatform.php
Line 108. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/DrizzlePlatform.php
Line 56. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Platforms/SQLAnywherePlatform.php
Line 383. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connections/MasterSlaveConnection.php
Line 365. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php
Line 925. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/dbal/lib/Doctrine/DBAL/Schema/AbstractSchemaManager.php
Line 91. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();

File: ../some_symfony_project/vendor/doctrine/collections/lib/Doctrine/Common/Collections/ExpressionBuilder.php
Line 45. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();
Line 55. Function argument(s) returned by "func_get_args" might have been modified: func_get_args();


File: ../some_symfony_project/vendor/doctrine/orm/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php
Line 293. Possible array element creation during by-reference assignment: $this->_resultPointers[$dqlAlias] =& $coll[$index];
Line 303. Possible array element creation during by-reference assignment: $this->_resultPointers[$dqlAlias] =& $coll[key($coll)];
                                                                 
  [PhpParser\Error]                                              
  Syntax error, unexpected '.', expecting T_VARIABLE on line 18  


 Comments   
Comment by Marco Pivetta [ 03/Aug/15 ]

Went through all these: no issues found, all false positives.

Please inspect them manually yourself before opening further issues via automated tools.





[DDC-3859] Overriding default identifier generation strategy has no effect on associations Created: 31/Jul/15  Updated: 31/Jul/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.5, 2.4.7
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Grzegorz Szaliński Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: association, generator-strategy, orm
Environment:

Windows 7 Enterprise SP1, Symfony 2.7.2, Doctrine ORM 2.4.7, MySQL 5.6.12, PHP 5.5.0.



 Description   

Hello everyone,

I have an entity with custom ID generator strategy. It works flawlessly.
In some circumstances I have to override this strategy with a "handmade" Id. It works when the main entity is being flushed without associations. But it doesn't work with associations. This example error is thrown:

An exception occurred while executing 'INSERT INTO articles_tags (article_id, tag_id) VALUES (?, ?)' with params ["a004r0", 4]:

SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (sf-test1.articles_tags, CONSTRAINT FK_354053617294869C FOREIGN KEY (article_id) REFERENCES article (id) ON DELETE CASCADE)

This is when foreign keys are configured. For testing I deleted the foreign keys definitions manually. The result was no error, and the associated entity was saved with the foreign key generated based on the default generation strategy (loosing the actual associations). I posted more details on how to reproduce on StackOverflow: http://stackoverflow.com/q/31594338/709626.

I first found the issue using "pure" Doctrine 2.5.0. Then, while trying to debug, I reproduced it in Symfony 2.7.2.

Actually I'm not sure whether it's a bug or I am doing something not correctly. Also this is my first report here so please let me know if I should provide any more details.






[DDC-3858] Doctrine SLC and @version, failure to get optimistic lock Created: 31/Jul/15  Updated: 04/Aug/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: Second Level Cache
Affects Version/s: 2.5
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Dorrogeray Assignee: Fabio B. Silva
Resolution: Unresolved Votes: 0
Labels: SLC
Environment:

PHP 5.5.9, ubuntu



 Description   

Greetings everyone,

UPDATE: As a temporary workaround, I switched to the less performant READ_WRITE with the basic filelock implementation, and the problem went away.

I am using Doctrine 2.5 with SLC enabled (memcached) and I have encountered some strange behaviour. When doctrine fetches entities from cache, the @version column is actually set to NULL instead of whatever value is correctly in the database - looks like the @version doesn't get updated as far as cache is concerned.

Note that afected entity uses @ORM\Cache(usage="NONSTRICT_READ_WRITE", region="Entity\Contact")

If I restart memcached, correct @version is loaded (because of the force reload).

This also leads to failure to get optimistic lock (due to incorrectly evaluated version mismatch).

I have no idea, but could this be somehow related to http://www.doctrine-project.org/jira/browse/DDC-3781 ?

For now, Ill try to prevent this issue from occurring by clearing updated entities from cache, and thus forcing their reload by whoever will request them next.

Thanks for any response/advice!

Here is part of call stack, this time failing on different entity, but for the same reason:

#0 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php(483): Doctrine\ORM\OptimisticLockException::lockFailed(Object(DoctrineORMModule\Proxy_CG_\CsnTour\Entity\Customer))
#1 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Entity/BasicEntityPersister.php(366): Doctrine\ORM\Persisters\Entity\BasicEntityPersister->updateTable(Object(DoctrineORMModule\Proxy_CG_\CsnTour\Entity\Customer), '`customer`', Array, true)
#2 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/Cache/Persister/Entity/NonStrictReadWriteCachedEntityPersister.php(95): Doctrine\ORM\Persisters\Entity\BasicEntityPersister->update(Object(DoctrineORMModule\Proxy_CG_\CsnTour\Entity\Customer))
#3 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(1069): Doctrine\ORM\Cache\Persister\Entity\NonStrictReadWriteCachedEntityPersister->update(Object(DoctrineORMModule\Proxy_CG_\CsnTour\Entity\Customer))
#4 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(384): Doctrine\ORM\UnitOfWork->executeUpdates(Object(Doctrine\ORM\Mapping\ClassMetadata))
#5 /var/www/TravelSupport/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php(356): Doctrine\ORM\UnitOfWork->commit(NULL)
#6 /var/www/TravelSupport/module/CsnTour/src/CsnTour/Controller/TicketController.php(2014): Doctrine\ORM\EntityManager->flush()



 Comments   
Comment by Fabio B. Silva [ 04/Aug/15 ]

Dorrogeray,
Can you please add a failing test case ?

If you need help to write the test you can use this ticket as a reference.





[DDC-3857] [GH-1485] Changed references from PHP6 to PHP7 Created: 31/Jul/15  Updated: 31/Jul/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

Found a reference to PHP6 while reading the best practices docs.

While doing this tiny change, I also found a couple more references to it in the tests which I changed too.

If this is a funny reference to it, I'm happy for you to leave it as is. Otherwise, this PR replaces the existing references to PHP6 for PHP7 instead.






[DDC-3856] [GH-1484] Make exception message configurable for NoResultException Created: 31/Jul/15  Updated: 31/Jul/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

Currently it's not possible to use a custom exception message for the NoResultException. It would be great to use a custom one. For example you can define what specific result was expected or with what query it was executed, let's say you want to find members with a select query. Then it would be great if the message could be 'No members found for query.', instead of the default message.

This change is backward compatible, because it checks for emptiness of the message, and only if it's not empty it uses the custom message. Furthermore it's now possible to loop the parameters $code and $prevision exception throw this NoResultException.






[DDC-3855] Inheritance JOINED, left select child entity retrieves not valid object Created: 30/Jul/15  Updated: 30/Jul/15

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

Type: Bug Priority: Major
Reporter: Gregory Pokrovsky Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: DQL, Inheritance, Joined, Query,


 Description   

Delivery is child of inheritance parent Place. If delivery not set in query, result will have array of PlaceAddress entities, because PlaceAddress is a root alias, but when delivery added to select, then result will contain array of PlaceTypeDelivery but root alias stays PlaceAddress. Is this a bug?

$this->_em
->createQueryBuilder()
->select(['partial addresses.

{id,realAddress,phone}

','place','partial workday.

{id}','partial delivery.{id}

'])
->from('CommonBundle:PlaceAddress', 'addresses')
->leftJoin("addresses.place", "place", "WITH", "addresses.place = place.id")
->leftJoin("addresses.workday", "workday", "WITH", "workday.address = addresses.id")
->where("place INSTANCE OF CommonBundle:PlaceTypeDelivery")
->andWhere("place.enabled = 1");






[DDC-3854] [GH-1483] fix typo Created: 30/Jul/15  Updated: 30/Jul/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:






[DDC-3853] [GH-1480] Allow custom id generators to handle composite keys Created: 28/Jul/15  Updated: 28/Jul/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

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

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

Message:

Currently when using composite keys, any other id generation strategy than
NONE (assigned identifiers) is triggering an exception in ClassMetadataInfo.

This commit allows to use the CUSTOM strategy with composite keys, therefore
to allow a custom id generator to handle the composite key identifier
generation.






Generated at Tue Aug 04 19:57:53 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.