Open chprof opened 1 day ago
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?
could this empty field issue be causing unnecessary full index regeneration
Yes. Any fields involved in the query would cause its index to be generated if it isn't already.
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?
Not every field has an index generated in here. Just known ones like slug, uri, title, etc. You can add more in config/statamic/stache.php
, though.
https://statamic.dev/stache#configuring-additional-indexes
If so, would the proposed fake query builder solution prevent this excessive Stache indexing
The idea would be that a query doesn't actually happen, so yes it should bypass any actual work.
Not every field has an index generated in here. Just known ones like slug, uri, title, etc. You can add more in
config/statamic/stache.php
, though.
Thanks for the explanation. One more clarification about indexing configuration:
I've configured additional indexes in config/statamic/stache.php, but they seem to be created for ALL collections. Is there a way to configure field indexes for specific collections only?
For example, if I have a 'city' field that's only used in 'locations' collection, can I limit its index generation to just that collection instead of indexing this field across all collections?
This would help optimize the indexing process since not all fields are used in every collection.
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. Am I understanding correctly that if there's a link in the navigation to one of the entries from a blog collection that contains 3000 entries, it will trigger index generation for the entire blog collection? In other words, will it generate indexes for all 3000 entries on first page load?
Yes
Thank you for the explanations, I'll be waiting for updates
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