lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Willnauer" <>
Subject Re: GData Server - Lucene storage
Date Fri, 02 Jun 2006 16:56:24 GMT
On 6/2/06, Yonik Seeley <> wrote:
> On 6/2/06, Simon Willnauer <> wrote:
> > So this would happen quiet often due to updates and inserts.
> > Hmm it is more and more a bad idea to use a lucene index as a storage.
> > Rather go straight to a Database.
> Yes, if you need to be able to *instantly* retrieve (but not search)
> updates you just inserted, and you need to support a high volume of
> updates and queries.
> You could also do that in-memory by supporting retrieval by id from
> your "batch" of documents not yet "committed" in Lucene.  Only
> downside is it's volatile.

So that's actually what I expected. You can't have everything with this
approach. I always have to lower one's sights. But I wan't to be prepared to
serv a high volume of inserts and updates. I used lucene a couple of times
with version 1.4 and  concurrent write access hasn't change. I will use the
Berkley DB for Java as the default storage, I still can implement a lucene
based storage if there is enough time. I had a look at the licence of the
sleepycat BerkleyDB for Java dist. and in my opinion it is alright to use
and distribute it with the gdata server.
Are there any experts on licencing? Is it ok for the ASF to use that?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message