[DDC-3625] [GH-1339] [DDC-2224] Honor convertToDatabaseValueSQL() in DQL query parameters Created: 18/Mar/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: cache, dql, parameter

Issue Links:
Dependency
is required for DDC-2224 convertToDatabaseValueSQL() is not ho... Resolved

 Description   

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

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

Message:

This is a follow-up to the abandoned #574 by @mnapoli, that fixes DDC-2224(http://www.doctrine-project.org/jira/browse/DDC-2224).

At the time, @beberlei closed the PR for the following reason, deemed unfixable:

> Passing a type into the parameters is not recognized during caching, that means, using a DQL cache, the same DQL statement with (different parameter types) will lead to the same SQL being generated, depending on if the first or the second set parameter query is executed first.

This PR re-integrates the original fix, and offers a solution to the above issue: take the parameter types into account when checking the local `ParserResult` and the query cache.

In addition to the test for the DDC-2224 issue, I added a test to ensure that changing a parameter type invalidates the cache.



 Comments   
Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DDC-3621] Support embeddables in partial object query Created: 17/Mar/15  Updated: 25/Mar/15  Resolved: 23/Mar/15

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

Type: Improvement Priority: Minor
Reporter: Karl Rixon Assignee: Guilherme Blanco
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Dependency
depends on DDC-3630 [GH-1343] Support embeddables in part... Resolved

 Description   

Hi,

Currently it's not possible to combine embeddables and partial objects - for example:

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

This results in an exception from the parser.

Is this just as simple as making the following change to Parser::PartialObjectExpression() line 1782?

// before
$partialFieldSet[] = $this->lexer->token['value'];

// after
$field = $this->lexer->token['value'];

while ($this->lexer->isNextToken(Lexer::T_DOT)) {
    $this->match(Lexer::T_DOT);
    $this->match(Lexer::T_IDENTIFIER);
    $field .= '.'.$this->lexer->token['value'];
}

$partialFieldSet[] = $field;


 Comments   
Comment by Karl Rixon [ 23/Mar/15 ]

doctrinebot automatically opened DDC-3621 when I issued a PR, so closing this issue as a duplicate.

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3630] [GH-1343] Support embeddables in partial object query expression [DDC-3621] Created: 20/Mar/15  Updated: 25/Mar/15  Resolved: 23/Mar/15

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: dql, embeddables, hydration, partial

Issue Links:
Dependency
is required for DDC-3621 Support embeddables in partial object... Resolved

 Description   

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

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

Message:

I don't see any existing tests covering this class, but all existing tests pass with this change.



 Comments   
Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3062] [GH-997] [FIX] Allow to use ManyToMany with all operators Created: 31/Mar/14  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

Type: Bug Priority: Critical
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Incomplete Votes: 0
Labels: collection, criteria, many-to-many, persister


 Description   

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

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

Message:

Hi,

ping @guillhermoblanco : I think this may be blocking for 2.5

I introduced not so long ago support for ManyToMany for Criteria. However, I realized my implementation was really incomplete, because I hard-coded the "=" operator (https://github.com/doctrine/doctrine2/pull/885/files#diff-982b7374bbe9d5f4b6b71f4869a446eaR575). This means that it fails in a lot of cases when you use something different than "eq" for Criteria.

This PR fixes that, however it's a bit hacky. The SqlExpressionVisitor was made by type hinting for a BasicEntityPersister, preventing us from using us for a collection persister. Therefore I added a new interface to keep BC.

There is also a lot of code duplication (the whole "getSelectConditionSQL" was copied from the BasicEntityPersister), but without trait or BC, I have no idea about how to solve it.

All tests pass, test were added for other operators.



 Comments   
Comment by Doctrine Bot [ 13/Jan/15 ]

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

Comment by Doctrine Bot [ 13/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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





[DDC-3534] [GH-1280] [DDC-3346] #1277 find one with eager loads is failing Created: 23/Jan/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: collection, eager, fetch, hydrator, lazy-loading, many-to-many, onetomany, persister

Issue Links:
Dependency
is required for DDC-3346 findOneBy returns an object with part... Resolved
is required for DDC-3531 [GH-1277] [DDC-3346] Failing test for... Resolved

 Description   

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

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

Message:

Ping @scaytrase

Note that this is a first revision and needs refactoring, so please consider helping out with that if you can.

Ping @guilhermeblanco: please check the `CachedPersisterContext` stuff: it's dirty as heck, but that's because the persister internal generated SQL caching is inconsistent as heck too.

Resolution path for 2.4.x will be to throw an exception if there is an offset or a limit.



 Comments   
Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 23/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 24/Jan/15 ]

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

Comment by Doctrine Bot [ 25/Jan/15 ]

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





[DDC-3638] [GH-1348] Doctrine mapping:import command Created: 25/Mar/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

Status: Resolved
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: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

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

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

Message:

Why I cannot find this command:

`` php app/console doctrine:mapping:import --force AcmeBlogBundle xml ``
[here](http://doctrine-orm.readthedocs.org/en/latest/reference/tools.html?highlight=command) I mean mapping:import command.

I already replace this command:

`` php app/console doctrine:mapping:convert xml ./src/Acme/BlogBundle/Resources/config/doctrine/metadata/orm --from-database --force ``
with

`` sudo vendor/bin/doctrine orm:convert-mapping xml '/var/www/html/laravel/package' --from-database --force ``
and worked well.



 Comments   
Comment by Doctrine Bot [ 25/Mar/15 ]

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

Comment by Doctrine Bot [ 25/Mar/15 ]

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





[DDC-3636] cannot extend ClassMetadataFactory Created: 25/Mar/15  Updated: 25/Mar/15  Resolved: 25/Mar/15

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

Type: Improvement Priority: Major
Reporter: Jurj Alin Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

We cannot extend the `ClassMetadataFactory` because most of the members are private.
Use case:
I have to overwrite only the `getShortName` and because most are private i need to copy/paste all the other private methods in my extended class just to make it work



 Comments   
Comment by Marco Pivetta [ 25/Mar/15 ]

The class metadata factory is not designed to be extensible, as it is an internal doctrine component.

Comment by Jurj Alin [ 25/Mar/15 ]

i understand that, however we are talking about custom discriminator value, nothing else, for example if i have the entity Application\Entity\User as the discriminator, it will be converted to `user`. Thats what i'm trying to do, just to allow different discriminator generation

Comment by Marco Pivetta [ 25/Mar/15 ]

Can't this simply be fixed via explicit mapping or via an event handler?





[DDC-3623] [GH-1337] Paginator OrderBy fix take 2 Created: 17/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: distinct, mssql, oracle, orderBy, paginator, postgresql

Issue Links:
Dependency
is required for DDC-3606 [GH-1325] fixed PostgreSQL and Oracle... Resolved
is required for DDC-3629 [GH-1342] Paginator functional tests Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

This PR fixes issues created in #1220, reported in #1267. The original PR was reverted in #1283.

The issue was that in queries ordered by joined association columns, the joined column aliases did not exist in the outer query created in LimitSubqueryOutputWalker.

This PR adds functionality to LimitSubqueryOutputWalker which finds any such columns referenced in the OrderBy clause, and adds them to the SelectStatement prior to SQL generation.



 Comments   
Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 17/Mar/15 ]

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

Comment by Doctrine Bot [ 24/Mar/15 ]

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





[DDC-3629] [GH-1342] Paginator functional tests Created: 19/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: distinct, mssql, oracle, orderBy, orderby, paginator, postgresql

Issue Links:
Dependency
depends on DDC-3623 [GH-1337] Paginator OrderBy fix take 2 Resolved
is required for DDC-3606 [GH-1325] fixed PostgreSQL and Oracle... Resolved

 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

PaginationTest has been expanded and now covers ordering and limiting rather thoroughly.

4 tests fail on PostgreSQL and MySQL, 14 tests fail on SQL Server, and I didn't try any other DBMS.



 Comments   
Comment by Doctrine Bot [ 22/Mar/15 ]

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





[DDC-3606] [GH-1325] fixed PostgreSQL and Oracle pagination issues Created: 09/Mar/15  Updated: 24/Mar/15  Resolved: 24/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: distinct, mssql, orderBy, paginator, postgresql

Issue Links:
Dependency
depends on DDC-3623 [GH-1337] Paginator OrderBy fix take 2 Resolved
depends on DDC-3629 [GH-1342] Paginator functional tests Resolved

 Description   

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

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

Message:

Pagination with ordering on 1:m and m:m relations, was not working
properly because of selecting the ordered fields in main select
statement with distinction (e.g. SELECT DISTINCT e0_.id, p1_.name from
... ) in this case we've received less rows than we've required in
query. So I've modified the subquery generation part.
In case of PostgreSQL and Oracle added the row_number in the subquery
over order by statement, then the main select is grouped by id and
selected min of row number, also ordering by rownumber asc, because they
are on right order already (e.g. select e0_.id, min(rownum) as rownum
from ..... order by rownum).
In case of MySQL, the subselect result with ids are in right order so
there is no need to select that fields(this fixes the same issue too)
In other cases I haven't tested because of that leaved the same.



 Comments   
Comment by Vahe Shadunts [ 09/Mar/15 ]

Hi Benjamin Eberlei, please let me know if I need to change something, I've used regular expression to change the doctrine's generated select statement, if there is a better way please let me know.

The code I've modified
https://github.com/vaheshadunts/doctrine2/blob/DDC-1958/lib/Doctrine/ORM/Tools/Pagination/LimitSubqueryOutputWalker.php#L221

Comment by Vahe Shadunts [ 09/Mar/15 ]

Also please let me know should I have to modify the test assertions of the queries which are have changed by my modifications? Or I have to skip the continuous integration ?

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 16/Mar/15 ]

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

