On Wed, Feb 17, 2010 at 4:47 PM, Alexander Klimetschek <[email protected]> wrote: > On Wed, Feb 17, 2010 at 16:22, Jukka Zitting <[email protected]> wrote: >> What would we need to do to achieve this, and would the result be >> worth the effort?
>From the top of my head we should also closely think about the changed way in a clustered environment, as now, all nodes in a cluster have their own cluster. Also still, I really doubt about whether it is feasible to implement in a performant way Regards Ard > > Some ideas from the top of my head: > > A basic problem is that the search index would include itself, so > maybe one has to have a separate node tree under > /jcr:system/searchIndex that is not covered by the search, observation > and/or other things that could lead to "circular" problems. Or > performance issues, if the involved binaries are touched very often > and also changed outside of sessions, eg. when a text extractor ran > later. > > One "useful" feature of the search index on the file system is that if > it gets corrupted somehow, you can delete it and it will be re-built > upon startup. This should also work if it lies inside the content. > Thus a broken search index must not break repository startup or it > must be possible to delete it with a tool w/o requiring a full > repository start. > > Regards, > Alex > > -- > Alexander Klimetschek > [email protected] >
