Hi, There is one more problem with storing the index config near the content. The index config doesn't just need to be read when running a query, but also when modifying data, in order to update the index data itself. If the index config isn't stored at a central place, then either the index isn't updated, or each time you store anything, all the parent nodes need to be read to pick up index configs.
A variation would be to store the index config at two places (at a central location and near the context). An internal observation handler could synchronize the two. But all that just seems like a lot of trouble to me, for a quite small advantage (just my view). So I suggest we start with storing the index config at a central location, and then if we see a strong need we can still support a different solution. Regards, Thomas On 9/18/12 6:04 PM, "Jukka Zitting" <[email protected]> wrote: >Hi, > >On Tue, Sep 18, 2012 at 5:30 PM, Thomas Mueller <[email protected]> wrote: >>>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? > >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. > >At commit time, it can walk down the affected subtrees to detect which >indexes need to be updated. > >BR, > >Jukka Zitting
