Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

Tom,

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

Gary

--On 05 June 2008 15:24 -0500 Tom Zeller 
<>
 wrote:

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



----------------------
GW Brown, Information Systems and Computing