Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Re: GRP-146

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Re: GRP-146


Chronological Thread 
  • From: "Tom Zeller" <>
  • To: "Chris Hyzer" <>
  • Cc: "" <>
  • Subject: Re: [grouper-dev] Re: GRP-146
  • Date: Tue, 2 Sep 2008 16:45:34 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=uNxHwc0o6RAmV/rgPScaWnGEsFjSLkJKja/bKv9fHEueEGm1PTy63RV1BuLPmHLAZ0 XvE/0Q92mN9RnfV0/+L44t9PEAzo5YLnB6ABqk+Tql8r+oRi8h6EGTiJE/WSngLtCsHd j7jD4DxHA7nEW6RyAHm9RP8FURw0C1ZuUzTPQ=

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





Archive powered by MHonArc 2.6.16.

Top of Page