Marcel Reutegger wrote:
Christoph Kiehl wrote:
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.
Hm, sounds interesting, but wouldn't this only work with file system
based persistence managers?
no, the index would simply store its files as jcr resource nodes and any
persistence manager must be able to handle binary properties.
Okay ;) I didn't mean technical limitations, more practical limitations.
Jackrabbit already does some optimization. when a binary property is
read it is either copied into memory if it is smaller than 64k or
spooled to a temp file. Further access to that property is then either
directly from memory or a local file.
finally, what is it good for?
- jackrabbit does not need a separate location for the index anymore,
it's all in the repository itself.
- the index will be fully transactional. See issue JCR-204
I like the idea of having a transactional index but I don't think it's a good
idea to read this index from a binary property in a database, because in our
case we've got a fairly large repository where we got index files with a size of
40MB. As far as I understand you have to transfer 40MB to the database on every
index change that gets committed. Am I right?
Cheers,
Christoph
