Ensure the index for rep:ACL is correctly detected

[ghenzler]

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, but session.nodeExists(OAK_INDEX_PATH_REP_ACL) returns false.

[1]

accesscontroltool/accesscontroltool-bundle/src/main/java/biz/netcentric/cq/tools/actool/helper/QueryHelper.java

Lines 101 to 106 in 653d2ac

	boolean indexForRepACLExists = session.nodeExists(OAK_INDEX_PATH_REP_ACL);
	LOG.debug("Index for repACL exists: {}",indexForRepACLExists);
	String queryForAClNodes = indexForRepACLExists ?
	"SELECT * FROM [rep:ACL] WHERE ISDESCENDANTNODE([%s])" :
	"SELECT ace.* FROM [rep:ACE] AS ace WHERE ace.[rep:principalName] IS NOT NULL AND ISDESCENDANTNODE(ace, [%s])";
	LOG.debug("Query to obtain all ACLs: {}", queryForAClNodes);

[2]

accesscontroltool/accesscontroltool-package/src/main/jcr_root-cloud/apps/netcentric/actool/config/org.apache.sling.jcr.repoinit.RepositoryInitializer~actool.config

Line 3 in 653d2ac

allow jcr:all on /

[ghenzler]

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:

• This approach does not require read access to /oak:index (in the SDK it's visible, in the CS by default /oak:index has a deny for everyone in the ACL)
• For projects that do for some reason not like to use accesscontroltool-oakindex-package directly but define their own index for rep:ACL, we don't hard-code the name
• Also if we have to create a new version /oak:index/repACL-custom-2 at some point the index path would not be hard-coded anymore

Con:

• The regex on the explain query might be brittle if oak chooses to change that string format at some point (the current regex is quite specific, we could also make it more open)

[kwin]

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.