-
-
Notifications
You must be signed in to change notification settings - Fork 539
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
Entries Fieldtype: Empty field triggers queries across all collections instead of configured scope #11152
Comments
You're right it's an issue. I've thought about having a fake query builder for instances like these where we know there will be zero results. Since we know your field is empty, there's zero reason for us to perform a query at all. The only reason we do is so you consistently get a query builder instance when using the field on the frontend. |
Thanks for the clarification about the fake query builder. I have a follow-up question regarding Stache behavior: Since Stache watches file modifications and builds indexes, could this empty field issue be causing unnecessary full index regeneration on initial page load after cache clear when page contains empty field? Specifically, I'm concerned that when the system queries ALL collections (due to empty field), it might trigger Stache to:
This is particularly critical for our production site with approximately 4-5 thousand entries. I'm observing significant performance impact when opening a page with such field, as it seems to cause complete index regeneration instead of selective updates. What's also puzzling is that running 'php please stache:warm' doesn't seem to resolve this issue. Shouldn't this CLI command prepare all necessary indexes upfront and prevent such regeneration on page load? Is this assumption correct about the indexing behavior? If so, would the proposed fake query builder solution prevent this excessive Stache indexing, and why doesn't the warm command help in this case? |
Yes. Any fields involved in the query would cause its index to be generated if it isn't already.
Not every field has an index generated in here. Just known ones like slug, uri, title, etc. You can add more in https://statamic.dev/stache#configuring-additional-indexes
The idea would be that a query doesn't actually happen, so yes it should bypass any actual work. |
No, at the moment they are across all collections, but they could probably be made more granular. |
Thank you for all the detailed explanations! This really helps to understand the Stache behavior better. Since both issues (empty field queries and collection-wide indexing) can significantly impact performance on larger sites, is there any timeline for implementing these improvements? Specifically:
Would be great to know if these are planned for any upcoming releases. |
Nothing is planned yet since both issues were only brought up today. 😄 |
I'd like to ask one more question regarding Stache index generation in Statamic. |
Yes |
Thank you for the explanations, I'll be waiting for updates |
Hi, I also experience such problems on my projects, please tell me when to wait for the update ? |
@jasonvarga Hi, are there any updates on this issue? |
@chprof #11184 |
Bug description
When using fieldtype entries with an empty field value, the system queries ALL collections instead of limiting the scope to the configured collection.
Current behavior:
Expected behavior:
Queries should be limited to the configured collection scope even when the field is empty.
Key Question:
Does this "empty field" scenario trigger a full reindexing process across all collections in the flat-file system? If so, what are the performance implications and recommended approaches to handle this?
Looking forward to your insights on this behavior.
Thanks, Yuri
How to reproduce
Logs
No response
Environment
Installation
Fresh statamic/statamic site via CLI
Additional details
No response
The text was updated successfully, but these errors were encountered: