Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] changelog implementation sketch

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] changelog implementation sketch

Chronological Thread 
  • From: "Tom Zeller" <>
  • To: "GW Brown, Information Systems and Computing" <>
  • Cc: "Grouper Dev" <>
  • Subject: Re: [grouper-dev] changelog implementation sketch
  • Date: Fri, 6 Jun 2008 09:06:22 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=loh75gZrpiUl6Xv4lwJo709QaUqhDc2Tu0KXMjdIld73Q+etPoNSC0i7D+oiBM4ewQ gre2dTSdiNb0ryVak6PqBvpou4N1KLHNhYiwJ38WbB4TpDDmW89YSE2+ylcmSxR0/63o o6E/NVbB3gRZHCTKrE2nr1JdLHNYT7mR2NS5w=

On Fri, Jun 6, 2008 at 3:27 AM, GW Brown <> wrote:
Also, the change_number is always 001 in the examples. I assume it is incremented with each change?

Yes, I've made that more obvious now.
The stem extension change example show the object_type for the stem as group...


8) We should also audit/notify when a Member's subject id is changed

I've worked out an example for this. 

Interesting. Strictly speaking we don't remove/add members where we change subject id, on the other hand consumers of the affected groups would probably want to 'know' about such changes. Possibly we could indicate the member_uuid as well as the subject identifiers without implying and add/remove?

 Ah, right, membership persists when subject ids change as far as grouper is concerned. Perhaps consumers would just have to know whether or not to ignore consequent membership changes in the same change as a subjectId modification.

This seems similar to a 'delete group' where additional information (representation of the object(s) prior to or after the change) would be useful.

Jokingly (you know, XML solves everything) I once typed up


but we might as well cook up our own XML representation of changes then.

Maybe grouper objects (groups, members, memberships, subjects, stems, fields) should each have their own LDIFy representation with an identifying objectclass which might make such representations easier, dunno, I will experiment more.


Archive powered by MHonArc 2.6.16.

Top of Page