Skip to Content.
Sympa Menu

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

Subject: Grouper Developers Forum

List archive

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

Chronological Thread 
  • From: Chris Hyzer <>
  • To: Colin Hudler <>, "" <>
  • Subject: RE: [grouper-dev] Problem Paging A Stem Containing Child Groups (start parameter)
  • Date: Mon, 3 May 2010 13:27:29 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

As always, thanks for the thorough analysis.

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?


From: Colin Hudler
Sent: Friday, April 30, 2010 2:51 PM

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


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


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

int, int, java.lang.StringBuffer, boolean, boolean)

defined as

public Set getChildren(String node,String listField,int start,int
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

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();
queryOptions = new QueryOptions().paging(queryPaging);
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
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

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

  • RE: [grouper-dev] Problem Paging A Stem Containing Child Groups (start parameter), Chris Hyzer, 05/03/2010

Archive powered by MHonArc 2.6.16.

Top of Page