DDC-3628: Embeddable Array Hydration Issue #4455

New Issue

admin · 2026-01-22T14:42:02+01:00

admin commented

2026-01-22 14:42:02 +01:00

Originally created by @doctrinebot on GitHub (Mar 19, 2015).

Originally assigned to: @Ocramius on GitHub.

Jira issue originally created by user rj.garcia:

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
        (
           ...
        )
    )

Originally created by @doctrinebot on GitHub (Mar 19, 2015). Originally assigned to: @Ocramius on GitHub. Jira issue originally created by user rj.garcia: 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 ( ... ) ) ```

admin added the Bug label 2026-01-22 14:42:02 +01:00

admin closed this issue

2026-01-22 14:42:02 +01:00

admin commented

2026-01-22 14:42:02 +01:00

@doctrinebot commented on GitHub (Mar 19, 2015):

Comment created by @ocramius:

This is actually expected behavior, IMO

@doctrinebot commented on GitHub (Mar 19, 2015): Comment created by @ocramius: This is actually expected behavior, IMO

admin commented

2026-01-22 14:42:02 +01:00

@doctrinebot commented on GitHub (Mar 19, 2015):

Comment created by @beberlei:

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.

@doctrinebot commented on GitHub (Mar 19, 2015): Comment created by @beberlei: 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.

admin commented

2026-01-22 14:42:03 +01:00

@doctrinebot commented on GitHub (Mar 19, 2015):

Comment created by rj.garcia:

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

@doctrinebot commented on GitHub (Mar 19, 2015): Comment created by rj.garcia: 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

admin commented

2026-01-22 14:42:04 +01:00

@doctrinebot commented on GitHub (Mar 19, 2015):

Comment created by @ocramius:

[~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.

@doctrinebot commented on GitHub (Mar 19, 2015): Comment created by @ocramius: [~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.

admin commented

2026-01-22 14:42:04 +01:00

@doctrinebot commented on GitHub (Mar 19, 2015):

Comment created by rj.garcia:

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).

@doctrinebot commented on GitHub (Mar 19, 2015): Comment created by rj.garcia: 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).

admin commented

2026-01-22 14:42:04 +01:00

@doctrinebot commented on GitHub (Mar 19, 2015):

Comment created by @ocramius:

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).

@doctrinebot commented on GitHub (Mar 19, 2015): Comment created by @ocramius: 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).

admin commented

2026-01-22 14:42:05 +01:00

@doctrinebot commented on GitHub (Mar 19, 2015):

Issue was closed with resolution "Won't Fix"

@doctrinebot commented on GitHub (Mar 19, 2015): Issue was closed with resolution "Won't Fix"

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#4455