Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Grouper client: getting total result count when performing paginated query

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Grouper client: getting total result count when performing paginated query


Chronological Thread 
  • From: "Katika,Shanthi Swaroop" <>
  • To: "Hyzer, Chris" <>, Geert van der Ploeg <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] Grouper client: getting total result count when performing paginated query
  • Date: Fri, 20 May 2016 17:40:31 +0000
  • Accept-language: en-US

That’s certainly a good workaround. I didn’t know that we could access the database through the web services API. Could you point me in the direction  of documentation or examples for it?  


From: "Hyzer, Chris" <>
Date: Friday, May 20, 2016 at 4:00 PM
To: temp <>, Geert van der Ploeg <>
Cc: "" <>
Subject: RE: [grouper-users] Grouper client: getting total result count when performing paginated query

If its possible you could get SELECT access to two views and get the counts that way as a temporary measure…  or you could use the Java API though it might not be possible and this is not recommended anyways (to put the Java API into another application).

 

I would use the grouper_memberships_lw_v and grouper_groups_v

 

Thanks

Chris

 

From: Katika,Shanthi Swaroop []
Sent: Friday, May 20, 2016 11:13 AM
To: Hyzer, Chris <>; Geert van der Ploeg <>
Cc:
Subject: Re: [grouper-users] Grouper client: getting total result count when performing paginated query

 

Hi.

 

I just realized that replying from the user list  webpage doesn’t send all the previous communication with it. For context, I’m resending my previous question. I apologize for any inconvenience caused. 

 

Is there any update on this issue? I'm currently doing a workaround for

pagination by making two API calls. The first API call to get current Page

results, and the second API call by changing the pageSize to check if the next

few pages exist or not and then generate page links in pagination depending on

how many more results exist. 

 

If it's not possible to add parameters to the current APIs, could you create a

new API to get just count of number of groups and count of number of subjects

in a group?

 

Best,

Swaroop

 

 

From: Chris Hyzer <>
Date: Tuesday, October 22, 2013 at 4:51 PM
To: Geert van der Ploeg <>
Cc: "" <>
Subject: RE: [grouper-users] Grouper client: getting total result count when performing paginated query

 

Im sorry, we can change WS in a version to send more params to the server, but if we send extra params back, it can break clients.  With our framework it would not be straightforward to do this for REST and not SOAP.  Anyways, I opened a jira for 2.2

 

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

 

Thanks,

Chris

 

From: Chris Hyzer
Sent: Thursday, October 17, 2013 11:49 AM
To: 'Geert van der Ploeg'
Cc:
Subject: RE: [grouper-users] Grouper client: getting total result count when performing paginated query

 

I could look into that too… btw, you can chain up your find groups calls in weird ways… if you have a simple call like the one you suggest, then the paging will work, if it is more complex, then not.

 

 

 

From: Geert van der Ploeg []
Sent: Thursday, October 17, 2013 9:38 AM
To: Chris Hyzer
Cc:
Subject: Re: [grouper-users] Grouper client: getting total result count when performing paginated query

 

Hi,

 

I would certainly be interested in a fix for this feature. We use 2.1.5 right now, a patched version of that release would work fine for us.

By the way, would the same fix work for a likewise call to GetGroups?

~~~

      WsGetGroupsResults results = new GcGetGroups()

      .addSubjectId(personId)

      .assignPageSize(pageSize)

      .assignPageNumber(pageNumber)

      .execute();

~~~

 

Some background information: Currently I'm working on replacing our 1.6.3 Grouper installation with an up to date version. This also includes removing some direct database calls to the Grouper database and replace them with proper calls to the Grouper web service.

Pagination is one key issue to be solved, the other one is getting a list of 'my groups', but filtered on (part of) the group name (and paginated as well). Maybe this will result in a feature request as well, but we will see.

 

Thank you!

 

Geert

 

On 17 October 2013 14:34, Chris Hyzer <> wrote:

Unfortunately right now it doesn’t return that right now.  I could probably add that in for you if you wanted to get the latest 2.1.4 and rebuild, is that something you are interested in?

 

Thanks,

Chris

 

From: [mailto:] On Behalf Of Geert van der Ploeg
Sent: Thursday, October 17, 2013 5:56 AM
To:
Subject: [grouper-users] Grouper client: getting total result count when performing paginated query

 

Hi all,

 

I'm trying to use Grouper client to get a list of groups, but I want the results paginated.

So I include a WsQueryFilter to contain a pageSize and pageNumber.

This indeed returns a paged 'slice' of the results.

 

But how can I figure out the total result count of the request (if it weren't paginated)?

Only then I could render a message like "Displaying results 11-20 of 87" and decide whether to hide/show 'next page' links etc, in my user interface.

 

Code I use right now:

~~~

    WsQueryFilter filter = new WsQueryFilter();

    filter.setPageSize("10");

    filter.setPageNumber("1");

    filter.setQueryFilterType("FIND_BY_GROUP_NAME_APPROXIMATE");

    filter.setGroupName("%");

    String personId = "urn:collab:person:example.com:admin";

    WsFindGroupsResults results = new GcFindGroups()

            .assignQueryFilter(filter)

            .assignIncludeGroupDetail(false)

            .assignActAsSubject(new WsSubjectLookup(personId, null, null))

            .execute();

 

~~~

Running the same query but without filter would probably return the whole set. But that would defeat the purpose of the pagination (not having to query a huge list of groups).

 

Thanks for any hints.

 

Kind regards,

Geert

 




Archive powered by MHonArc 2.6.16.

Top of Page