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: "" <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] Grouper 1.6.1 UI membership list sorting
  • Date: Sat, 9 Oct 2010 11:29:55 -0700

>
> 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 include:
>
> * 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 or sources.
Consolidation of similar subjects is a whole different can of worms, of
which our groups system washes its hands. We do, though, cache all our
subjects
locally in Grouper DB tables.

Our sources include:

* people and other things that can login (staff, students, alumni, ...),
* DNS names from certificates we issue. Applications use certs to
authenticate,
* 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.

I don't say 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, and I think remote subject sources are the major factor in that
behavior. It seems like an issue that must be dealt with.

Jim




Archive powered by MHonArc 2.6.16.

Top of Page