Grouper Developers Forum

[Tom Zeller <>]

Lets take my use case:

- Get members 51-100 of a group of 60k members sorted by name without retrieving all 60k members and without looking up 60k members from the subject API.

Without knowing the sort string, you will need to retrieve all 60k, and go to the subject api and get the sort string, then sort them, then get 51-100.  In general, doing operations across multiple sources and collating the results is hard without some consolidation.

If the sort string is in a table of all subjects (probably the members table), then this is one easy hibernate query.

Maybe we could make this optimization optional somehow (hard to think how :) ), but I think if people want to use a UI or WS to manage large groups, that is not embarrassingly slow, then they will want to adopt this.

Granted I can picture some sources (e.g. web service of a remote federated source) where frequent retrieval of all known subjects, or a retrieval of all subjects, might not be convenient... hmm...

So, Chris, you're saying just store the subject 'name' along with their id in grouper ? perhaps with some ttl ? and don't fret if a subject's name changes between refreshes of a UI page ? and maybe not 'name' but whatever the UI is configured to display ?