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
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
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 atle.pra...@gmail.com
I looked over the
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
2010/6/23 Atle Prange atle.pra...@gmail.com
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
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 atle.pra...@gmail.com
Hm, i'll have to fix that...
Any thoughts on a Trie implementation? Would it be able to compete?
I have no idea
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 atle.pra...@gmail.com
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
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
matt...@neotechnology.com wrote:
I think the lucene test is flawed since it never returns any results in
lookup method. That's why it's so
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
9 matches
Mail list logo
