Hi Christoph,
the search index implementation uses a collection of lucene indexes
for performance reasons. To keep track of the indexes in use it
creates a file indexes with the index names.
the file ns_mappings.properties is a mapping of namespaces to index
internal prefixes to save storage space.
finally, the redo.log is required to turn lucene into a transactional
index.
as mentioned before the current search index implementation does not
work on the jackrabbit FileSystem abstraction. The reason is lack of
support for random access on the FileSystemResource which is a
performance killer when lucene is running on top of that.
in the long term I would like to put the index in the repository
itself. but that means that the repository (at least internally) has
to support random access on its binary resources.
regards
marcel
Christoph Kiehl wrote:
I've got a configuration running where I use my MemoryFileSystem,
InMemoryPersistenceManager and a lucene RAMDirectory, but there jr still
creates the following structure in the file system:
./repository
./repository/index
./repository/index/_0
./repository/index/indexes
./repository/index/ns_mappings.properties
./repository/index/redo.log
./version
./version/blobs
./workspaces
./workspaces/default
./workspaces/default/blobs
./workspaces/default/index
./workspaces/default/index/_0
./workspaces/default/index/indexes
./workspaces/default/index/redo.log
./workspaces/default/workspace.xml
./repository.xml
./.lock
