which is the fastest and better way to find out all the "stepitem" nodes from the following structure? Currently, I am using Querybuilder to list down all the step-item node below the page, but is it the fastest way or list children method of Resource Api is fastest.
Solved! Go to Solution.
Views
Replies
Total Likes
The query is not always faster. Your query very likely searches the index with the wildcard filter "stepsitem__%" (should not be that expensive) and finds ALL nodes with that name, performs a path lookup in the repo (unless the path is also part of that index), and then filters the result according to ACL etc. Depending on the amount of "stepsitem_%" nodes in the repo, your query might load thousands of potential hits which are then eliminated by the path filter. The runtime performance might vary.
If you iterate through a few hundreds nodes (which is very likely the case if you just search the nodes below a single cq:pageContent node), the iteration is probably much faster, because it does less IO.
You should benchmark it, but then use a timer with a nanosecond resolution, miliseconds is probably not fine enough.
Jörg
Views
Replies
Total Likes
hi
You can use the node iterator or can be refactored using Sling API or third method is slingquery .
The Sling and AEM API both do the same thing with far less code and without any exceptions.
The AEM API has the added benefit that the developer doesn’t need to know about the inner structure of what a property is named or where it’s saved. If the property would be stored in the property ‘title’ in the next version, none of your code would need to change!
My personal guideline is to use the higher-level API’s when you can. Only when you need a feature that isn’t available higher up, should you switch to the lower-level API.
thnkz
JCR Queries are always faster becuase they uses index unlike Sling API and Sling Query
you can use SQL2 query to achieve same
e.g.
SELECT * FROM [nt:unstructured] AS node
WHERE ISDESCENDANTNODE(node, "/content/site/page")
AND NAME() like "stepsitem_%"
Views
Replies
Total Likes
The query is not always faster. Your query very likely searches the index with the wildcard filter "stepsitem__%" (should not be that expensive) and finds ALL nodes with that name, performs a path lookup in the repo (unless the path is also part of that index), and then filters the result according to ACL etc. Depending on the amount of "stepsitem_%" nodes in the repo, your query might load thousands of potential hits which are then eliminated by the path filter. The runtime performance might vary.
If you iterate through a few hundreds nodes (which is very likely the case if you just search the nodes below a single cq:pageContent node), the iteration is probably much faster, because it does less IO.
You should benchmark it, but then use a timer with a nanosecond resolution, miliseconds is probably not fine enough.
Jörg
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies