oodt-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OODT-68) Add Number of Product Hits to ProductPage
Date Tue, 07 Dec 2010 14:17:08 GMT

    [ 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.

View raw message