Closed ghenzler closed 1 month ago
As quick test I created the following groovy script as an alternative to detect if a index for node type rep:ACL
exists:
String checkIndexExplainQuery = "EXPLAIN SELECT * FROM [rep:ACL] AS s WHERE ISDESCENDANTNODE([/etc])";
def query = session.getWorkspace().getQueryManager().createQuery(checkIndexExplainQuery, javax.jcr.query.Query.JCR_SQL2);
def plan = query.execute().getRows().nextRow().getValues()[0]
boolean indexExists = (plan =~ "(?ms).*indexDefinition:.*luceneQuery:.*jcr:primaryType:rep:ACL.*")
println "Index for node type rep:ACL exists: ${indexExists}\n"
println "Execution Plan:\n " + plan
Pro:
/oak:index
(in the SDK it's visible, in the CS by default /oak:index
has a deny for everyone in the ACL)rep:ACL
, we don't hard-code the name /oak:index/repACL-custom-2
at some point the index path would not be hard-coded anymoreCon:
Wouldn't a EXPLAIN MEASURE
be more stable with regards to the return value (just evaluating the double value representing the cost)?
If it is above a certain threshold we can derive from that a better index than the traversal fallback one does not exist.
In AEMaaCS there is currently the issue that even though the oak index
/oak:index/repACL-custom-1
is installed, QueryHelper [1] takes the wrong query for ACEs instead of ACLs, and for our case we are above the 100,000 query limit with that. [2] should really give access to/oak:index/repACL-custom-1
, butsession.nodeExists(OAK_INDEX_PATH_REP_ACL)
returns false.[1] https://github.com/Netcentric/accesscontroltool/blob/653d2acba53b5087edf703a25bdcd20f43fd3edf/accesscontroltool-bundle/src/main/java/biz/netcentric/cq/tools/actool/helper/QueryHelper.java#L101-L106 [2] https://github.com/Netcentric/accesscontroltool/blob/653d2acba53b5087edf703a25bdcd20f43fd3edf/accesscontroltool-package/src/main/jcr_root-cloud/apps/netcentric/actool/config/org.apache.sling.jcr.repoinit.RepositoryInitializer~actool.config#L3