Comment by Doctrine Bot [ 24/Mar/15 ]

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

Comment by Doctrine Bot [ 24/Mar/15 ]

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





[DDC-3626] [GH-1340] Add inversed by annotations on auto generate entities Created: 18/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

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

Type: New Feature Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: bidirectional, entityGenerator


 Description   

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

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

Message:

Add inversed by annotations on auto generate entities.

Source:
http://w3facility.org/question/symfony2-doctrine2-generate-one-to-many-annotation-from-existing-database-by-doctrinemappingimport/#answer-17881139



 Comments   
Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3634] [GH-1346] Fix: generated IDs are converted to integer Created: 23/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 1
Labels: autogeneration, autoincrement, big-integer, identifier


 Description   

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

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

Message:

When I try to use type `bigint` and `@GeneratedValue` together, generated value is converted to integer.

See PHP documentation http://php.net/manual/en/language.types.array.php

> Strings containing valid integers will be cast to the integer type. E.g. the key "8" will actually be stored under 8. On the other hand "08" will not be cast, as it isn't a valid decimal integer.



 Comments   
Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3632] [GH-1345] Fix crashes in ConvertMappingCommand and GenerateEntitiesCommand... Created: 20/Mar/15  Updated: 23/Mar/15  Resolved: 23/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: discriminator-map, inheritance, metadata, reflection


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

... when using entities with joined table inheritance

ConvertMappingCommand and GenerateEntitiesCommand both use the DisconnectedClassMetadataFactory, which allows metadata manipulation without loading the associated classes. Commit a36bea broke these two commands by adding a bailout condition in ClassMetadataFactory::populateDiscriminatorValue which checks $metadata->reflClass->isAbstract(). If the DisconnectedClassMetadataFactory is being used, $metadata->reflClass will always be null, causing a fatal error, "Fatal error: Call to a member function isAbstract() on null".

This commit adds a check to see if $metadata->reflClass is set before checking isAbstract.



 Comments   
Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 23/Mar/15 ]

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





[DDC-3631] [GH-1344] Fix tests for SLC console commands failing due to console output decoration Created: 20/Mar/15  Updated: 22/Mar/15  Resolved: 22/Mar/15

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: cache, console, second-level-cache, tools


 Description   

This issue is created automatically through a Github pull request on behalf of zeroedin-bill:

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

Message:

The tests for the SLC console commands were failing on my box because the console output was being decorated with ANSI color codes, while the test assertions were using undecorated strings.

This PR turns off output decoration when these console commands are executed in the tests.



 Comments   
Comment by Doctrine Bot [ 20/Mar/15 ]

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

Comment by Doctrine Bot [ 22/Mar/15 ]

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

Comment by Doctrine Bot [ 22/Mar/15 ]

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





[DDC-3628] Embeddable Array Hydration Issue Created: 19/Mar/15  Updated: 19/Mar/15  Resolved: 19/Mar/15

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

Type: Bug Priority: Major
Reporter: RJ Garcia Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: array, hydration, orm
Environment:

Mac OS X 10.10.2

PHP 5.6.6 (cli) (built: Mar 10 2015 14:21:21)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies


Attachments: File B5.Mdl.Bite5.CoverPhoto.CoverPhoto.dcm.yml     File B5.Mdl.Bite5.CoverPhoto.CoverPhotoCollection.dcm.yml    

 Description   

I've stumbled across the doctrine embeddable system, and it's been working great; however, I found an inconsistency with the array hydration.

Attached are my configuration files for my parent object and the embeddable. When doing a simple query to retrieve the parent object and use `getArrayResult`, I get the following data structure

[cover_photos] => Array
                (
                    [id] => ..
                    [url_key] => ...
                    [original.width] => ...
                    [original.height] => ...
                    [original.url] => ...
                    [original.type] => ..
                    [cropped.width] => ..
                    [cropped.height] => ..
                    ...
                )

This is inconsistent with how normal hydration works where the expected result would be something like

[coverphotos] => Array
    (
        [id] => ..
        [url_key] => ..
        [original] => Array
        (
           ...
        )
    )


 Comments   
Comment by Marco Pivetta [ 19/Mar/15 ]

This is actually expected behavior, IMO

Comment by Benjamin Eberlei [ 19/Mar/15 ]

Maybe we could document this, as it is a bit weird. But from my perspective this is ok as well. Everything else is very expensive to implement, not sure if its worth the benefit.

Comment by RJ Garcia [ 19/Mar/15 ]

Well, currently, I'm working around the issue with the following function

function array_expand(&$array, $separator = '.')
{
    $keys_to_recurse = [];
     foreach ($array as $key => $value) {
        $sep_position = strpos($key, $separator);

        if ($sep_position === false) {
            continue;
        }

        $prefix = substr($key, 0, $sep_position);
        $suffix = substr($key, $sep_position + 1);

        if (!array_key_exists($prefix, $array)) {
            $array[$prefix] = [];
            $keys_to_recurse[] = $prefix;
        }

        $array[$prefix][$suffix] = $value;
        unset($array[$key]);
     }

     foreach ($keys_to_recurse as $key) {
        array_expand($array[$key], $separator);
     }
}

Personally, as a user of this embeddable's feature, in my specific usage of the embeddables with array hydration, I need them in hierarchal format. I'm not too familiar with the hydration internals, so I can't comment on the difficulty of expanding the embeddable entities into structured hierarchal data

Comment by Marco Pivetta [ 19/Mar/15 ]

RJ Garcia is there any reason why you're using array hydration here?

Adding this change to the ArrayHydrator is actually problematic/complex (and a BC break now, since we froze 2.5.0-beta1 yesterday).

I would suggest keeping it out of the ORM.

Comment by RJ Garcia [ 19/Mar/15 ]

Yes, I was running into issues with prefetching in my query. Even though I had prefetched all of my desired associations, doctrine was still performing extra queries to load associations that I wasn't using/wanted. After I fetched my main entity collection, I needed to traverse it (perform some changes) and convert to arrays for outputting in a JSON api. When I traversed the object graph, doctrine would run queries on sub entities that I didn't want. When I switched to array hydration, naturally, I didn't get any of those extra queries when I traversed the array structure. I've also found better performance results when using array hydration, and because I'm only querying my entities to export them into JSON, I don't need full data/entity consistency.

Just recently, I stated using embeddables, and that's how I found out about the array hydration difference (because I was already using array hydration).

Comment by Marco Pivetta [ 19/Mar/15 ]

Resolving as won't fix since at this point, this is a BC break and is also quite complex/useless to solve from our perspective (we did have some internal discussion about it).





Generated at Thu Mar 26 19:18:02 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.