Am Freitag, 23. Januar 2004 15:27 schrieb Wallmer, Martin: > > -----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...
I thought that Lucene could use the TxFileStore for handling transactional indexes. If it would be possible to create an index per resource and merge them into the real searchable big index after commit this would be fine. Just brainstorming... Would be no good to copy the whole index to achieve transactionality. Is a real transactional search required or is it only necessary to avoid wrong indexes when a transaction is getting rolled back or the commit fails? > > Martin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
