Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UnitOfWork::persisters caches join statements #11860

Open
oojacoboo opened this issue Mar 5, 2025 · 0 comments
Open

UnitOfWork::persisters caches join statements #11860

oojacoboo opened this issue Mar 5, 2025 · 0 comments

Comments

@oojacoboo
Copy link
Contributor

Bug Report

Q A
Version 3.3.2

Summary

I've been dealing with an issue where join conditions on a query, combined with a filter, were incorrect. It was using the join conditions from a previous query on the same entity within a loop.

Current behavior

It turns out the issue is related to the UnitOfWork::getEntityPersister method, specifically the use of the persisters property for state/cache.

public function getEntityPersister(string $entityName): EntityPersister
    // This if block is the issue.  When commented out, the issue is resolved.
    if (isset($this->persisters[$entityName])) {
        return $this->persisters[$entityName];
    }
    ...
}

Expected behavior

Avoid caching these persisters, or add improved logic to rebuild the join statement in the EntityPersister instance. I wasn't able to determine the proper way to ensure the selectJoinSql is properly rebuilt when reusing an existing persister instance.

How to reproduce

The issue exists with the BasicEntityPersister::currentPersisterContext->selectJoinSql property. When the persister is cached within the UnitOfWork, this selectJoinSql never gets rebuilt, resulting in an incorrect join statement. It's specifically seen with filter conditions.

oojacoboo added a commit to rentpost/doctrine-orm that referenced this issue Mar 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant