Grouper Developers Forum

[Chris Hyzer <>]

We should delete the grouper.properties, right?  J

 

I think in this case its not an important debate since as I said, once we have notifications ldappc wont need it…

 

It could be an undocumented property that people can use if they are having performance problems.  Or it could just be a grouper.properties config Boolean with a sentence explaining it. (default to true)

 

We are starting to layer up the queries though… a query to add a membership, a query for user audit, a query for point in time, a query for notification, and a query for lastMembershipChange… and I think we need options for all those things so people can pick and choose how much overhead they want, and/or so they have tuning options if they are having performance issues…

 

Maybe at some call with room in the agenda we should discuss when we should make things configurable and when not if we are not in agreement and this will come up a lot…

 

In general I think config options are good.  I agree with you in the findByName case (not having it configurable) since it is nice when all groupers behave alike (least surprise).  Though I also think that if there are good defaults for options, they don’t really hurt anything, and might be useful to people to change from the default at some point.  I also think that universities should package up grouper for their school and document the decisions they make to their schools/centers so they know how it is configured/run…  Finally, we need to remember to deprecate then remove old config options which aren’t useful anymore.

 

Thanks!

Chris

 

From: [mailto:] On Behalf Of Tom Zeller
Sent: Tuesday, March 17, 2009 2:40 PM
To: Chris Hyzer
Cc: Grouper Dev
Subject: Re: [grouper-dev] Draft Minutes: Grouper Call 18-Feb-09

 

I think an option to optout would be nice (so people who aren’t using ldappc don’t need two db queries for every membership change).

I agree, however...there is a balance between performance and configuration complexity (and resultant documentation) - is the performance impact significant ? Of course, one might say, yes a factor of 2, but is that really the case using hibernate-inversely-controlled-transactions ?