On Thu, 5 Jan 2006, Steven Pannell wrote:
Look in the old archive mails and you will find a few people have tried this
out. There is even some code around.
In the 'db' contrib area there are now two implementations of a Lucene
Directory subclass against a database. Not a relational database, but a
database nonetheless, Berkeley DB and Berkeley DB Java Edition.
For more info, see:
https://svn.apache.org/repos/asf/lucene/java/trunk/contrib/db
I have tried this, and to be honest it does not make much sense.
While fitting a Lucene index into the neat little rows and columns of a
relational database makes little sense, depending on your requirements it may
still make sense to protect your indexes with transactions or to get finer
locking control than the one afforded by Lucene's FSDirectory.
For example, I have the need to coordinate index updates with other non Lucene
updates, ie use the same transaction to update the index and to save the data
(text and non-text) elsewhere.
The real problem is performance it just takes too long to keep getting the
index from the database for performing the query.
As with all database issues, performance is to be carefully traded off against
all the other requirements of your application. I find that search performance
is quite acceptable with the Berkeley DB implementations in the 'db' contrib
area.
Andi..
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
