Hi.
As one of the people who asked about placing indeces into RDBMS, I was primarily interested in just storing index in the RDBMS (basically, storing the structures described on this page http://lucene.apache.org/java/docs/fileformats.html in the relational DB). The main reason is NOT to be able to perform some magic with joining Lucene and 'pure DB query' results (which, actually, IS useful in some curcumstances, but don't really see a problem of doing it in Java after quering DB and Lucene), but rather avoid the cost of reindexing and associated problems in complex enterprise environments.
There no problem joining/intersecting Lucene/DB results in the Java layer apart from performance. Imagine you have 10k results from Lucene and 10k results from the RDB and you only need results 20...40 ordered by 'name' field, ascending (which is the usual case). An sql query with join and limit/offset would be much faster than joining 20k entries in Java.
Yet another advantage of storing index in the DB is its 'managability' and 'debugabiliy' (nice word!). Through there is Luke, etc, administrators in big companies do not want to learn many new tools and having smth already familiar to deal with can sometimes be a good argument in favor of product adoption. (BTW, Compass, as Aleksei mentioned, can be the answer to this prayer - meant to check it out long time ago, but haven't got around to it yet. Also, it seems like the project is half-dead. I wonder if it's true...)
Compass is a lively and active project, we successfully use it in production. Bye. /lexi --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
