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: Chris Hyzer <>, Tom Zeller <>, Grouper Dev <>,
  • Subject: RE: [grouper-dev] changelog implementation sketch
  • Date: Mon, 02 Jun 2008 10:23:29 +0100

I think we need to be very clear on what we are trying to achieve with auditing since it impacts greatly on our approach.

Tom B. has suggested that we use reliable (guaranteed) auditing as a way of recording changes such that these changes can be used to drive potentially less reliable notifications. Effectively, if a notification fails it might be reconstructed / queried for by a ‘listener’ system. So, in Java, we will have a representation of a change which can be ‘serialised’ to the audit database. It should then be possible to re-constitute the Java representation of the change from the data in the audit database.

As I understand it auditing goes beyond who did what and when within Grouper. It may also be necessary to know, at any point in time, who was a member of a group or who had a particular privilege for a group. This was an important requirement for Steve Langella when discussing the future Grid Grouper to control access to Grid resources. It has also come up in discussions at Bristol.

I think that it ought to be possible to work backwards (or forwards from a known snapshot) to determine exactly how a group looked at a point in time. So, even if we don’t provide the tools to do that just now the audit logs should contain sufficient information to make it possible.

I am also uncomfortable with the idea of using the file system to store changes largely because the API can easily be run in different JVMs on different machines which would need to mount the same file system and be properly configured.

I originally suggested LOBs because big and nested membership changes might exceed varchar2 implementations. Many changes would fit easily into a standard varchar2 so an alternative would be to split larger changes across multiple varchar2 fields - variable according to the database implementation. This would also make it easier to query data. A site could write a tool to ‘export’ the changes as files if they prefer to use find / grep.

I agree we need to be careful to ensure that saving audit information doesn’t adversely affect performance. Auditing should be optional and we will need to profile +- auditing to see what impact it does have.


--On 30 May 2008 15:18 -0400 Chris Hyzer

I was thinking of the auditing could be used to see who did what when
from where.

So, not considering the use of this for systems to stay in sync with
grouper, it would be one table and the columns could be something like:








category (e.g. group),

action (insert),

description (e.g. group created with name 'whatever:whatever' and
description 'this is the des...' and friendly name 'Whatever stem:
Whatever Group'),

system (prod_ui, test_web_service, my_gsh),

object_id (group_id),



Note that the behind the scenes changes to the registry might not need to
be added (e.g. that GrouperAll was added as a member). Its more just
what users / clients do from an external perspective...

I agree that the table would need to auto-delete some old records, since
these grow large. So I would think that recreating the point in time
wont be possible (or are we planning on working backwards?) right?

I think a requirement should be that this thing should be gentle on
system performance. If we are writing files, storing multiple rows, etc
it might take a performance hit...

Also, from an architecture perspective, I am all that keen on storing
local files. If you wanted a hot/standby redundancy setup, now the disk
is involved, instead of the DB...




On Behalf Of Tom
Sent: Friday, May 30, 2008 2:50 PM
To: Grouper Dev;

Subject: [grouper-dev] changelog implementation sketch

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