Subject: Grouper Developers Forum
- From: "GW Brown, Information Systems and Computing" <>
- To: Chris Hyzer <>, Grouper Dev <>,
- Subject: Re: [signet-dev] hooks poc (proof of concept)
- Date: Wed, 11 Jun 2008 10:46:17 +0100
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.
--On 11 June 2008 03:32 -0400 Chris Hyzer
I did a proof of concept on group and membership hooks, here are the
examples, issues, and implementation details...
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
GW Brown, Information Systems and Computing
- hooks poc (proof of concept), Chris Hyzer, 06/11/2008
- Re: [signet-dev] hooks poc (proof of concept), GW Brown, Information Systems and Computing, 06/11/2008
Archive powered by MHonArc 2.6.16.