Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of mueller@adobe.com designates
 64.18.1.35 as permitted sender)
From: Thomas Mueller <mueller@adobe.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Date: Thu, 20 Sep 2012 14:10:39 +0100
Subject: Re: On custom index configuration
Thread-Topic: On custom index configuration
Thread-Index: Ac2XMVJ/tYtC8eIsRxa5pKhsf87aPw==
Message-ID: <CC80E0A0.342FA%mueller@adobe.com>
In-Reply-To: <BE33F866-D178-47EB-990F-A19B7D1EFD0F@pooteeweet.org>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.3.120616
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

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:

   /long/path/deep/in/repository

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.

Regards,
Thomas


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,
>>=20
>> On 19/set/2012, at 22:47, Lukas Kahwe Smith wrote:
>>=20
>>> Hi,
>>>=20
>>> 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)?
>>=20
>> 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:
>>=20
>>     /path/to/somewhere [jcr:mixinTypes =3D oak:indexed]
>>           /oak:indexes
>>               /solr [jcr:primaryType =3D oak:solrIndex, oak:nodeType =3D
>>nt:file, url =3D ...]
>>                   /:index { invisible index content }
>>=20
>> 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
>mls@pooteeweet.org
>
>
>