Audit Logging, User Roles

[John Hasler]

Christopher Browne writes:
> Hmmm...  If an "entry" is superceded, then we're left with two entries:
> a) The original one, which is, in effect, no longer valid, and to which
>   nothing should, any longer, point.

> b) The new one, superseding the original, to which everything should _now_
>   point.

> Unfortunately, this leaves us in danger of being backed into the corner
> where changing an entry results in having to cascade changes to all the
> database records that refer to the entry.

How about attaching a rule to the corrected entry to return the correcting
entry?


> Thus, we have, in such a table, fields:
>  a) prGUID [private GUID] [primary key for the table; unique, not null]
>  b) GUID [public GUID] [secondary index for the table; unique, nulls allowed]
>  c) parentGUID [Parent GUID] [another index on the table; NOT unique, nulls forbidden]

> When a record gets created, the sequence might be thus:
> -> Generate a new private GUID, put it in prGUID
> -> Generate a new GUID to be used publicly, put it in field GUID.
> -> Also put the second GUID in field parentGUID

> When a record is superceded, the procedure might be thus:
> -> Generate a new private GUID, put it in prGUID for the _new_ record.
> -> Fill in the "rest of the new record."
> -> Set field GUID for the new record to have the GUID field value from
>    the previous version.
> -> Set field parentGUID to have the same value found in field GUID.

> -> For the record that is being superceded, set field GUID to null, so
>    that it disappears from the purview of the usual processes that will be
>    looking for non-null GUID values.

I considered something similar. but I don't want to do anything but append
new records to the journal.


-- 
John Hasler
john@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI