Hi, > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Mittwoch, 21. Januar 2004 13:35 > To: Slide Developers Mailing List > Subject: Re: Integrate Indexstore and SEARCH (was Indexing store) > > > Wallmer, Martin wrote: > > - if we use one implementation for both, it might be necessary > > to replicate data, or content search might not perform well > > Could you explain this a bit more, please. I was not able to > follow the > ongoing discussion in detail...
if you store your properties within RDBMS or Tamino, they are indexed by that system. If you would base the search engine on Lucene (for content AND properties, you would have to write the properties to Lucene as well. > > > Scenario 1: > > Create a resource - the index method creates indexes for > > content and properties using Lucene. > > > > SEARCH for property and content - the search engine for this > > store implements both property and content. It creates the > > calls to Lucene to deliver the resource ids, the resources > > can be loaded and returned in a SearchQueryResult. > > > > Scenario 2: > > Create a resource - the index method creates an index for > > the content, no index for properties. RDBMS does this for > > you. > > > > SEARCH for properties - the property search engine creates > > an SQL statement, which is perfomed by RDBMS. The resource > > ids are returned, load the resources and return as > > SearchQueryResult. > > > > SEARCH for content - same as scenario 1 > > > > SEARCH for property and content - both search engines do their > > part, both SearchQueryResults are merged. > > What about having both properties and content in an RDBMS if > full text > search is supported? As far as I remember, at least Oracle has this > feature. > Absolutely. You could implement a search engine which generates one SQL statement for your mixed (prop and content) searchrequest, no > Additionally, where does Tamino fit in here? > The Tamino search engine currently does not support the <contains> operator, so the <contains> is executed by the generic search. This is the implementation that is checked in slide CVS and works for any store. As Tamino focuses on XML documents, we added the XPATH operator, which allows high performance content search on XML documents. > > > > If we agree to express the SEARCH as XML (<basicsearch> as defined > > by DASL), a lot of the infrastructure is already present. > > +1 from me as the performance overhead should be negligible > compared to > the search itself... > > Oliver > > regards, Martin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
