Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.218.224 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:from:date:message-id:subject:to:content-type;
        b=mc3BrDrTYlPiSXT+we+w9jZQeQg0rRVnbI4eRdoaRhcNLkFrDr4mXpslOUPSm+RZ9G
         KbI9RnCJfEZx6ce+gjQ3GwcJorndUfJyAkRU9y+btiO0yQS0NMEdV6XjKm7NBGOu96PC
         xgrveIipw3CDSv2xli+X8pOmOSMtCbVhSw0bY=
MIME-Version: 1.0
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Wed, 17 Feb 2010 16:22:49 +0100
Message-ID: <510143ac1002170722g76806f23he522cd7fc05a2499@mail.gmail.com>
Subject: [jr3] Search index in content
To: Jackrabbit Developers <dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Having the search index stored on the normal file system gives us
great performance and avoids having to tweak Lucene too much to suit
our needs. However, the extra storage mechanism adds all sorts of
consistency, backup and transaction complexities.

Especially with things like the data store it should be feasible to
achieve good enough search performance even if the index is stored
inside the repository either as normal (hidden/protected) JCR nodes or
as special lower level constructs that still leverage our standard
persistence mechanism.

What would we need to do to achieve this, and would the result be
worth the effort?

BR,

Jukka Zitting