Grouper Users - Open Discussion List

[Jeff McCullough <>]

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
>