Access Controls

[Christopher Browne]

On Tue, 02 Jan 2001 14:23:22 CST, the world broke into rejoicing as
linas@linas.org  said:
> It's been rumoured that David Merrill said:
> > 
> > I read this again and changed my mind, and I'll tell you why...
> > 
> > When a record is changed, it is moved to the audit table, and a new
> > record is generated. That means a new GUID as well. So if the record
> > exists in the transaction table, it is necessarily the same "original"
> > data.
> 
> Maybe we are using guid's for too many conflicting purposes? 
> 
> It seems that we need another identifier that says 
> 'this is the same record, even though we've been editing it.'
> 
> For example, don't splits store the guid's of thier parent accounts?
> If you edit an account, and issue it a new guid, don't you have to
> walk a zillion splits to update thier guid's as well ??

Yes, indeed, this seems an overly conflicted use of GUIDs.

I _thought_ the point of the exercise was for the GUID to represent
a permanent unique identifier for an object.

If it changes, that seems to me to be a Bad Thing.

There _is_ a reasonable policy to use for this that seems rather
a lot less abusive:

-> Generate a new GUID for each entry that gets added to the "audit log."

-> The audit log should _also_ include a reference to the "active"
   transaction's GUID, so that one may trace from audit log to the
   current version of the transaction, and, if there is an index on
   audit_log-oldGUID, from transactions to audit log.

Thus, the active transaction doesn't get a new GUID value all the time.

If there are processes out there that need to know when a particular
transaction changes, it makes sense to have something analagous to the
CORBA Notification or Event services rather than changing GUIDs all the
time.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
<http://www.hex.net/~cbbrowne/>
Early to rise,
And early to bed,
Makes a man healthy
But socially dead.