Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Draft Minutes: Grouper Call 18-Feb-09

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Draft Minutes: Grouper Call 18-Feb-09


Chronological Thread 
  • From: Shilen Patel <>
  • To: Chris Hyzer <>
  • Cc: Tom Zeller <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] Draft Minutes: Grouper Call 18-Feb-09
  • Date: Tue, 17 Mar 2009 14:26:18 -0400

I wasn't as much concerned about the database constraints.  But rather I was thinking about the default behavior.  By default, last_membership_change should get updated on membership changes.  Sound good?  Do we still want a configuration option to disable the use of last_membership_change (so that neither modify_time nor last_membership_change are updated on membership changes)?

Thanks!

-- Shilen


On Mar 17, 2009, at 1:58 PM, Chris Hyzer wrote:

> Thanks TomZ.  I'll make the last_membership_change column mandatory then unless somebody has an alternate opinion.  Also, Chris added getLastMembershipChange()
> for both groups and stems.  I'm also going to be adding query filters for the new column.  So I think LDAP-PC can either use getLastMembershipChange() or the query
> filters (that will be added soon).

What does mandatory mean?  Non null in the DB?  Its hard to add non-null cols in a DB independent way (ddlutils like to create a temp table, move all data, drop original table, recreate with non-null col, copy all data back, delete temp table)… one thing we could probably do if we really wanted is if the table doesn’t exist, create it as non-null, and if it does exist, without that col, just add as nullable…  
 
Anyways, that constraint isn’t all that useful in my opinion anyways since if the group doesn’t have any members, the last_member_change col should be null.  And even if it is non-null it doesn’t mean we are updating it on every membership update, it doesn’t prevent against stale data… so I say leave it as is (nullable)
 
Thanks,
Chris
 
 
 
 
From: Shilen Patel [] 
Sent: Tuesday, March 17, 2009 1:53 PM
To: Tom Zeller
Cc: Grouper Dev
Subject: Re: [grouper-dev] Draft Minutes: Grouper Call 18-Feb-09
 
 
On Mar 17, 2009, at 1:44 PM, Tom Zeller wrote:


Grouper Call 18-Feb-09**
 
[AI]  (TomZ) will confirm that Ldappc uses query filters to determine when a group was last modified. 
 
Last Membership Update Issue
 
Shilen:  Should we prevent updating the modifyUUID and modifyTime for a group or stem when a member or privilege is added or deleted and instead create last_membership_change attributes on groups and stems?
 
How would this affect Ldappc, which does membership updates based on the time the group was last updated?
 
TomZ will look into possible dependency with Ldappc: 
[AI]  (TomZ) will confirm that Ldappc uses query filters to determine when a group was last modified. 
 
Chris noted that, long-term, if Ldappc is moved to notifications, then we may not need the last_membership_change field at all. 
 
[AI] (Shilen) will create a Jira item for the UUID and last membership update issue. 
 
Ldappc calls group.getModifyTime() to determine if a group has been modified recently. If the last time of a membership change is not available, then ldappc will have difficulty determining groups that need to be updated.
 
Perhaps we should make the last_membership_change attribute/column mandatory, and provide another method to return the last membership modification time, e.g. group.getMembershipModifyTime().
 
[I've added this comment to jira]
 
TomZ
 
 
 
Thanks TomZ.  I'll make the last_membership_change column mandatory then unless somebody has an alternate opinion.  Also, Chris added getLastMembershipChange() for both groups and stems.  I'm also going to be adding query filters for the new column.  So I think LDAP-PC can either use getLastMembershipChange() or the query filters (that will be added soon).
 
Thanks!
 
-- Shilen




Archive powered by MHonArc 2.6.16.

Top of Page