Well actually, I think it could be done, at least in MySQL. The limit clause
in MySQL can take one or two parameters, if the one is used it tells MySQL
to get the n first results. If two parameters are used, the first parameters
is an offset (i.e. give me results starting at row n) and the second is the
number of rows we want.

So it should be possible to create a search that implements a
"getNextNumRows()" or so ... It will probably not be easy to this in a
generic way that supports all types of stores but my guess is that it can be
done.

But I don't know if I'm the right person to answer this question as the time
I have spent looking at the Slide source code is only around 10 hours :-)

Regards,
Pontus

> -----Original Message-----
> From: Carlos Villegas [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 17, 2005 5:06 PM
> To: Slide Users Mailing List
> Subject: Re: AW: Slide search performance issues
> 
> 
> One thing I noticed when implementing a search GUI, was that after 
> sending the query it will wait until the server responded 
> with all the 
> results. I wanted to get results as they are found, so they get 
> displayed in the GUI one by one or in chunks and have a 
> button to abort 
> the query in the middle. I had no indexing at all for search and even 
> though queries may take a long time, providing immediate user 
> feedback 
> will make things acceptable. I was using the slide client. I 
> think not 
> only the server has to be able to send answers little by 
> little but the 
> client also has to handle it and provide the results as they arrive.
> With this in place, implementing a limit it just a matter of 
> stoping at 
> the right place and can be done at the client side. But it's probably 
> more complicated than only adding a limit feature.
> 
> Carlos
> 
> Daniel Florey wrote:
> > My favourite approach concerning this issue would be to 
> implement the
> > MS-Exchange extension that adds the ability to specify to 
> limit the result
> > set by specifying ranges of results.
> > This is described at the MS WebDAV pages as far as I 
> remember. But it is not
> > that easy to implement that on server side. But in fact 
> would lead a big
> > step towards Exchange compatibility...
> > I know that everybody hates MS to extend the standards, but 
> in the area of
> > WebDAV they've added some useful bits. So why not adopt it?
> > Some ranges could be mapped to sql commands by retrieving 
> only the first
> > rows, others could at least be filtered at java result set 
> level. Any ideas?
> > 
> > Cheers,
> > Daniel
> > 
> > 
> >>-----Urspr�ngliche Nachricht-----
> >>Von: [EMAIL PROTECTED]
> >>[mailto:[EMAIL PROTECTED]
> .apache.org]
> >>Im Auftrag von Pontus Strand
> >>Gesendet: Montag, 17. Januar 2005 08:22
> >>An: 'Slide Users Mailing List'
> >>Betreff: RE: Slide search performance issues
> >>
> >>Ok, found the reason to why the query below didn't work, I 
> had failed to
> >>include a "group by"-clause.
> >>
> >>However, that doen't solve the problem. If I get lots of 
> hits when doing a
> >>search it still takes a long time to execute. What I would 
> like to do is
> >>to
> >>move the limititation from the Slide server to the 
> DB-server (where it
> >>really belong). As I understand it the keyword "limit" isn't part of
> >>SQL-standard (Orcale for one doen't implement it) so I 
> guess that this is
> >>difficult do in generic terms. This is, however, important 
> for us as we
> >>need
> >>the performance so which class/classes would I have to 
> override in order
> >>to
> >>modify the behaviour of the search method? Is this 
> recommended at all? Or
> >>should we try to limit the client so we can't do to wide searches?
> >>
> >>/Pontus
> >>
> >>
> >>>-----Original Message-----
> >>>From: Pontus Strand [mailto:[EMAIL PROTECTED]
> >>>Sent: Friday, January 14, 2005 2:51 PM
> >>>To: 'Slide Users Mailing List'
> >>>Subject: RE: Slide search performance issues
> >>>
> >>>
> >>>A quick follow-up, when working with large number of files
> >>>the number of
> >>>hits when doing a search could be large. As I understand it,
> >>>it is possible
> >>>to limit the number of responses by using the DAV:limit XML
> >>>element from the
> >>>DASL specification. However, the specification also states
> >>>that the server
> >>>may disregard the requested limit. So my questions are: Does
> >>>Slide support
> >>>DAV:limit? And will it work when using the
> >>>"use-rdbms-expression-factory"
> >>>parameter? And, finally, am I using correct syntax in the
> >>>example below?
> >>>
> >>><D:searchrequest xmlns:D =\"DAV:\">
> >>>  <D:basicsearch>
> >>>    <D:select>
> >>>      <D:allprop/>
> >>>    </D:select>
> >>>    <D:from>
> >>>      <D:scope>
> >>>        <D:href></D:href>
> >>>      </D:scope>
> >>>    </D:from>
> >>>    <D:where>
> >>>      <D:and>
> >>>        <D:eq><D:prop><D:fileextension/></D:prop>
> >>>        <D:literal>xml</D:literal></D:eq>
> >>>      </D:and>
> >>>    </D:where>
> >>>    <D:limit>
> >>>      <D:nresults>
> >>>      10
> >>>      </D:nresults>
> >>>    </D:limit>
> >>>  </D:basicsearch>
> >>></D:searchrequest>
> >>>
> >>>The reason for my questions is that I can't get it to work
> >>>and I can't find
> >>>any references to this. Is there perhaps another way to limit
> >>>the number of
> >>>search hits?
> >>>
> >>>Regards,
> >>>Pontus
> >>>
> >>>-----------------------------------------------------------
> ----------
> >>>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]
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > 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]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to