Hi, I agree that slide has better ways to answer a query than I suggested. Testing the whole query in the slide context could be an implementation optimized for SEARCH unaware stores, the default implementation if no search engine is configured with the store.
In Tamino we have the metadata stored as XML. Queries searching the metadata only can be translated into one XQuery statement. If there are queries on the content (<contains> in DASL), I assume we have to do a postprocessing. Any other store, that stores metadata and content on different locations will have to merge as well. I think that merging subresultsets might be a common task, so why not offer it in a generic way. My approach is to guarantee that Slide provides DASL, but leave the optimization to the store. Martin -----Original Message----- From: Dirk Verbeeck [mailto:[EMAIL PROTECTED]] Sent: Montag, 14. Januar 2002 01:14 To: Slide Developers List Subject: Re: DASL - integrate basicsearch into slide Hi For your first case, isn't is better to test the whole query at the same time. If you do it that way you only have to retrieve the properties one time. A filesystem store would benefit from this. For a memory store it doesn't matter for speed but you will have no intermediate results. A JDBC store will probably do everything itself. I'll have to have another look at the spec to see what exactly is possible with DASL. What about your Tamino server what kind of queries does it support? and XMLDB (from user mailling list) We probably need to implement your proposal, that way it's very flexible but I still think a complete test on a object is needed. Dirk "Wallmer, Martin" wrote: > > Hi, > > here some very basic ideas for basic search integration: > > * The slide kernel itself is able to perform a basicsearch query by > scanning the structure, building subresult sets and merging them (don't ask > for performance). > * A store specific implementation may perform all or part of the job. > > A highsophisticated store would translate the query into an XQL (or SQL) > statement for example and leave the work to its database engine. > A less intelligent store for example may perform all the compare operations > (equal, lessThan, ...) and deliver sub result sets, the slide kernel then > would merge these sets according to the AND / OR operators in the query. > > A BasicSearchQuery represents the query and is able to deliver a > SearchQueryResult using the execute method. It may serve as a base class for > store specific implementations. It hosts the information about the SELECT, > FROM, WHERE, ORDERBY and LIMIT. It also hold a tree of > BasicSearchExpressions. > > A BasicSearchExpression represents exactly one operator (AND, GT, ...). It > may have the state resolved or unresolved. If it is unresolved, it contains > the BasicSearchExpressions, on which the operation is to be executed. If it > is resolved, it contains a SearchQueryResult, that represents the result set > of this BasicSearchExpression. The state transition from unresolved to > resolved may only happen, when all subsequent BasicSearchExpressions have > the state resolved. > > A store specific implementation of BasicSearchQuery is free how to process > the tree of BasicSearchExpressions and if it resolves the root expression. > However, if the root expression is not resolved at the end of the execute > method, super.execute() must be called to guarantee, that a > SearchQueryResult is produced. > > Any comments? > > Martin Wallmer > Research & Development > Software AG ++49 6151 92 1831 > Uhlandstr. 12 > D 64297 Darmstadt > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
