grouper-users - RE: [grouper-users] REST query string
Subject: Grouper Users - Open Discussion List
List archive
- From: Chris Hyzer <>
- To: Jeff McCullough <>
- Cc: "" <>, CalNet Administration <>
- Subject: RE: [grouper-users] REST query string
- Date: Wed, 17 Oct 2012 00:50:02 +0000
- Accept-language: en-US
|
The batching of the WS lets you get the members of multiple groups at once, in separate subcontainers, not to merge the results into one resultset… so I don’t
see how adding paging could be done differently without a drastically different result structure…
Thanks, Chris From: Jeff McCullough [mailto:]
Hi Chris, Thank you for doing this work. Overall it makes sense, though I have a couple of comments relating to sortString and the way individual groups are paged. Is there anyway that the sort string can relate to what a JNDI or LDAP adapter might
return? I can see why that might not work, but just checking. For paging multiple groups is it possible to page through one group after another rather than paging them all at the same time? For example, the subjects from group #1 will be paged until empty,
then the paging moves to group #2, etc. I can see why you chose the way you did it, so again just checking. Thank you, Jeff On Sep 21, 2012, at 4:14 PM, Chris Hyzer wrote:
This is done. You can add these params to getMembers and getMembersLite in 2.1.3+. Note, if paging/sorting is set on a non-lite call with multiple groups, then
the paging sorting will apply to all the individual member lists, not the concatenation of the result * @param pageSize page size if paging * @param pageNumber page number 1 indexed if paging * @param sortString must be an hql query field, e.g. * can sort on uuid, subjectId, sourceId, name, description, sortString0, sortString1, sortString2, sortString3, sortString4 * @param ascending T or null for ascending, F for descending. I cut a 2.1.3 release which is not official and not even really candidate release, but there is not much different in it than 2.1.2 so it is pretty stable,
feel free to try it out and give me feedback Thanks, Chris Ps. there is no schedule for 2.1.3 at the moment From:
[] On Behalf Of Chris Hyzer It sounds like you are doing a combination of #3 and #4 below. Yes, you can create those groups, and get the members, and calculate things on the client.
We can think of the long term plan of having something like this in the Grouper API/WS. I will continue to add paging to the getMembers operation then… Thanks, Chris Ps. btw, include/exclude groups is intended for adhoc one-off changes to groups loaded from a system of record. Otherwise you can add a group to a group (for
union) or do a composite for intersection or minus… From: Jeff
McCullough [] Chris, Okay. The work around follows. Here is the target list group structure I've setup: ::Staff:groups:dept1..N ::Student:groups:dept1..N From what you have said, it sounds like paging/sorting can only be done by group as grouper currently is coded. An extension might be to return a uniquely sorted paged list of all the members of the supplied group list. Grouper does this
now with Include/Exclude groups. If the first part is all that is possible now, then so be it. The client app will need to pull the list, paged if it likes, and then sort the list uniquely. From grouper's perspective it is just pulling data from a list of groups. From
the client app's perspective it is pulling data from two or more target lists that are members of two or more departmental group lists. Make sense? Jeff On Sep 16, 2012, at 6:37 PM, Chris Hyzer wrote: The WS (or the underlying Grouper API for that matter) doesn’t have a way to do what you describe. I would suggest: 1. Using
LDAP provisioned from WS 2. –or-
Using SQL (using another schema with a grant to grouper_memberships_lw_v) 3. –or-
Getting all the members and do the calculations on the client (probably need caching) 4. –or-
Create all the calculated groups in grouper that you need (might be too many groups) 5. –or-
We can add this to Grouper, though its not as easy as adding paging/sorting, so we would need to discuss the specifics and prioritize with other enhancements… If anyone on the Grouper team wants to elaborate, feel free. Jeff, sorry this is not what you were hoping for, but let me know how you want to proceed. Thanks, Chris From: Jeff
McCullough [] You are correct in all points. The client app owners would prefer to use WS. It is fairly easy to compose the target lists into departmental groups, and a subset of those groups can be returned. If filtering, a union of two target lists could be filtered by departmental codes on the fly. There is also the issue
of uniqueness. For example, if the target lists were staff and students, there will be overlap. Jeff On Sep 15, 2012, at 6:35 PM, Chris Hyzer wrote:
Just to be clear on what you are asking… you want to send a filter in to the WS and get a list of members back? e.g. send in: ((STAFF UNION AFFILIATES) INTERSECTION (DEPT_A UNION DEPT_B)) Return the list of members (in pages of 500 at a time)… Is that right? Just curious, is Grouper provisioned to LDAP and an LDAP filter could do this, but you would prefer they used WS? Thanks, Chris From: Jeff
McCullough [] The app is used to send messages to various target lists. For example staff (plus maybe affiliates) in several departments. So it is an AND of the target list(s) and selected departments. The target lists aren't
always the same so the idea is to let grouper create the target list by creating departmental groups within that target list folder. Then the apparently can pick a target list by selecting the members from the appropriate groups/depts within the target list
folder. Chris Hyzer <> wrote: Do you want to get the members who are in any of the groups, or all of the groups (AND or OR)? 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? :) 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
If you are downloading all memberss from a group, I worry about paging... I think paging is great for UIs though. 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. |
- Re: [grouper-users] REST query string, Jeff McCullough, 10/16/2012
- RE: [grouper-users] REST query string, Chris Hyzer, 10/16/2012
Archive powered by MHonArc 2.6.16.