Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Grouper 1.6.1 UI membership list sorting

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Grouper 1.6.1 UI membership list sorting

Chronological Thread 
  • From: Jim Fox <>
  • To: "" <>, "" <>
  • Subject: Re: [grouper-users] Grouper 1.6.1 UI membership list sorting
  • Date: Fri, 8 Oct 2010 13:44:23 -0700
  • Accept-language: en-US
  • Acceptlanguage: en-US

>So, while I can see that storing a string for sorting would be of
>immediate benefit, with few risks, I see icebergs ahead if Grouper were
>to try to cache all data about all subjects from all sources. These
>* Consolidation and de-duplication - Grouper would be caching data from
>multiple sources, but presenting a consolidated set. Should subjects
>from different sources which represent the same person be consolidated
>into a single subject? now? ever?
>* Timeliness - how up-to-date would the local Grouper subject store need
>to be? In our case if would be unacceptable if it were out-of-date by
>more than a few seconds

We don't have Grouper do any consolidation of subjects, but we do keep all
our sources in Grouper's database. Consolidation of similar sources is a
whole different can of worms. Our groups system washes its hands of that.
Our sources include:

* people and other things that can login (staff, students, alumni, ...),
* DNS names from certificates we issue. These are used by applications to
* ePPNs for people outside the university, and
* ActiveDirectory machine names,

which are all kept up to date by various external processes. Of those the
people and the AD machines could be LDAP sources.

A common subject source, LDAP directory or DBMS, is itself hardly ever the
system of record for subject information. So there are already some
processes that keep caches updated. Adding Grouper into the mix should not
be so difficult. We do some cache updates overnight, names and
departments, for example. More critical changes, such as login id, are
updated immediately.

The principal advantage we gain by using local subject tables is speed and
efficiency of searches and membership queries. We can, for instance,
produce one page of a paged membership report, sorted by some subject
attribute, with a single database query. Paging a sorted membership list
is just not feasible with remote subjects.

I don't know that our configuration would work for everyone, but I do know
that one of Grouper's greatest faults is the unbearable slowness on some
operations. I think remote subject sources are the major factor in that
leaden behavior. It seems like an issue that must be dealt with.


Archive powered by MHonArc 2.6.16.

Top of Page