Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] hooks and notifications

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] hooks and notifications

Chronological Thread 
  • From: "GW Brown, Information Systems and Computing" <>
  • To: Tom Barton <>, 'Grouper Dev' <>,
  • Subject: Re: [grouper-dev] hooks and notifications
  • Date: Wed, 28 May 2008 14:44:27 +0100

--On 28 May 2008 08:09 -0500 Tom Barton

GW Brown, Information Systems and Computing wrote:

--On 27 May 2008 16:30 -0500 Tom Barton
I know of actual use cases for veto (Bert, is that what you mean by
"filter"?) and for notification (including notification to an audit
log). I don't think I know any, as yet, for plug-ins to enhance events.
Nor do I see why any such uses would have to be tightly-coupled to the
originating event, in the same transaction.
I would like the ability, when a group is created, to set some group
attribute values (and possibly add some group types) and have those be
part of the transaction. New values would depend on existing values and
location in the hierarchy - but you don’t need to know the details...

The current way of using lots of individual API calls to build a group
isn’t very satisfactory in this respect. Ideally these types of changes
could be effected using new single API methods i.e.

Stem.addChildGroup(String extn, String displayExtn, Set types, Map

Group.setAttributes(Map attributes)
Group.setAttributes(Set newTypes, Map attributes)
Group.setAttributes(Set newTypes, Map attributes, Set removeTypes);

Similarly, for adding / removing members or privilegees:

Group.addMembers(Set subjects)
Group.addMembers(Set subjects,Set subjectsToRemove)

Rather than generating lots of ‘small’ changes, a single ‘large’ change
can be vetoed, amended* or notified). I can’t sensibly choose to veto
type/attribute changes to a group without knowing what all the changes
are - and currently when you make one change the API has no knowledge of
any API calls you intend to make in the next lines of code.

I zero in on the word "ideally" above, and agree. You are saying that
there's a use case for enhancing the API, but you'd settle for the
ability to meet your need with a plug-in. Why don't we just put it in the
API for 1.4.0?
It is actually both - we need to enhance the API and then it becomes practical to use hooks to deal with the complete changes.

Are there other actual use cases for enhancing groups by plug-in?
None that immediately come to mind.

However, I *do* want reliable audit history. And I don't want that to
depend on a separate process calling back to the DB for the details on
what changed, in case it may have changed again in the meanwhile. I'd
like instead to have a logical description of each completed transaction
preserved somewhere in the grouper DB when the transaction completes.
This history-of-changes table could have a configurable depth (time or
size) and would necessarily serialize all transactions, thus also
providing the basis for reliable notification by 3rd party
implementations. The hard part of this is deciding what the "logical
descriptions" are - it's not which columns in which tables have what new
values. Think of LDIF as a motivating example. The grouper event log, at
INFO level, is probably capturing the right events, but not with the
right schema.
So are we looking at tables with:

date, transaction_id, member_id

transaction_id, object_id, object_type, change*

*where change is a clob, or similar, which has a representation of
changes to the object.

Something like that, although I don't think we need to store large
objects, we should have a sequential change number to preserve the order
in which things were changed in the DB, and I'd add names for objects in
addition to their internal ids.
The reason I was thinking of large objects was that some changes to large memberships would beak varchar2 limits - but I see your comment below about using individual rows for each change.

New API methods would allow a client to query for all changes since a
certain date (filterable by object type, and optional object_id) and
would return consolidated changes for each object changed.

Pulling things out of the history table could be but needn't be in the
API per se as the table is independent of anything else.
I guess some tool to provide an interface to the history table would be useful but it could be an extension - should anyone care to write one.

The devil would be in the detail of how you represent the changes - they
need to be easily machine readable.

LDIF and RDF are both machine readable and at least one certainly has the
breadth to cover our functional domain. Probably a variation of the other
does too. So I think we've got both semantic and more traditional means
open to us.

Also, do we ‘log’ effective changes?

Current event logs do contain effective changes. We could reflect each
effective change in the history table with an additional row having the
same change number as the originating event (and transaction id, if
that's true).
My main concern here would be the number of database writes and the size of the tables, but it would certainly be easier to query.


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page