Questions about the Backend Interface

[linas@linas.org]

It's been rumoured that Derek Atkins said:
> 
> Thanks.
> 
> More responses inline...
> 
> Dave Peticolas <dave@krondo.com> writes:
> 
> > The rollback is supposed to undo any changes which have been made
> > since TransBeginEdit and restore the transaction to its original
> > state. Restoring the data is actually done by the engine, so I'm
> > presuming that backends would implement this by releasing any locks,
> > etc. that were created by trans_begin_edit. Presumably, single user
> > backends have no need to implement this callback. Linas will know
> > more about this, though.

Rollback for transactions in the multi-user case is sort of broken.
If the data in the database is newer than whats in the engine, then
any proposed updates from the user must not only be rejected, but the
newer data from the database must also be pulled in.  This isn't done
yet.

One other little problem: 'rollback' is used in two, unrelated ways.
1) by the gui, to implement 'undo'
2) by the engine, (when the above paragraph gets fixed).  Some work
   needs to be done to disambiguate the above.

> That's what I thought.  Since all the edits are done in the engine
> cache, the backend really just needs to unlock the structure.  Is
> there any reason that we don't have a rollback on an account edit,
> too?

Not yet implemented; see above.

> > > 	3) The 'sync()' operation seems to be an extremely heavy
> > >            operation, especially for a networked backend.
> > 
> > The operation is probably going to change. It is invoked by both
> > 'Save' and 'Save As' functionality. But backends which implement
> > the 'fine-grained' backend calls (like the sql backend) don't
> > need to do anything during a 'save'. So the call will probably
> > be split into two calls for that reason.
> 
> Fair enough...  Although I'm not exactly sure how 'save-as' will work
> for a fine-grained backed.  

As it currently works, its a mass-copy of all data out of the gnucash
engine into the named storage location.  

If the indicated storage location doesn't exist, its created, and
all of the engine data is copied into it.

If the storage location (i.e. database) does exist, and contains data,
then the engine contents are merged into it.

----
>From the engine point of view, the above is the easiest thing to do.
However, in some cases, it may not be what the user is expecting.
For example: in the (unfinished) multi-user mode, the engine does
*not* contain a full copy of the database data; instead, it contains
only a subset.  A 'save as', if implemented as above, would save only
that subset, instead of all of the data.   If the user thought 'save as'
means the same thing as 'copy', they would be sorely disappointed. 
I don't currently have an opinion on the 'best' way of dealing with this
situation.

> I thought of another issue..  There doesn't appear to be a way for the
> backend to notify the engine that and account or transaction was
> deleted out from under it.  

Or merely changed, for that matter.  At some point, we'll need to work
with Dave to fiugre out how to use the event system so that a backend
can notify the engine that some other user has modified data.

> This is probably related to question #2
> below.  Unless I'm missing something, during a sync operation there is
> no way to tell the difference between a "new" object or an object that
> was deleted in the backend.

Ummmm, ahhh, ohh... deleted splits are accounted for since we can detect
that the number of splits in a transaction has changed.  But if the
entire transaction was deleted by some other user, then the engine 
currently would conclude that what it has is something new, not
something deleted.

I see two ways of fixing this.
1) Keep a master list of all transactions.  If a transaction is not in
   the list, it should be deleted. (since, in theory, there is nno way 
   to create a new transaction wihout putting it on the list).

2) Keep an audit trail of modified & deleted transactions; and check
   that.

I admit, the multi user case, with data caching in the engine, is
proving more complex & harder to implement than I anticipated.  Where I
last left it, account balances were giving me heartaches.

--linas