Messages per Month
| From | Sent On | Attachments |
|---|---|---|
| Jukka Zitting | Feb 17, 2010 7:22 am | |
| Alexander Klimetschek | Feb 17, 2010 7:46 am | |
| Ard Schrijvers | Feb 17, 2010 7:50 am | |
| Thomas Müller | Feb 17, 2010 7:59 am | |
| Jukka Zitting | Feb 17, 2010 8:39 am | |
| Adam Foltzer | Feb 17, 2010 5:39 pm | |
| Thomas Müller | Feb 17, 2010 11:39 pm | |
| Ard Schrijvers | Feb 18, 2010 1:23 am | |
| Bertrand Delacretaz | Feb 18, 2010 1:48 am | |
| Jukka Zitting | Feb 18, 2010 1:57 am | |
| Thomas Müller | Feb 18, 2010 2:23 am | |
| Alexander Klimetschek | Feb 18, 2010 4:18 am | |
| Alexander Klimetschek | Feb 18, 2010 4:21 am | |
| Thomas Müller | Feb 18, 2010 5:11 am | |
| Jukka Zitting | Feb 18, 2010 5:17 am | |
| Marcel Reutegger | Feb 19, 2010 1:52 am | |
| Ian Boston | Feb 22, 2010 2:14 pm |
| Subject: | [jr3] Search index in content | |
|---|---|---|
| From: | Jukka Zitting (jukk...@gmail.com) | |
| Date: | Feb 17, 2010 7:22:26 am | |
| List: | org.apache.jackrabbit.dev | |
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





