Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

Chris,

You've been busy! - and as ever the devil is in the detail so doing the 
proof of concept throws up a number of issues and is a really valuable 
exercise.

A couple of thoughts:

1) In the case where an object is created and there is no business object 
yet, could that be fudged by having a 'read-only' subclass of, say, Group? 
Attempts to call 'write' methods would throw IllegalStateExceptions or 
similar.

2) You describe a save method which now must be called after setting 
description, extension, and, I presume, after adding custom types and 
setting custom attributes? Does this mean that the create will happen 
without the need for a save? Not necessarily a big deal if all further 
attribute changes are treated as one change and can be vetoed.

The save method is quite a big change to how things currently work i.e. all 
code out there dealing with attributes would need to be updated - so we'll 
need to strongly advertise the change. Is there a way of throwing an 
exception if there are unsaved changes when we commit the transaction?

Will there be an addMembers method which can be treated as one change?

3) The issue of not having all the relevant details e.g. group name and 
subject id / source available could be addressed by modifying queries and 
some objects. Just because the database schema is normalised doesn't mean 
that our objects have to be i.e. we can query for group name and subject 
id/source when we query for memberships and have the values available - in 
fact I did something similar for 1.2 - but the change got lost when we 
shifted to Hib3 because I'd updated HibernateMembershipDAO and not 
Hib3MembershipDAO.

Whilst profiling I noticed that when listing memberships the API would do 
one big query to get the memberships but then, for each row, do a query to 
get the member details - and then do another query to get the subject 
details. In HibernateMembershipDAO I changed the method:

public Set findAllByOwnerAndField(String ownerUUID, Field f)

so that the query looked like:

select ms, m from HibernateMembershipDAO as ms, HibernateMemberDAO as m

I then added a method to take the results and return them as 
MembershipDAO's with MemberDAO's already set. I then added LazySubject - 
which can do .equals / hash operations without an actual Subject lookup - 
these only need subject id/type/source. A request for attributes would 
cause LazySubject to instantiate a Subject and delegate the call to it. 
This approach was much faster.

Gary

--On 11 June 2008 03:32 -0400 Chris Hyzer 
<>
 wrote:

> I did a proof of concept on group and membership hooks, here are the
> examples, issues, and implementation details...
>
>
>
> https://wiki.internet2.edu/confluence/x/zl0
>
>
>
> Let me know asap via email or in the call if there is a reason to not
> continue coding in this direction.
>
>
>
> Im having some scheduling issues during the call tomorrow... I will be on
> the call, but might not have 100% attention (and don't mind screaming
> kids in the background)  J
>
>
>
> Regards,
>
> Chris



----------------------
GW Brown, Information Systems and Computing