Grouper Users - Open Discussion List

[Chris Hyzer <>]

I don't know what you are expecting it to return...  Note the paging is for 
each group, since there is a separate query for each group.  When you do a 
getMembers for multiple groups, it returns a list for each group...  can you 
call it for one group at a time when paging?  :)

Example:

GroupA:
memberA0
memberA1
memberA2
memberA3

GroupB:
memberB0
memberB1

################

Get first page of size 2 for groups GroupA,GroupB:

Results
        - GroupA
                - memberA0
                - memberA1
        - GroupB
                - memberB0
                - memberB1

###############

Get the second page of size 2 for groups GroupA,GroupB:

Not sure if this throw an error since there is no second page of size 2 for 
GroupB, or if it is an empty list...  I would think it would be an empty list:

Results
        - GroupA
                - memberA2
                - memberA3
        - GroupB
                <no members returned>


Is this what you expect?

Thanks,
Chris

-----Original Message-----
From: Jeff McCullough 
[mailto:]
 
Sent: Friday, September 14, 2012 12:59 PM
To: Chris Hyzer
Cc: 
;
 CalNet Administration
Subject: Re: [grouper-users] REST query string

You are awesome. Thank you sooo much. :) A quick question about sorting. Will 
it check for uniqueness across the listed groups?

Thank you,
Jeff

On Sep 14, 2012, at 5:33 AM, Chris Hyzer wrote:

> ok, I have paging/sorting working in the logic, now I need to test more, 
> document, expose in the WS transfer objects, REST/SOAP/WSDL/etc, implement 
> in client, test client, change the configs for a 2.1.3 build, do a build, 
> and put on server...  :)  Will let you know
> 
> Chris
> ________________________________________
> From: Jeff McCullough 
> []
> Sent: Thursday, September 13, 2012 2:21 PM
> To: Chris Hyzer
> Cc: 
> ;
>  CalNet Administration
> Subject: Re: [grouper-users] REST query string
> 
> Hi Chris,
> 
> I understand your concern, but the groups being accessed are reference 
> groups that won't be changing at the same time. The SQL interface idea is 
> interesting, but I'm very reluctant to give them access to the underlying 
> db. It is probably best to stick with the REST interface paging if you are 
> game.
> 
> Thank you,
> Jeff
> 
> On Sep 13, 2012, at 11:15 AM, Chris Hyzer wrote:
> 
>> If you are downloading all memberss from a group, I worry about paging...  
>> I think paging is great for UIs though.
>> 
>> If a member is added while the page queries are being executing, a member 
>> could be missed.
>> 
>> e.g.
>> 
>> Grouper members:
>> 
>> 1,2,3,4,5,6,7,8,9,10
>> 
>> App gets the page of size 2 starting at index 0: 1,2
>> App gets the page of size 2 starting at index 2: 3,4
>> 
>> Then item #2 is removed:
>> 
>> 1,3,4,5,6,7,8,9,10
>> 
>> App gets the page of size 2 starting at index 4: 6,7
>> 
>> Note that member 5 was missed, even though they are in the group.
>> 
>> So... do you think they can just get all the members at once without 
>> paging (even though size of 10k)?  There is also the Grouper SQL interface 
>> of reading grouper_memberships_v (filter on field and group) which can be 
>> used for large exports...
>> 
>> If you still want paging in WS, no problem, it looks like I could add this 
>> to getMembers without much trouble, let me know.
>> 
>> Thanks,
>> Chris
>> 
>> -----Original Message-----
>> From: Jeff McCullough 
>> [mailto:]
>> Sent: Thursday, September 13, 2012 1:56 PM
>> To: Chris Hyzer
>> Cc: 
>> ;
>>  CalNet Administration
>> Subject: Re: [grouper-users] REST query string
>> 
>> Hi Chris,
>> 
>> Thanks for the info. We were just hooking our first real client app, and 
>> the paging thing is going to be a deal breaker for them. Putting part of 
>> the query in the request body is workable. The client app will be pulling 
>> group data that will frequently be in the 10s of thousands, and they would 
>> prefer to pull about 500 members at a time. Do you have a sense of how 
>> much effort adding paging to getMembers might be, and a rough time frame? 
>> I can maybe steer them to using LDAP groups, but the window of opportunity 
>> they have to change to using grouper for the app is fairly short. I'm a 
>> little worried they may be lost on other projects for a very long time. 
>> Okay... Enough pleading. :) Let me know.
>> 
>> Jeff
>> 
>> 
>> 
>> On Sep 13, 2012, at 10:07 AM, Chris Hyzer wrote:
>> 
>>> A couple of gaps unfortunately... for the params to be in the URL, it has 
>>> to be a Lite operation, and you can only get members from one group at a 
>>> time in a Lite getMembers or getMemberships operation.  If you want to 
>>> pass a JSON/XML/XHTML string in the body of the request, you can specify 
>>> multiple groups.  I don't see where there is paging on getMembers or 
>>> getMemberships... I think we need to add that.
>>> 
>>> https://bugs.internet2.edu/jira/browse/GRP-845
>>> 
>>> Thanks,
>>> Chris
>>> 
>>> 
>>> -----Original Message-----
>>> From: 
>>> 
>>>  
>>> [mailto:]
>>>  On Behalf Of Jeff McCullough
>>> Sent: Wednesday, September 12, 2012 6:48 PM
>>> To: 
>>> 
>>> Subject: [grouper-users] REST query string
>>> 
>>> Quick question. Is it possible to compose a REST like query in one URL 
>>> that uses paging and requests subjects from more than one group?
>>> 
>>> Thanks,
>>> Jeff
>> 
>