- 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...
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.
Additionally, where does Tamino fit in here?
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
