improve checklist_items performance#9849
Conversation
✅ Feature branch deployment ready!
|
usu
force-pushed
the
fix/checklist-item-performance
branch
from
ee3480c to
1abc182
Compare
|
I had AI try a slightly different approach. I couldn't test and review it yet. |
|
hm, it seems we broke the feature branch deployment with postgres 18..., sorry for that. |
…list-item-performance
|
Looks very promising: dev: |
| try { | ||
| $iri = $this->iriConverter->getIriFromResource($entity, UrlGeneratorInterface::ABS_PATH, $operation); | ||
| } catch (NoSuchPropertyException $e) { // @phpstan-ignore catch.neverThrown | ||
| // NoSuchPropertyException is thrown for cases where uri parameters cannot determined automatically |
There was a problem hiding this comment.
For later:
would be nicer if we could check that case earlier instead of using exceptions for the control flow.
| try { | ||
| $oldIri = $this->iriConverter->getIriFromResource($oldEntity, UrlGeneratorInterface::ABS_PATH, $operation); | ||
| } catch (NoSuchPropertyException $e) { // @phpstan-ignore catch.neverThrown | ||
| // NoSuchPropertyException is thrown for cases where uri parameters cannot determined automatically |
There was a problem hiding this comment.
For later:
would be nicer if we could check that case earlier instead of using exceptions for the control flow.
There was a problem hiding this comment.
As long as we don't have the custom logic, maybe a test that this endpoint must currently not be cached, because we don't have a purge logic?
2 participants
Fixes #8668
Replaces the query
/api/checklist_items?checklistNodes=%2Fapi%2Fcontent_node%2Fchecklist_nodes%2F{id}%2Fby a dedicated subresoure
/api/content_node/checklist_nodes/{id}/checklist_itemsand disables eager loading for this operation. Given that the number of returned items from this query is rather small (selected checklist items in a specific activity), the additional toll for disabling eager loading is much slower than what is gained by making the initial SQL query fast.
Some more information on what I found out why the original query is slow is documented in #8668.