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: Chris Hyzer <>
  • To: Tom Zeller <>, Grouper Dev <>, "" <>
  • Subject: RE: [grouper-dev] changelog implementation sketch
  • Date: Fri, 30 May 2008 15:18:18 -0400
  • Accept-language: en-US
  • Acceptlanguage: en-US

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:

 

log_id,

timestamp,

subject_id_who_made_change,

source_id_who_made_change,

act_as_subject_id_who_made_change,

act_as_source_id_who_made_change,

ip_address_of_person_who_made_change,

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),

optional_field,

optional_field2

 

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…

 

Regards,

Chris

 

From: [mailto:] On Behalf Of Tom Zeller
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 :

 

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




Archive powered by MHonArc 2.6.16.

Top of Page