> -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Freitag, 23. Januar 2004 14:39 > To: Slide Developers Mailing List > Subject: Re: Integrate Indexstore and SEARCH (was Indexing store) > > ...
> >> > >>My idea was all those indexers *might* update a *single* > >>index and thus > >>there might be single search without merging. > > > > > > Yes! So we should have *one* indexer (or an indexer > framework) in which > > you can plugin a jpg indexer, a pdf indexer, ... > > > > If all that indexed data is written to the same store as the > > NodeRevisionDescriptors (say in RDBMS), you can write a > search engine > > that executes a mixed (prop and content search) at once, no merge. > > OK, so we were agreeing all the time, right? :-) It always depends, where you set your focus. If you need performance, try all to put in one system. If you need the functionality of a high sophisticated indexer, that for any reason cannot be integrated with your RDBMS, make two searchers and merge. The architecture of index / search should allow both. > > > A question to the Lucene experts: Where does Lucene writes > its index? > > Is it possible to store in RDBMS? > > I was wondering about this as well. Another real problem > might be when > to index and transactionality. If we index as soon as we write a > resource and then decide to rollback at some point it might > be a problem > if we updated a main index. It might be necessary to create a > new index > and merge it with the existing one on commit. > Ah ja, transactions :-(. The indexer must be a store and must take part at the two phase commit. How can this be achieved with Lucene? No big problem if Lucene can write its index to RDBMS... Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
