8000 [DoctrineBridge] fixed caching when EntityType is used with the "query_builder" option by webmozart · Pull Request #6206 · symfony/symfony · GitHub
[go: up one dir, main page]

Skip to content

[DoctrineBridge] fixed caching when EntityType is used with the "query_builder" option #6206

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

Merged
merged 3 commits into from
Dec 6, 2012

Conversation

webmozart
Copy link
Contributor

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -

fabpot added a commit that referenced this pull request Dec 6, 2012
This PR was merged into the 2.1 branch.

Commits
-------

b604eb7 [DoctrineBridge] Improved performance of the EntityType when used with the "query_builder" option
db2ee54 [DoctrineBridge] Improved exception message
99321cb [DoctrineBridge] Fixed: Exception is thrown if the entity class is not known to Doctrine

Discussion
----------

[DoctrineBridge] fixed caching when EntityType is used with the "query_builder" option

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -
@fabpot fabpot merged commit b604eb7 into symfony:2.1 Dec 6, 2012
// It is important to return the same loader for identical queries,
// otherwise the caching mechanism in DoctrineType does not work
// (which expects identical loaders for the cache to work)
$hash = md5($queryBuilder->getQuery()->getDQL());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is wrong. You can have the same DQL with different parameters and different query hints

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reference, here is the way Doctrine computes a cache key for the result cache: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query.php#L596

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i use the following in a subscriber which is used inside a collection (in a form):

            'query_builder' => function(EntityRepository $er) use ($data) {
                return $er->createQueryBuilder('pac')->where('pac.bookingAppointment = :bookingAppointment')->setParameter('bookingAppointment', $data);
            }

since sf 2.1.5 is something wrong with the used closure.. when i call it twice and $data has changed, i get the same result..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the PR has been reverted in the 2.1 branch

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok.. sorry.. so i am looking forward to 2.1.7 :)

@dupuchba
Copy link
Contributor

I use the entity field type to generate 2 dynamically choice list and I think I am diving into what @stof is talking about as the 2 choice list are the same which is not right...

'query_builder' => function (EntityRepository $repository) use ($data) {
    $qb = $repository->createQueryBuilder('p');
    $qb->select(array('DISTINCT p', 'i'))
          ->from('PiggyBoxShopBundle:Product', 'p')
        ->leftJoin('p.menuItems', 'i')
        ->where('(p.shop=?1 AND i.id=?2)')
        ->setParameters(array(1 => $data->getMenu()->getShop()->getId(), 2 => 44));

    return $qb;
}

The two parameters are dynamic and the the choiceList which is generate is the same. I am completely lost...

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

Successfully merging this pull request may close these issues.

7 participants
0