On Thu, Jan 04, 2001 at 12:51:44AM -0600, Christopher Browne wrote:
> On Tue, 02 Jan 2001 15:54:53 EST, the world broke into rejoicing as
> David Merrill <[EMAIL PROTECTED]> said:
> > 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
> > > [EMAIL PROTECTED] 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.
>
> That sounds quite reasonable.
Yes, and it really does away with the need for a separate table. Look
at my post from yesterday, titled "audit trail, take 2", for my
current plans.
> > 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?
>
> I think it needs more than just a version number.
>
> Suppose two independent updates try to take place "concurrently."
>
> One goes in, as "version 4," and another goes in, also proposed as
> "version 4." If all that is tracked is the version number, then
> the second update gets silently ignored. Bad Thing.
The new design is to use a guid which changes with each revision, and
an id that remains stable across revisions. No version number.
--
Dr. David C. Merrill http://www.lupercalia.net
Linux Documentation Project [EMAIL PROTECTED]
Collection Editor & Coordinator http://www.linuxdoc.org
Finger me for my public key
White magic is poetry, black magic is anything that actually works.
-- Victor Anderson
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
