Grouper Developers Forum

[Chris Hyzer <>]

 

 

 

> So, Chris, you're saying just store the subject 'name' along with their id in grouper ?

 

Their ID is already in grouper_members, so yes, I propose adding the name, description, and sort_string (e.g. to_lower of name, or whatever site picks)

 

> perhaps with some ttl ?

 

I think a time-to-live is an interesting idea.  I was originally thinking we would refresh all on an interval, so we don’t worry about TTL, but we could consider that as well.  I don’t think it should ever clear out if the TTL runs out and the subject is unresolvable (could be useful to have this info for unresolvables)

 

> and don't fret if a subject's name changes between refreshes of a UI page ?

 

Well, I was thinking it was only for query purpose, and maybe to display the 50, it would go back to subject api.  Though maybe this is an option.  But yes, if you go back to subject API, and all the sudden it is not sorted exactly correctly, then don’t fret, or resort, and maybe there is an  outlier.

 

> and maybe not 'name' but whatever the UI is configured to display ?

 

Yes

 

Regards,

Chris

 

 

 

From: [mailto:] On Behalf Of Tom Zeller
Sent: Friday, February 27, 2009 11:35 AM
To: Chris Hyzer
Cc: Tom Barton; GW Brown, Information Systems and Computing; Grouper Dev
Subject: Re: [grouper-dev] subject attribute cache?

 

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 ?