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: "GW Brown, Information Systems and Computing" <>
  • To: Tom Zeller <>
  • Cc: Grouper Dev <>
  • Subject: Re: [grouper-dev] changelog implementation sketch
  • Date: Fri, 06 Jun 2008 09:27:49 +0100


comments below. Also, the change_number is always 001 in the examples. I assume it is incremented with each change?


--On 05 June 2008 15:24 -0500 Tom Zeller

On Thu, Jun 5, 2008 at 1:08 AM, GW Brown, wrote:

2) Calling Stem.setExtension and / or Stem.setDisplayExtension also
changes any descendant group extension / displayExtension, each of which
might be a separate or subordinate notification. The current table would
group changes by transaction but if we need to record multiple changes -
to support querying by object and object type - we should know the
'parent' change.

3) In a similar vein to 2) each group that has its effective membership
changed should be recorded as a subordinate change.

OK, I've updated the examples with a parent change identifier column.
The stem extension change example show the object_type for the stem as group...

4) When a group is deleted there may be effective membership changes
elsewhere. It also becomes impossible to work backwards to reconstitute
the group - unless the current state of the group immediately prior to
deletion is 'stored'. We could in principle work forwards from the
beginning of time, or a snapshot taken at a known time.

For some changes, we might include a snapshot representation of the group
immediately prior to the change, either in the change representation
itself (which seems non-standard for LDIF and difficult for pluggable
representation implementations) or a 'previous_representation' column or
a separate (linked) table. I don't think we would want to do this for
every change, for performance reasons.
If we were using LOBs I think Oracle restricts you to one per table, so a separate table might be best. A group representation could be pretty big - and relatively expensive to generate but it could be made optional

5) If a group type is removed from a group we also lose the ability to
work backwards to reconstitute any custom lists for the type

I'm not clear on the above, makes sense though...could you provide more
details please ?
If you remove a type which has custom lists you will also remove all the members of those custom lists. In this case I guess the 'delete' ldiff could simply list all subjects which were removed vs list name - potentially a large change

7) The table should include who made the change

Right, the examples now contain subject_id and '...' meaning other
columns, such as Chris' suggestions like act_as_subject_id, etc.

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?

Thanks for your comments!

GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page