Grouper Developers Forum

[Chris Hyzer <>]

As always, thanks for the thorough analysis.

https://bugs.internet2.edu/jira/browse/GRP-426

I think this is resolved (for now). The problem was that groups are paged in 
the DB, and stems are not, and not in the same query. This is a tough 
problem. I just show all stems on screen and paged groups underneath. Might 
be an issue if there are lots of stems underneath, but I have spent a bunch 
of time on this so if we want to go further it will take significant effort.

Attached are screenshots

Can you try from the 1.5 branch in svn?

Gary, do you mind reviewing the code?

Thanks,
Chris

________________________________________
From: Colin Hudler 
[]
Sent: Friday, April 30, 2010 2:51 PM
To: 

Subject: [grouper-dev] Problem Paging A Stem Containing Child Groups (start 
parameter)

Greetings,

In the standard grouper user interface (1.5.2), when a stem contains
many groups (more than the page size), clicking next does not advance
the page.  Instead, it loads the same first page of groups.  It was soon
discovered that manually setting the "start" parameter to a much higher
value, like

https://grouper/browseStemsAll.do?start=200&currentNode=3e59f943-4d04-4a90-b102-d9218b8295d4&pageSize=10

Actually did take the user to the next page.  I went looking, and I
found a likely source of the problem.  Please advise if you prefer some
other troubleshooting (it is easily reproducible).  Skip to the very end
for my conclusion.

Ultimately, the stem browsing ui calls

edu.internet2.middleware.grouper.uiAbstractRepositoryBrowser#getChildren(java.lang.String,
int, int, java.lang.StringBuffer, boolean, boolean)

defined as

   public Set getChildren(String node,String listField,int start,int
pageSize,
       StringBuffer totalCount,boolean isFlat,boolean isForAssignment,
       String omitForAssignment,String context,HttpServletRequest
request) throws Exception{

There's a bunch of logic, which in this case comes down to

         List<GroupAsMap> listOfMaps = getChildrenAsMaps(s, stemName,
           (start/pageSize)+1, pageSize, resultSizeArray);

Note that it takes the "start" and divides it by page size to get the
current page.

getChildrenAsMaps() calls another getChildren with a different arity in
the same file.  It is defined as

   public List<GroupOrStem> getChildren(GrouperSession s, String stemId,
       int start, int pageSize, int[] resultSize) throws
StemNotFoundException{

Here it finally starts to get the children, and uses paging in a
conditional block:

     QueryOptions queryOptions = null;
     if (this.pagedQuery()) {
       QueryPaging queryPaging = null;
       queryPaging = new QueryPaging();
       queryPaging.setPageSize(pageSize);
       queryPaging.setFirstIndexOnPage(start);
       queryOptions = new QueryOptions().paging(queryPaging);
       queryOptions.retrieveCount(true);
     }
     children=getChildGroups(stem, queryOptions);
     if (GrouperUtil.length(resultSize) >= 1) {
       if (this.pagedQuery()) {
         resultSize[0] = queryOptions.getCount().intValue();
       }
     }

It is calling "queryPaging.setFirstIndexOnPage(start);" with the start
parameter converted already by the other getChildren().  Let's take a
look at what
edu.internet2.middleware.grouper.internal.dao.QueryPaging#setFirstIndexOnPage
does with it:

     this.pageNumber = (startIndex / pageSize) + 1;

HMMM, looks like it will always be "1" unless our "start" parameter is
one extra pageSize magnitude larger.  I hope you enjoyed this journey,
and I hope the problem is clear.

It appears that the start parameter should not be converted into a page
number by getChildren.  I haven't bothered to examine the consequences
of changing
edu.internet2.middleware.grouper.uiAbstractRepositoryBrowser#getChildren

Let me know if I can clarify further, or it is completely wrong direction!

Attachment: page1.gif
Description: page1.gif

Attachment: page2.gif
Description: page2.gif

Attachment: page3.gif
Description: page3.gif