Access Controls

[David Merrill]

On Tue, Jan 02, 2001 at 02:38:45PM -0600, Christopher Browne wrote:
> 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.

Yeah, I see your point. The idea was half-baked. Try this:

The guid never changes on the original record. If it is deleted, no
problemo - just move it to the audit table. If it is edited, copy it
to the audit table before changing the original. We could then have
lots of versions in the audit table, but they are all timestamped and
so we can recreate the audit trail easily. There's really no need to
even change the guid on them.

This brings back the problem I thought I had solved, which was
determining whether or not the record has changed already. Linas
suggested handling this by sending the original data along with the
updates when requesting a save. This would work, but seems kludgy. The
db then has to check, field by field, to see if it has changed.
The alternative is to assign a version number that increments each
time the record is updated. Then we need only check one field to know
if changes have been made. See any problems with that approach?

-- 
Dr. David C. Merrill                     http://www.lupercalia.net
Linux Documentation Project                dmerrill@lupercalia.net
Collection Editor & Coordinator            http://www.linuxdoc.org
                                       Finger me for my public key

We are the flow, and we are the ebb.
We are the weavers, we are the web.