audit trail, take 2

Dave Peticolas dave@krondo.com
Wed, 03 Jan 2001 23:02:57 -0800


David Merrill writes:
> On Wed, Jan 03, 2001 at 05:02:15PM -0800, Dave Peticolas wrote:
> > David Merrill writes:
> > 
> > > The major changes are:
> > > 
> > > - a single table; no separate audit table.
> > > - the client doesn't work directly with guids, but instead works with
> > >   an "ID" field that does not change when records are edited. The guid
> > >   stays globally unique. The client still has access to the guid, if it
> > >   wants it.
> > > 
> > > Did I miss anything? There are so many threads going I could have very
> > > easily done that. But that's not a complaint; I'm very glad to see so
> > > many folks interested in this.
> > 
> > I'm not clear as to the difference between and purpose of
> > the xaction_guid and xaction_id fields.
> 
> The guid is specific to a record in the database. The id represents a
> transaction, but not any particular version of the transaction. If a
> transaction is changed, the guid for the new version is a new guid,
> but the same id remains.
> 
> The guid is there for those portions of the system that care about the
> specific record, as opposed to the more general transaction which can
> change and still be the same transaction. The id is there for other
> parts of the system that don't care, and only want the current
> version.

Is the xaction_id also a guid, in the sense of being globally unique?

What I'm really getting at is, for a given transaction, will there be
some 'stable' GUID with which you can quickly access the most recent
version? By stable I mean that you can always use that same GUID to
get the most recent version.

dave