Grouper Developers Forum

[Tom Zeller <>]

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...
> >