Hi, I'm not convinced about storing upgrade history as hidden nodes is a good idea. If somebody installs a new version, and you need to keep track of the upgrade, the nodes need to be visible on the jcr layer, otherwise the system needs to be taken offline just to check the upgrade history. Is there any other scenario that I'm not aware of?
I think Chetan's proposal makes sense here, use visible nodes for index setup & friends, wipe everything else clean on reindex. alex On Wed, Sep 24, 2014 at 3:04 PM, Davide Giannella <dav...@apache.org> wrote: > On 24/09/2014 09:44, Chetan Mehrotra wrote: > > On Wed, Sep 24, 2014 at 1:57 PM, Davide Giannella <dav...@apache.org> > wrote: > >> Let's say we want to keep logs of upgrades between the index > >> definitions, I would store these kind of information under a hidden node > >> as well. > > It would be better to store them in proper nodes. With that you can > > access them via std JCR Tooling. The only downside that they would be > > pickedup in observation. > > > > To enable precise deletion of index data nodes in case of reindex we > > can capture those node names in index definition and reindex logic > > then only removes them. Or follow some convention :data and :index for > > storage of index nodes and then remove only those nodes > > > Assuming we want to consider the case, I think that the proper solution > would be one of the following > > * force all the index implementation to use :index. It's the current > case and we'll have to state it somewhere around indexes and commit > hook. We already have as well a constant for that name. > > * force the index implementation to use a specific node type/mixin for > the content node. This will give us more flexibility on the index > implementation side. > > Davide > > >
