Grouper Developers Forum

[Chris Hyzer <>]

This is to summarize the discussion we had yesterday about hooks and 
notifications

I will do a proof of concept in two weeks.  This will be about groups (and 
maybe memberships if there is time).

We decided:

1. No multiple event registration, implementers can call multiple methods 
from one hook point, and API hooks will just be in the API
2. The hook will be transactional or not in Grouper (not transactional 
currently in Signet)
3. The hook will receive the object which is currently being operated on
4. The hook implementation class will extend one of several hook classes, and 
one or many methods can be overridden

We didn't decide these, but we have discussed them in previous meetings

1. Vetos are communicated with a subclass of RuntimeException (since Grouper 
API is heavily nested, and don't want to add a bunch of boolean returns)
2. Hooks are synchronous.  The hook API will make it easy to do part of the 
hook implementation logic asynchronously (3 lines).  (Since not multiple 
hooks, and people will generally want synchronous for non-notification hooks, 
I think all should just be synchronous.

####################################

We talked about changes to the Grouper API.

The problem is that the DB layer is now transparent, and there are long 
running transactions.  So:

group.setDescription("whatever")

Generates:  update grouper_groups set description = "whatever" where uuid = 
"sdffdskjljdfg"

(granted this is actually a grouper_attribute, but this isn't an exact 
example :) ).

So what we need is either:

a. high level method which does multiple things at once:

group.assignFields(name, description, nameFriendly, attributes)

-or- b. we need to change the existing methods to not generate sql:

group.setDescrition("whatever");
group.setAttribute("a", "b");
group.save();

We think that (a) will have the least impact on the existing code and unit 
tests, but (b) is really the right thing to do.  I will take a look.

Also, we discussed long running transactions again.  The issue is that there 
are three levels to the DB layer.

- the transaction: from when the tx starts to where the commit happens.  This 
is out of the control of the Grouper API, and this is the way we want to keep 
it
        - where we want the hook point: this is some operation on the object 
model.  E.g. change the description and attributes of a group
                - the sql (hopefully we can move this up to where the hook 
point is)

I didn't really take notes of the discussion, if I left anything out, let me 
know.

Regards,
Chris