-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Form] Caching resolved $options is dangerous #6456
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
Comments
Actually, the issue is that the QueryBuilder is not cached properly. The DQL string is not the only part that can change, which mean the way the cache key is computed is wrong. It need to depend on the query params, query hints, ORM filters and so on |
@stof are you working on this ? any ETA ? |
@stof Seems to be a lot better by disabling the cache ! Thanks for the hint. |
An easy fix would be the include parameters in the cache key as they are most likely to change. |
That's about what stof Saïd. ----- Reply message ----- At least it would fix this problem. — Reply to this email directly or view it on GitHub. |
I know 😄 I was just suggesting it as a quick fix. |
@stof suggested a better quick fix (reverting) but the real fix should also be quick if anybody has time these days. |
What d'you think? Is it valuable enough for a PR? |
Good start, I would also use other variables mentionned by stof and I would not modify param values. |
Something like that (but with the parameters) would be great, wouldn't it? https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query.php#L639-L649 |
Doctrine actually has multiple cache types, DQL ->SQL is just one of theme. Edit: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/AbstractQuery.php#L782 Maybe its best if we can use the information and cache key generation of Doctrine instead of making something our self? |
IMO, an existing cache-id generation mechanim should be used. |
@sstok We cannot as this cache does not correspond to any Doctrine cache level: it is caching the hydrated results based on the original DQL query, which means it has to take all settings into account whereas each Doctrine cache only uses a few of them (the query cache does not need to take parameters into account for instance as they are not part of the DQL -> SQL conversion, and the result cache does not need to handle DQL specific settings as it works with the SQL). |
+1, I'm hitting this bug as well :/. I
8000
f you're looking for a workaround, you need to find a way to somehow change the DQL between the different uses of this. For example, in one use I order by a Ping Mr @bschussek! :) This is a bug in a security maintenance release, so we should either revert sha: b604eb7 as @stof suggested or perhaps have an opt-in for this feature (some option to turn it on) - and actually fix it on a non-maintenance release. Thanks! |
As a quickfix in your project you can just avoid to use placeholders/parameters in your dql and it'll work (well if you're not using different hints, filters, ...). What do you mean @weaverryan when you say "change the DQL between the different uses of this"? The real issue here is about generating a valid unique cache id for a given query builder, right? |
@bschussek I'm going to revert b604eb7 (any objections?). Another solution should happen in master. |
@fabpot it would be great to open a new issue while reverting so that the optimization don't get lost. |
reverted. |
+1 - I'm hitting on this, too. @gquemener: Comment by @weaverryan describes a workaround so that you get different cache IDs until this bug is fixed: Different DQL = Different cache ID
Instead of "AND 1=1" you could also add something else which does not change the result (e.g. add another meaningless ORDER BY if your DQL does already manages the order for your view). |
@fabpot what about closing this issue & create and enhancement request ? |
@vicb that would help for sure. thanks. |
Do you expect me to do this ? |
+1 from me, too. I filed issue 6787, which as @Tobion says is probably a dup. |
Any updates on this? This bug is a major nuisance. Or at least some way to disable the caching until there is a fix? The workaround suggested by @weaverryan works, but it's a pretty ugly kludge. |
If @fabpot reverted it as indicated in a previous comment, the easy fix its to update sf. |
The commit is reverted, so I think this can be closed? |
In a custom FormType, I have:
The qb is supposed to return a different value according to the value of
$options['type_vehicule_id']
.However due to resolved options being cached by form types, the options would be resolved only once and re-used for the second form. This means that both forms would use the same query builder which is different from what I expect.
@bschussek
/cc @yohannpoli
The text was updated successfully, but these errors were encountered: