Hi Tommaso, My knowledge of Solr is not anything like as deep as yours. I would like to check what I know is correct, to avoid sharing the wrong information.
In [1] the first test does not commit and is backed by a RAMDirectory shared by the reader and writer. Does that mean that Lucene natively only supports NRT inside a single JVM, and if the JVM dies anything not hard committed (if the RAMDirectory was backed by a FileDirectory) would be lost or is recovery of soft commits and pre-soft commits now handled automatically in Lucene4. Last time I looked at the source code was shortly before Lucene 4.0 was released which was some years back. Best Regards Ian On 24 July 2015 at 09:49, Tommaso Teofili <tommaso.teof...@gmail.com> wrote: > I think the proposal makes sense; in the end NRT is something that is > inherently supported by Lucene (see an example [1]) and, as Ian mentioned, > something that has been similarly implemented in ES and Solr. > > I think it'd be possible though to make use of Lucene's NRT capability by > changing a bit the code that creates an IndexReader [2] to use > DirectoryReader#open(IndexWriter,boolean) [3]. > > My 2 cents, > Tommaso > > [1] : https://gist.github.com/mocobeta/4640263 > [2] : > > https://github.com/apache/jackrabbit-oak/blob/trunk/oak-lucene/src/main/java/org/apache/jackrabbit/oak/plugins/index/lucene/IndexNode.java#L94 > [3] : > > https://lucene.apache.org/core/4_7_0/core/org/apache/lucene/index/DirectoryReader.html#open(org.apache.lucene.index.IndexWriter > , > boolean) > > 2015-07-24 10:23 GMT+02:00 Michael Marth <mma...@adobe.com>: > > > > > >The reason I preferred using Lucene is that current > > >property index only support single condition evaluation. > > > > I did not know this. That’s a strong argument in favour of using Lucene. > > >
