Add endpoint that uses plone.volto block_types indexer (wip)
#1789
Conversation
|
@jonaspiterek thanks for creating this Pull Request and helping to improve Plone! TL;DR: Finish pushing changes, pass all other checks, then paste a comment: To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically. Happy hacking! |
✅ Deploy Preview for plone-restapi ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| for blocktype in blocktypes: | ||
| brains = catalog.searchResults(block_types=blocktype) |
There was a problem hiding this comment.
I am sure this can be optimized to one query with removal of the for loop.
| result[blocktype] = Counter() | ||
|
|
||
| for brain in brains: | ||
| obj = brain.getObject() |
There was a problem hiding this comment.
The above query could ask the object_provides index for the (marker) interface of the volto.blocks behavior. This would save several an object wake ups.
There was a problem hiding this comment.
I just tried the object_provides index for the marker interface of the volto.blocks behavior like so: brains = catalog(object_provides=IBlocks.__identifier__) which returns brains just like the block_types index. And so I am asking my self: Doesn't this make the block_types index completely unnecessary? Because from the brains I get the object and from there I get the block values.
/cc @davisagli
There was a problem hiding this comment.
@jonaspiterek You can do that but then you end up loading the full object for all the content items that have blocks, and loading the full object is slower than loading the metadata that is stored as part of the catalog. The block_types index exists for the use case where you want to find all the items that have a particular type of block, without actually loading the full objects.
Also the block_types index properly finds blocks that are nested inside other blocks, which your code doesn't do yet.
There was a problem hiding this comment.
@jonaspiterek Btw if you just want to find out how many items have each type of block, you can also get that efficiently from the index like this (if I recall correctly): api.portal.get_tool("portal_catalog").Indexes["block_types"].uniqueValues(withLengths=1)
There was a problem hiding this comment.
@jonaspiterek Is there a compelling reason to add a new service for this? It should be possible to query the block_types index using the existing @querystring-search service (we might need to add a criterion for it in the querystring registry settings)
|
@davisagli no there is no particular reason for this to be an extra service. I can take a look on how to do that via the @querystring-search service if an extra service for the indexer is not wanted. |
ToDo