On 6/2/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 6/2/06, Simon Willnauer <[EMAIL PROTECTED]> 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? simon
