jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: On custom index configuration
Date Thu, 20 Sep 2012 13:10:39 GMT

It is problematic to fix the configuration if you don't know where to
look, if the configuration can be basically anywhere in the repository.
Let's say there are special Lucene indexes configured at:


And if you want to switch to another query engine (let's say MongoDB), how
can you do that, given you don't know there is an index configured?

I guess it's simpler to administrate indexes if the configuration is
stored, or at least linked, at a central place.


On 9/20/12 2:48 PM, "Lukas Kahwe Smith" <mls@pooteeweet.org> wrote:

>On Sep 20, 2012, at 2:45 PM, Tommaso Teofili <teofili@adobe.com> wrote:
>> Hi all,
>> On 19/set/2012, at 22:47, Lukas Kahwe Smith wrote:
>>> Hi,
>>> Just wanted to bring up how this all relates to custom index solutions
>>>(like Solr/ES). Isnt there a risk that by making it possible to attach
>>>such configuration to nodes, that it would encourage applications that
>>>make it close to impossible to switch to Solr/ES to benefit from their
>>>features (especially improved scalability in clustered setups)?
>> Why do you think so? Actually I'm working on such an integration (w/
>>Solr) and it doesn't sound that bad, on the contrary, as far as I
>>understand Jukka's proposal, it should be easier as you could add
>>something like:
>>     /path/to/somewhere [jcr:mixinTypes = oak:indexed]
>>           /oak:indexes
>>               /solr [jcr:primaryType = oak:solrIndex, oak:nodeType =
>>nt:file, url = ...]
>>                   /:index { invisible index content }
>> along with a CommitHook and a QueryIndex specific implementations.
>it just seemed to me like it would encourage a proliferation of very
>specialized handlers which bind the content to the specific indexer.
>i think it would be ideal if in most cases switching the internal lucene
>solution for Solr/ES should work without having to touch anything beyond
>a few configs (which can of course be stored inside the repo). The
>example you are showing above seems to go into the opposite direction.
>Lukas Kahwe Smith

View raw message