On Sep 20, 2012, at 2:45 PM, Tommaso Teofili <[email protected]> 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.
regards,
Lukas Kahwe Smith
[email protected]
