Grouper Developers Forum

[Chris Hyzer <>]

Here is the email that was requested to be re-sent out for community response.
The two items that we didn't discuss in the previous grouper call were 
discussed today in the signet call without dissent.

Thanks,

Chris

> -----Original Message-----
> From: Chris Hyzer
> Sent: Thursday, May 29, 2008 11:24 AM
> To: Grouper Dev; 
> 
> Subject: hooks and notifications summary
>
> 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
>
>
>