EAGER loading an Association Mapped IDs #6038

New Issue

admin · 2026-01-22T15:25:12+01:00

admin commented

2026-01-22 15:25:12 +01:00

Originally created by @mattsah on GitHub (Aug 14, 2018).

Originally assigned to: @Ocramius on GitHub.

Bug Report

Q	A
BC Break	no
Version	2.5.14

Summary

When trying to fetch an associated entity using EAGER, association mapped IDs seem to fail with spl_object_hash() requires parameter 1 to be an object.

Current behavior

I have an entity id which is an association key, see config below. I'd like to perform an EAGER fetch on the related person on this entity, however, when I do an eager fetch any attempt to Providers::find() (a standard Doctrine find() on a repository) fails with spl_object_hash() requires parameter 1 to be an object. Keeping fetch: LAZY resolves this.

I traced this down to ~lines 998 - 1005 (in this version) of the BasicEntityPersister:

$field = $sourceClass->getFieldForColumn($sourceKeyColumn);
$value = $sourceClass->reflFields[$field]->getValue($sourceEntity);

if (isset($sourceClass->associationMappings[$field])) {
    $value = $this->em->getUnitOfWork()->getEntityIdentifier($value);
    $value = $value[$this->em->getClassMetadata($sourceClass->associationMappings[$field]['targetEntity'])->identifier[0]];
}

$sourceEntity appears to be the provider, $field is person which is, and indeed, when fetching EAGER, it appears the person value at that point is NULL -- not clear why.

How to reproduce

Create an associated entity whose id is an association key.:

Provider:
    type: entity
    table: providers
    repositoryClass: Providers
    id:
        person:
            associationKey: true
    fields:
        dateCreated:
            type: datetime
            nullable: false
            column: date_created
        dateModified:
            type: datetime
            nullable: true
            column: date_modified
    oneToOne:
        person:
            targetEntity: Person
            cascade: [ persist ]
            fetch: EAGER
            mappedBy: null
            inversedBy: null
            joinColumns:
                person:
                    referencedColumnName: id
                    onDelete: CASCADE
            orphanRemoval: false
    manyToMany:
        states:
            targetEntity: State
            cascade: {  }
            fetch: EAGER
            mappedBy: null
            inversedBy: providers
            joinTable:
                name: state_providers
                joinColumns:
                    -
                        name: provider
                        referencedColumnName: person
                        onDelete: CASCADE
                inverseJoinColumns:
                    -
                        name: state
                        referencedColumnName: id
                        onDelete: CASCADE
            orderBy: null
    lifecycleCallbacks: {  }

Attempt to find using the related entity:

$em->getRepository('Provider')->find($person);

Expected behavior

I would expect how the associated entity is fetched not to affect my ability to find its related entity based on it.

Originally created by @mattsah on GitHub (Aug 14, 2018). Originally assigned to: @Ocramius on GitHub. ### Bug Report  | Q | A |------------ | ------ | BC Break | no | Version | 2.5.14 #### Summary When trying to fetch an associated entity using EAGER, association mapped IDs seem to fail with `spl_object_hash() requires parameter 1 to be an object`. #### Current behavior I have an entity id which is an association key, see config below. I'd like to perform an `EAGER` fetch on the related person on this entity, however, when I do an eager fetch any attempt to `Providers::find()` (a standard Doctrine `find()` on a repository) fails with `spl_object_hash() requires parameter 1 to be an object.` Keeping `fetch: LAZY` resolves this. I traced this down to ~lines 998 - 1005 (in this version) of the `BasicEntityPersister`: ``` $field = $sourceClass->getFieldForColumn($sourceKeyColumn); $value = $sourceClass->reflFields[$field]->getValue($sourceEntity); if (isset($sourceClass->associationMappings[$field])) { $value = $this->em->getUnitOfWork()->getEntityIdentifier($value); $value = $value[$this->em->getClassMetadata($sourceClass->associationMappings[$field]['targetEntity'])->identifier[0]]; } ``` `$sourceEntity` appears to be the provider, `$field` is `person` which is, and indeed, when fetching EAGER, it appears the person value at that point is `NULL` -- not clear why. #### How to reproduce Create an associated entity whose id is an association key.: ``` Provider: type: entity table: providers repositoryClass: Providers id: person: associationKey: true fields: dateCreated: type: datetime nullable: false column: date_created dateModified: type: datetime nullable: true column: date_modified oneToOne: person: targetEntity: Person cascade: [ persist ] fetch: EAGER mappedBy: null inversedBy: null joinColumns: person: referencedColumnName: id onDelete: CASCADE orphanRemoval: false manyToMany: states: targetEntity: State cascade: { } fetch: EAGER mappedBy: null inversedBy: providers joinTable: name: state_providers joinColumns: - name: provider referencedColumnName: person onDelete: CASCADE inverseJoinColumns: - name: state referencedColumnName: id onDelete: CASCADE orderBy: null lifecycleCallbacks: { } ``` Attempt to find using the related entity: ``` $em->getRepository('Provider')->find($person); ``` #### Expected behavior I would expect how the associated entity is fetched not to affect my ability to find its related entity based on it.

admin added the Bug Invalid labels 2026-01-22 15:25:12 +01:00

admin closed this issue

2026-01-22 15:25:12 +01:00

admin commented

2026-01-22 15:25:13 +01:00

@Ocramius commented on GitHub (Aug 15, 2018):

Please upgrade your ORM version first, then report the issue again if it still occurs.

@Ocramius commented on GitHub (Aug 15, 2018): Please upgrade your ORM version first, then report the issue again if it still occurs.

admin commented

2026-01-22 15:25:13 +01:00

@mattsah commented on GitHub (Aug 15, 2018):

ORM version is determined by composer, based on requirements for laravel-doctrine/orm as well as the version of PHP which our servers will have available. Newer versions of doctrine require versions which are unavailable on our servers.

To be clear, what is the minimum version of doctrine ORM which is supported for PHP 7.0? Is there any?

@mattsah commented on GitHub (Aug 15, 2018): ORM version is determined by composer, based on requirements for laravel-doctrine/orm as well as the version of PHP which our servers will have available. Newer versions of doctrine require versions which are unavailable on our servers. To be clear, what is the minimum version of doctrine ORM which is supported for PHP 7.0? Is there any?

admin commented

2026-01-22 15:25:13 +01:00

@Ocramius commented on GitHub (Aug 15, 2018):

No, the current active releases require PHP 7.1+

@Ocramius commented on GitHub (Aug 15, 2018): No, the current active releases require PHP 7.1+

admin referenced this issue

2026-01-22 16:05:32 +01:00

[PR #6038] Remove excessive identifier hashing generated string length checks #9828

Sign in to join this conversation.