Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] auditing for 1.5

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] auditing for 1.5

Chronological Thread 
  • From: Tom Barton <>
  • To: Chris Hyzer <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] auditing for 1.5
  • Date: Mon, 05 Jan 2009 13:31:55 -0600

To re-stir this topic in preparation for the upcoming call, here are some points and questions about the auditing proposal.

1. Notifications & PIT (point in time audit data). You posit a notification architecture that's centered around the database and its record of changes. An alternative is for each API instance producing a change to emit a notification of that change. That can work provided all API instances share a common serialization scheme, ie, a way so that recipients of their notifications can order them correctly. A way to do that is to grab a serial number from the DB, ie, reduce the architectural dependence on the DB to just that one function. Did you consider an approach along these lines and reject it? What are the pros and cons of the two approaches?

2. Although doing PIT and User Auditing in the DB may be easy, I wonder about the difficulty of re-integrating a logical group management action from its DB-level effects. Could you (or someone) illustrate how this would proceed in a couple of particular cases? Eg, how would you tell that an indirect membership was removed due to an action taken by $Subject at $Time?

3. I completely understand the considerable value of using triggers from the perspective of performance. However, this raises the prospect of limiting the set of RDBMS products (and their revs) supported by Grouper. Quite aside from whether that's a good course to take from the Marketing perspective, what would implementing that type of support realistically mean to us as a development team? Eg, in January 2011 would we find ourselves under pressure to continue grouper's support of older revs of Oracle and SQL Server, older than those running in production at each developer's campus? Would that mean that we must run a series of revs of each supported RDBMS to test against? Would there be licensing costs the Grouper Project would need to underwrite if we're not piggy-backing on the license held by some developer's campus? Any other operating costs (servers, space, sys admin time to keep the required suite of RDBMS-revs running)?


Chris Hyzer wrote:
OK, we are focusing on getting 1.4 out the door (so much so that my work is done, and Im thinking about 1.5 J ). Anyways, I did a proof of concept of an easy auditing solution (auditing would be 1.5), and wrote a small doc. We don’t have to spend a lot of time discussing now, and I wont be doing more work on it anytime soon, but we can mull it over in the next few weeks and see if we like the idea or can come up with something better… J

Feel free to leave comments on the wiki page, or if you aren’t allowed, email me and I can add them for you



Archive powered by MHonArc 2.6.16.

Top of Page