Adds Statamic\Eloquent\Events\TypeRequested for use in EntryRepository #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a new
TypeRetrievedevent, intended for repositories to emit when types (e.g. entries) are loaded by identifier.It builds off another open PR at the moment.
Notably, this is does not fire via the methods that are indirectly loading entires. I.e.
->whereCollection()as the entries are not being found by identifier.This is part of a wider piece of work I've start to add a fairly large reduction in DB queries to the
statamic/eloquent-driver. The principal is to route as many modules of the system as possible through the repositories so that they may emitting this event.In my own projects, I rebind all the repositories via the container to do this, but it would be useful if the repositories did it themselves - hence the PR.
Utility and performance gain
Once in emitting, you can do an interesting optimisation of
statamic.webroutes. Rather than loading each entry one by one whilst Statamic Values are being augmented, instead, at end of each request you can store into the cache a list of IDs what were requested. Then, when next rendering the page, eager load them into the blink cache.To be clear, this is not simply caching the entries, but rather just their IDs. We gain the luxury of not having to think about cache invalidation.
The rationale is that its typically cheaper to do one DB query for 20 entries than it is to do 20 DB queries.
There are some edge cases:
In both cases the type usage cache isn't up to date, but only for one request. As soon as the page renders again, the exact type usage will be save. In both cases there is still a very high likelyhood that the number of DB queries will be dramatically reduced.
Pseudo code for simplicity below:
Note: the example above is only for entries, but could be expanded to the other types in Statamic, e.g. assets, terms etc.
Intention to implement further
Should this is something that could be merged, I'd be happy to extend this functionality to all the repositories that use
findandfindBy.