Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] changelog implementation sketch

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] changelog implementation sketch

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Tom Zeller <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] changelog implementation sketch
  • Date: Tue, 10 Jun 2008 16:12:09 +0100

--On 10 June 2008 09:17 -0500 Tom Zeller

This is already a rather long thread, and I'm loathe to add more to it,

Representing changes from a group-centric point of view via LDIF seems
straightforward, but what about member-centrically ? e.g. how someone's
group memberships have changed.
What is the context here? Are we back to the subject id changing or is this to make it easier to query from a member point of view i.e. show me all the memberships for 'x' on a given date?

Group-centrically :

dn: name=stem:group,uuid=...
add: members
members: subject...

Member-centrically ?

dn: name=subject
add: groups
groups: stem:group

Doesn't seem right to me. I imagine we would want to be able to easily
query for changes affecting a member, and consequently it seems we would
probably want to add the member (or it's subject id) as a column, and
hence we would want one row per membership change...which makes me think
LDIF isn't the right way.
One row per membership change wouldn't be down to the LDIF format - it would mean we are not storing enough metadata in the database table. I hadn't thought about looking from the member perspective. In principle we should be able to do this, but one row per membership change doesn't strike me as scalable. If the actual change definitions - the LDIF or whatever format we use - for a group can be queried using 'like' we could have an inefficient means of finding relevant changes which would allow us to compute a subject's memberships at a given point in time.

In the end it could come down to how often we need to ask questions of the change log. If infrequently we can live with slower response times.

Another approach would be to have an asynchronous process for expanding the 'batch' group membership changes into one row per change so that it does not slow down the API.


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page