[
https://issues.apache.org/jira/browse/OODT-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968745#action_12968745
]
Chris A. Mattmann commented on OODT-68:
---------------------------------------
bq. the patch would be backwards compatible . . . setTotalPages(int) should
only be used by Catalog implementations and each Catalog was doing its own
number of page calculations (i.e. has to be reimplemented for each Catalog
implemented) - setTotalPages(int) is the only method which would be dropped . .
. a setter method for number of hits would take its place.
I disagree. The fact that we have to *remove* a method that's existed makes the
suggested approach *non*-backwards compatible. If it only added setNumberOfHits
(and left setTotalPages as-is) then I'd agree, but not if it takes
setTotalPages away.
As for the part about each Catalog doing its own number of page calculations,
that _is the intention_. Paging should be computed on the Catalog side which is
close to the result set list that it can slice up. If we want to streamline
this part, we discussed int he past making an AbstractPagedFilemgrCatalog class
that implements paging (using helper methods delegated to the subclasses which
extend it). I think even think there was a patch floating around at some point
about this.
bq. also with all this new gui development around the filemgr . . . paging is a
heavily used feature . . . having to double query just to get the first page
and the number of hits i think should be addressed - it greatly affects page
load time over large data sets
Hmmm, I haven't seen this at all? We're talking about 2 queries here, not 10,
and users are interactively paging through the results anyways. If they have to
query to get the first page and then at worst issue *one more query* to find
out the last page (in order to understand the # of results on that last page),
I'm not sure I understand the issue (especially when page slices are pretty
small, usually between 10-20 products in the deployments I've seen).
Furthermore, even if they weren't small, user GUI APIs could take advantage of
query(...pageNum), which is an existing method that computes all this stuff *on
the fm server catalog end*, which is even more efficient.
> Add Number of Product Hits to ProductPage
> -----------------------------------------
>
> Key: OODT-68
> URL: https://issues.apache.org/jira/browse/OODT-68
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating
> Environment: none
> Reporter: Brian Foster
> Assignee: Brian Foster
> Priority: Minor
> Fix For: 0.2
>
>
> - By adding get number of hits the method setTotalPages(int) is no longer
> needed; getTotalPages will calculate its return value based on page size and
> total hits
> - This also allows the number of products to be determined by just getting
> the first page, instead of getting last page which internally requires
> DataSourceCatalog to get first page and last page
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
