Grouper Developers Forum

[Chris Hyzer <>]

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).

Do we need this on stems for ldappc or other reasons, or only groups?  I know I added the col to stems, but I don’t remember where that came from…

 

Thanks

Chris

 

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

 

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. 

https://bugs.internet2.edu/jira/browse/GRP-228

 

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