> -----Original Message----- > From: Nick Reddel [mailto:[EMAIL PROTECTED] > Sent: Freitag, 23. Januar 2004 13:31 > To: 'Slide Developers Mailing List' > Subject: Re: Integrate Indexstore and SEARCH (was Indexing store) > > > > > Hi Christophe > > It looks like our solutions should fit together - I went ahead and did > the indexing and search implementations, on the meta-data, while you > went with the higher-level api, mostly focussed on the content. > > Some things: > -- For some applications (e.g. mine), it's critical that > indexing occur > within the transaction [i.e. SEARCH needs to reflect the exact store > state). A flag to indicate synchronous indexing?
Good point! Do you think its enough when the indexer takes part at the two phase commit? > > -- Property typing is a must, I think. At least to be able to pull out > meaningful date-ordering, etc. I've got two (one rdbms, one non) > solutions in mind - I'll run them by you. > > -- If we're serious about (possible) different indexers for a > combination of different stores, doesn't it make more sense to define > the indexers in a separate block (from the stores) in Domain.xml and > allow use references from the stores to the indexers? > Sounds good. > There are already two mechanisms in place to control which > indexer does > what, though: the search language used, and the fact that any > BasicQuery > implementation "falls back" to another if it can't handle any part of > the search request. So, here's some use cases/config examples: > > (1) dav:basicsearch on store highMetaStore uses by preference > RDBMSQuery > (searches the indexes generated by RDBMSIndexer). > If RDBMSIndex can't handle any part of the query (i.e. a LIKE if we're > not using full-text indexes in the RDBMS), it falls through to > LuceneQuery >> LuceneIndexer > If THAT can't (although we're unlikely to get here), fall through to > BasicQuery This would be the solution with the least changes at the current implementation. To stay at the use case prop => RDBMS, content => fileSystem/Lucene, the search engine for RDBMS would implement the expressions for all property operators, but not <contains>. This is done by the next search engine using Lucene. But its a little bit a hack :-) > > --- on highContentStore, it uses by preference LuceneQuery > > ---- on both stores, it uses by preference LuceneQuery (sum of > priorities) > > (2) slide:metasearch ONLY uses RDBMSQuery, > slide:contentsearch ONLY uses > LuceneQuery > I think currently we are far away from a different searchlanguage than basicsearch. Regards, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
