Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

Tom,

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.

Gary


--On 30 May 2008 13:50 -0500 Tom Zeller 
<>
 wrote:

> Howdy folks,
>
>
> Based on our discussions of hooks+notifications and correspondence from
> TomB, I have sketched a changelog implementation :
>
> https://wiki.internet2.edu:443/confluence/x/lVw
>
>
>
> 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.
>
>
> TomZ



----------------------
GW Brown, Information Systems and Computing