Grouper Users - Open Discussion List

[Jeff McCullough <>]

The customer for the client app wants to look at this as one uniquely sorted 
query, more like a JOIN across the specified groups. Is that at all possible?

Jeff

On Sep 14, 2012, at 10:28 AM, Chris Hyzer wrote:

> 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
>>> 
>> 
>