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: Mon, 02 Jun 2008 11:00:27 +0100


I agree with Chris that we need to store who made a change. We might want to allow API instances to have an identifier also so that we can track which applications may have been used to make changes - GSH vs the UI.

I would store metadata we already know about in a single row but allow for custom attributes in a separate table.

If LDIF can adequately describe changes and can easily be parsed back into a Java representation then that sounds OK. I’m not sure if anyone would actually try to apply the LDIF we generate directly against their LDAP server, so we should consider other formats / use an interface so sites can implement their own ‘serialization’. We must ensure we properly escape data as there are few restrictions on subject ids, source ids and group names.

As I wrote in my reply to Chris, I’m not sure using the filesystem is the best idea but that could be a configurable option.

Data interfaces - the query interface (or at least tools which use it) could be an extension.

Rolling the changelog - I’m not sure if there will be any legal requirements for holding data for, say, several years. I would assume data would be archived rather than deleted / overwritten.

Change Representation Format - there are two issues here - the actual format and the storage medium. We could store LDIF format in a CLOB, or split it across multiple varchar2’s.

Group member modification
We should work through some very specific examples and also what happens if we delete a group.

In the case where group A is a member of group B is a member of group C and we add subject D as a member to group A then group B and C are changed. If we need to be able to notify these changes we need to record them, however, that suggests that a change can have a parent i.e. if a change spawns a ‘tree’ of changes we should know how they are related.


--On 30 May 2008 13:50 -0500 Tom Zeller

Howdy folks,

Based on our discussions of hooks+notifications and correspondence from
TomB, I have sketched a changelog implementation :

It's rough in places (and perhaps just plain wrong in others), some ideas
I scraped from the list and some I just cooked up; it however represents
my allotted time so far.

Your comments are appreciated.


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page