Grouper Developers Forum

[Chris Hyzer <>]

Im open to suggestions, but here is my current plan:

1. If adding, and assuming there is an open row:
        a. Just add it, old data is null
        -or- b. Update all existing rows to something like NA, and add it
2. If changing a col:
        a. Null out all existing audit entry cells with that category / 
action / header
        -or- b. Update all existing rows to something like NA, and change it
3. If deleting a col:
        a. Null out all existing entries of that category / action / header

We need the data to be consistent, we cant have data in a cell which doesn't 
correspond to the header.  Also, the data isn't intended to be used 
programmatically, except possibly for UI links.  Picture a UI with audit data 
in it, the group change could be a link based on the uuid of the group.  If 
the description col is blank, or NA, or there, it just enhances the UI, but 
doesn't make a system break... right?  The uuids I think are the minimum 
data, the other stuff is nice to have.  The real data that we can link to 
from other systems can be accessed through point in time auditing...  
Speaking of which, we will have the same situation when we add cols to 
things, and add corresponding cols to point in time, then we will have to do 
option a. or b. above...

Thoughts?

Regards,
Chris

> -----Original Message-----
> From: Tom Zeller 
> [mailto:]
>  On Behalf Of Tom Zeller
> Sent: Saturday, February 07, 2009 11:19 AM
> To: Chris Hyzer
> Cc: Grouper Dev
> Subject: Re: [grouper-dev] Action Items: Grouper Call 4-Feb-09
> 
> Given version +1 in which we decide we'd like to add or change the
> string (or int) columns' data, how do we maintain the different
> versions' representation ? especially for 'long term' auditing/history
> ?
> 
> On Feb 6, 2009, at 2:25 PM, Chris Hyzer 
> <>
>  wrote:
> 
> >>
> >> I'd like us to review ideas for how the string and int cols will be
> >> used
> >> for a representative set of operations, before you get too far down
> >> this
> >> path.
> >
> > Here is my current plan (who wants to look at some source
> > code?!?!  :) ):
> >
> >
> http://viewvc.internet2.edu/viewvc.py/grouper/src/grouper/edu/internet2
> /middleware/grouper/audit/AuditTypeBuiltin.java?root=I2MI&view=markup
> > So far, only the String cols are used, not integer.  I picture int
> > cols for things like the loader where you capture how many inserts/
> > updates/deletes took place.
> >
> > Anwyays, so for a membership add:
> >
> > MEMBERSHIP_ADD(new AuditType("membership", "addMembership", null,
> > "id", "fieldId", "fieldName", "memberId", "membershipType",
> > "ownerType", "ownerId", "ownerName")),
> >
> > The audit category is "membership", and the action in that category
> > is "addMembership".  The category and action are a unique key in the
> > audit type table.  The String fields to capture for a membership add
> > are:
> >
> > "id", "fieldId", "fieldName", "memberId", "membershipType",
> > "ownerType", "ownerId", "ownerName"
> >
> > And all the other standard data is always captured: IP address, who
> > was logged in, what system, actAs user, etc
> >
> > For a group update, I will capture this misc string data:
> >
> > "id", "name", "parentStemId", "displayName", "description"
> >
> > Note, the old values arent in there, just the new values.  I was
> > thinking I would put that in the audit description column, something
> > like:
> >
> > Group 'penn:community:employee' was changed:
> >  - Display name was: 'Penn:Community:Employee Group', and is now:
> > 'Penn:Community:Employees of Penn'.
> >
> > Note that this is just for a UI so people can see who (or what)
> > invoked high level grouper operations, and what the user did.  If
> > you want a more data oriented output of what fields and underlying
> > tables were changed, it will be in the point in time auditing tables
> > by context id.  I don't think we need to reinvent that here by
> > making an XML representation of what changed etc... it is in the
> > point in time system...
> >>
> >>
> >>