Grouper Developers Forum

[Chris Hyzer <>]

Hey,

 

I know I have brought this up before and got shot down, but I have a little different spin on it this time, so hear me out.

 

I got a request to add a user to be a reader on a 60k member group.  So I go to the UI, pull up the group, pull up the readers, and click the button to assign to more users.  Then I wait, and wait, and wait, then I get an error.

 

https://bugs.internet2.edu/jira/browse/GRP-234

 

Apparently it will look at members (60k), and show the first 50 (or so) so you can pick the readers from the members.  This is not an easy task, since to get the first fifty based on a subject attribute, you need to go get all 60k, then put all the subject attributes together, sort, and chop off the list.  The particular error here was because some of the subjects were unresolvable, and it wasn’t handled correctly (I think it shouldn’t fail if it has unresolvable subjects).  So yes, I need to delete my unresolvable memberships, and I can also assign privs to grouper with unresolvable members via GSH…

 

But I got to thinking, what if there were a periodic job which did the unresolvable report (the daily report can already do this), and while doing that job, when it was resolving subjects, it just stashed a local copy of the attributes.  Then, under normal operations, it would go to the source for the attributes.  But for things like queries where sorting and paging are needed (or optionally if the source is unavailable, or if the subject is unresolvable?) grouper could use the local information.   So things could get a little out of sync… if someone changes their name in the source system, grouper will sort and page based on the old data, but the new data will appear on the screen.  Maybe grouper could also update the info when a subject is looked up and the data is different or something. 

 

Grouper could also optionally index this stuff in a search engine so subject queries based on substring of description (although not real time) would be superfast.   http://www.hibernate.org/410.html  This way the source would really only need to be optimized for ID lookups, not text searches…

 

Anyways, just a thought…

 

Thanks!

Chris