Bug #129


Metacat Performance: paged Query Returns

Added by Chad Berkley almost 24 years ago. Updated almost 11 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


If a query returns more than n results, then only n results should be shown to
the user at a time. This functionality is similar to a commercial search engine
that only shows the user "results 1-25" then you click a "next 25" button to get
to the next page of results.

Related issues

Is duplicate of Metacat - Bug #147: return partial resultsetsResolvedJivka Bojilova09/22/2000

Is duplicate of Metacat - Bug #2156: Metacat Performance: Send result back to web client in blocksResolvedSaurabh Garg07/13/2005

Actions #1

Updated by Matt Jones almost 24 years ago

  • Bug 147 has been marked as a duplicate of this bug. ***
Actions #2

Updated by Matt Jones almost 23 years ago

Changed milestone for several bugs. Some of these we should consider marking

Actions #3

Updated by Matt Jones over 22 years ago

Moved issues that we do not intend to address during the current release to the
'Postpone' milestone.

Actions #4

Updated by Saurabh Garg almost 19 years ago

  • Bug 2156 has been marked as a duplicate of this bug. ***
Actions #5

Updated by Saurabh Garg almost 19 years ago

Comment from bug# 2156:

Comparing Metacat with other search engines, there is a major
difference in the metacat web interface when compared to others. We
dont divide the result into blocks. So any online search will show x
number of results at a time. Metacat on the other hand shows all
results in one go. I am not sure how to fix this yet but I think we
will improve on time in three ways: database processing time, network
time and rendering of data in the browser. KNB currently has 1600
documents+ and a % search sends back a webpage which is 1.45 MB in
size. Hence even if we think of broadband, that is a lot of data being
sent back. Same goes for rendering of 1600 documents as compared to
10/20 documents. I am not sure though how hard this will be to implement

Actions #6

Updated by Saurabh Garg almost 18 years ago

The query will probably to be stored on per session basis. Maybe the docids found can be stored in a ordered data structure in the session for each of the clients..

But there has to be a query id also as there might be multiple queries coming in from a client.. hence there might be multiple datasets to store. Hence all the skins and morpho when using paged query returns will have to be modified to include the query id assigned by metacat in there request of next set of results.

Actions #7

Updated by Matt Jones over 17 years ago

See for an excellent discussion of strategies for query paging using JDBC.

Actions #8

Updated by Chad Berkley over 17 years ago

Metacat now does paged query returns. It also caches the last query with the user's session so that it does not need to re-run the entire query to re-display results. The cache can easily be cleared by running a different query then running the original query if you want to make sure you have the newest results. This works for public and authenticated sessions. I'll leave this bug open for now in case there are any problems that crop up with this solution later.

Actions #9

Updated by Redmine Admin over 11 years ago

Original Bugzilla ID was 129

Actions #10

Updated by ben leinfelder almost 11 years ago

  • Status changed from In Progress to Closed

Now using SOLR as the search mechanism which absolutely supports paged results.


Also available in: Atom PDF