[ic] Modifying the "more" paging system

[Daniel Browning]

* Ron Phipps <rphipps at reliant-solutions.com> [2005-02-11 18:28]:
> Hello,
> 
> The goal of this modification is to present links to both the user and
> search engine where they can easily come back to a spot in a search
> without using cached search results and it will clean up the URL
> (removes the SCAN=xxxxxxxxxxxxxxxxxxxxxxxxxxxx).  This is useful with
> the results after page 1.
> 
> I'm going to do something similar to the ActionMap outlined here:
> 
> http://www.icdevgroup.org/pipermail/interchange-users/2002-September/026
> 698.html
> 
> On my results page I use the query tag to bring up a list of products
> specific to a category.  My plan is to pass a value through the
> ActionMap to the fm (mv_first_match) parameter of the query to display
> the correct "page" of results.
> 
> I noticed that I will need to build my own [more] type tag to handle
> displaying the correct page links so that they will go through the
> ActionMap as well.
> 
> Does anyone see any drawbacks to this method?  Any gotchas to watch out
> for? I will be bypassing the search cache, so for each page there will
> be a new hit to the database, but I don't see anyway around this.  Would
> I get better performance if I did not use the "fm" parameter and instead
> passed values to a LIMIT statement in the query?
> 
> Thanks for your input!
> -Ron

[Responding to old thread] [Copying Ron directly too]

Ron,

I think you've got a great idea.  The current interchange [more] features are
great, but I think they could do with several neat enhancements (I have toyed
around with it some).

You could implement a search-specific URL with the existing [more]
functionality without much difficulty, but I think the best benefits come from
switching to an all-SQL more system.

The most significant performance boost, in my opinion, would be changing from
storing all of the search results on the hard drive to using SQL queries to get
just the values you need.  

The easiest way to do that is with LIMIT/OFFSET, or cursors.  However,
the limit/offset idea is not implemented the same way (or at all) in various
datbases.  Ditto with cursors, which are not even supported in any DBD modules
that I'm aware of.

So, the only other way to do it is with an additonal where clause.  It's even
slightly faster than limit/offset.  However, selecting which field to use and
how to use it is difficult.  I don't see how it could ever be made into a
general-purpose tool like the current [more].  However, as long as it was
easy to customize and drop-in, then it would be a great performance enhancement
for the important searches.

-- 
Daniel Browning <db at kavod.com> - Kavod Technologies.  Random Fortune:
What if everything is an illusion and nothing exists?  In that case, I
definitely overpaid for my carpet.
		-- Woody Allen, "Without Feathers"