Since write operations are confined in a transaction, data is only written
in tx.finish() så that's where neo4j does the invalidation of the searcher.
I.e. assuming multiple write operations are performed in each transaction
searchers need not be invalidated as often, and only when something is
act
Yes, but isn't that what you in practice have to do when using lucene
as an index for values in neo4j? Data could be written all the time,
and then you have to open a new reader every time you do a search, at
least when the index for the value you are searching for has changed.
How is that impleme
I think that calling writer.getReader() and closing it after each lookup
causes it to be slow. Basically only create a new reader/searcher if the
underlying writer has written something since last time you used the
reader/searcher
2010/6/28 Atle Prange
> I looked over the Lucene test. I am no Lu
I looked over the Lucene test. I am no Lucene expert, so when i
finally managed to actually find the documents i indexed, it was so
slow i cannot imagine i am doing things right:
package org.ogrm.test;
import java.io.File;
import java.io.IOException;
import org.apache.lucene.analysis.KeywordAnal
I guess i have to brush the dust of my tree knowledge then...
-atle
On Thu, 2010-06-24 at 09:43 +0200, Mattias Persson wrote:
> 2010/6/23 Atle Prange
>
> > Hm, i'll have to fix that...
> >
> > Any thoughts on a Trie implementation? Would it be able to compete?
> >
> > I have no idea on performa
2010/6/23 Atle Prange
> Hm, i'll have to fix that...
>
> Any thoughts on a Trie implementation? Would it be able to compete?
>
> I have no idea on performance or what would be the best approach. I though
your alphabet-relationship-types approach sounded quite interesting. Or as a
b-tree or some o
Hm, i'll have to fix that...
Any thoughts on a Trie implementation? Would it be able to compete?
atle
On Wed, Jun 23, 2010 at 11:04 AM, Mattias Persson
wrote:
> I think the lucene test is flawed since it never returns any results in
> lookup method. That's why it's so fast :)
>
> 2010/6/22 A
I think the lucene test is flawed since it never returns any results in
lookup method. That's why it's so fast :)
2010/6/22 Atle Prange
> Started a new thread since the old got a bit long, if you want to
> catch up read the thread "The event framework has landed".
>
> Okay, i changed the tests t
Started a new thread since the old got a bit long, if you want to
catch up read the thread "The event framework has landed".
Okay, i changed the tests to reflect a bit more realistic usage.
The tests first inserts 1M entries to create a base of data. After
that it makes reads and writes 1000 entr
9 matches
Mail list logo
