Hi, On Wed, Jan 21, 2015 at 6:29 AM, Davide Giannella <[email protected]> wrote: > Good afternoon, > > with an application that makes use of oak, we hard-coded index > definitions during repository initialisation as we had to achieve the > following requirements during repository initialisation/start-up/upgrade
So to put this in context, you want to define certain behaviours when you install content via a filevault package. the package installer should obey the different import modes: REPLACE, MERGE, UPDATE [2] > - if the index is there and nothing changed nothing should happen on the > index node. if the index is where? in the package or in the repository? how would the package installer find this out? or do you mean index definition? > - if the current index definition has type=disabled the InitialContent > won't touch the existing one > > - if the index definition has changed, we apply the new definition and > automatically issue a re-index > > - if the index definition is not there, we apply the new one and issue a > re-index well, from the package installers POV, it just writes the new index definition into the repository. I don't think it should know about the special semantics here. The repository should be smart enough to figure out, if the definition changed or not. > As the index definition in oak are defined with a proper node type > (oak:QueryIndexDefinition) we thought it would be a good idea to enhance > the current JackrabbitVaultPackaging[0] to consider this special use > case. Something link what we currently do for the rep:User[1] (I guess). what exactly do we need to change? regards, toby > > 0) http://jackrabbit.apache.org/filevault/overview.html > 1) http://goo.gl/38B7MQ (DocViewSAXImporter L636) [2] https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/api/ImportMode.java
