Hi, >At query time, when it knows the main path constraint used in the >query, it can walk down that path to detect which indexes are >available and useful for resolving the query.
I guess we could make it work. It would make the query engine a bit more complex, and some of the queries would get a little bit slower (because a few more nodes would need to be read as they might contain index configs), but it's possible as far as I see. The configuration of 'global' indexes (that affect the whole repository, such as the jcr:uuid index, the fulltext index) would still need to be stored at a fixed location (for example at the root node). One problem is if the index config is stored at the wrong place, or if the query doesn't include the path restriction. For example if a config of a global index is stored under "/content" instead of "/", and then if the query doesn't explicitly use "/content", the index wouldn't be picked up. So there are a few things that could go wrong. Storing the index configs at a fixed location is still what I would prefer, because it is a very simple solution, and I still don't see very big advantages to store the config near the content. Regards, Thomas
