Hi, >First of all I think there shouldn't be just one single place in the >repository where all index configuration should go.
Hm, how would the query engine detect what indexes are available? I think keeping the index configuration at one place is the most simple solution, and I don't currently understand what problems that could cause... If it does cause problems, maybe index config could be stored in two places (near the data, and additionally at a central place) but I'm not sure. >Instead I'd allow a custom indexes to be defined by adding something >like an oak:indexed mixin type and an associated oak:indexes child >node to any node in the repository. In order to find out what indexes exist, the query engine would have to run a query? I would say, that's a bit problematic. >For example, the following >code would define an additional jcr:created property index under >/articles: I think we should define a utility to manage indexes, on top of the JCR API. >Creating such an index node would trigger automatic indexing of the >Subtree I agree that index configuration should be normal nodes, and that adding such nodes should create the index. >either directly in a commit hook or as a delayed background >processing job. Yes. Sometimes it's also a good idea to wait creating the index, so that if a second index is added, the content only has to be traversed once (and not once for every index). Regards, Thomas
