Grouper Developers Forum

[Chris Hyzer <>]

My point is just to update timestamps for rows that are updated, not foreign keys (maybe with the exception of group attributes J ).  So if a membership is updated, update the membership last updated col (or insert it), not the group last updated col…

 

From: [mailto:] On Behalf Of Tom Zeller
Sent: Tuesday, September 02, 2008 5:46 PM
To: Chris Hyzer
Cc:
Subject: Re: [grouper-dev] Re: GRP-146

 

For provisioning, I think we talked about using a membership timestamp as part of a notification queue before and we weren't sure how to handle deletions. We then talked about auditing, or keeping memberships (almost) forever but marked as deleted. So, if we don't have one queue, then we need to store deleted memberships until they are processed by the provisioner.

 

Am I understanding your idea correctly ?

 

TomZ

 

On Tue, Sep 2, 2008 at 2:01 PM, Chris Hyzer <> wrote:

This tangential idea isn't for 1.4, but long term... I mentioned this before...

If we are going to have hibernate optimistic locking on (which prevents multiple users overwriting each others changes), then it would be nice if changing membership information doesn't update the group's last modified date (only editing the group or perhaps attributes should do that).  Think long term we could have a membership (or whatever else ancillary) column for last modified, and ldappc or other provisioners can use each of these instead of one monolithic queue?  I think performance of regular grouper operations would improve also since there would be fewer queries...

Thanks,
Chris

> -----Original Message-----
> From: Tom Barton [mailto:]

> Sent: Tuesday, September 02, 2008 2:56 PM
> To:
> Subject: Re: [grouper-dev] Re: GRP-146
>
> Good.
>
> Chris Hyzer wrote:
> > Ok, that makes sense.  I see only GroupModifiedAfter used in ldappc,
> so I removed group_modified_time_idx from my list of recommended ones
> to remove...  sound good?
> >
> > Thanks!
> > Chris
> >
> >> -----Original Message-----
> >> From: Tom Barton [mailto:]
> >> Sent: Tuesday, September 02, 2008 2:44 PM
> >> To:
> >> Subject: Re: [grouper-dev] Re: GRP-146
> >>
> >> These filters are used by Ldappc, I think.
> >>
> >> Chris Hyzer wrote:
> >>> The filters would use the indexes.  I see these filters available:
> >>>
> >>> GroupCreatedAfter
> >>> GroupCreatedBefore
> >>> GroupModifiedAfter
> >>> GroupModifiedBefore
> >>>
> >>> StemCreatedAfter
> >>> StemCreatedBefore
> >>>
> >>> Just curious, where are these filters used?  Or what would a use
> >>> case
> >> be?
> >>> I could see the created_by and modified_by being used when changing
> >> someone's member_id (jira issue open for this), though I think that
> >> is such a seldom used feature it might not require an index...
> >>> Thanks,
> >>> Chris
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Tom Barton [mailto:]
> >>>> Sent: Tuesday, September 02, 2008 12:50 PM
> >>>> To:
> >>>> Subject: [grouper-dev] Re: GRP-146
> >>>>
> >>>> Emily Eisbruch wrote:
> >>>>> [A1] {Group} will review and provide thoughts on GRP 146.
> >>>>> https://bugs.internet2.edu/jira/browse/GRP-146
> >>>> Regarding the suggestions for the grouper_groups table
> >>>>
> >>>>      - drop: group_createtime_idx
> >>>>      - drop: group_creator_idx
> >>>>      - drop: group_modifier_idx
> >>>>      - drop: group_modify_time_idx
> >>>>
> >>>> do we need to maintain group_createtime_idx and/or
> >>>> group_modify_time_idx to support corresponding GrouperQuery
> filters?
> >>>> Similar question for grouper_stems.
> >>>>
> >>>> Tom
> >>>>
> >