Questions about the Backend Interface

[Derek Atkins]

Thanks for the reply. Comment inline...

<linas@linas.org> writes:

> 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.

Ok, so the rollback method implementation needs to get a return value
from the actual data store (RPC Server in my case) in case the txn
changed.  This implies the client must send not only the txn guid but
also the version number, and the return may include a new transaction.
Good thing to know :)

> > 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.

So there is plans to have an 'account rollback' method (to rollback
edits to an Account*)?

> 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.

Hrm.  Perhaps certain back-ends might not support a 'save-as', or do
all backends need to do it?  Indeed, I'm not even convinced that
'save-as' makes any sense in a database or server-based backend.  So,
perhaps we just shouldn't provide the option for those types of
backend?

> ----
> 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.

Well, I guess it depends on what the user expects, doesn't it?  Worse,
what might happen depends on what the backend is.  I think a 'copy
file' might require specific calls to the backend, although how would
you 'copy file' from one backend type to another?  A large can of
worms, I agree.

> > 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.

Agreed.  Shouldn't be too hard.  I just need to know what functions to
implement, and the client will just receive them from the server and
signal an event to the GUI.

> > 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.

The latter is certainly a reasonable option, although both would work.
In my case, I'm actually depending on the engine (and another backend)
to perform the actual data storage behind the RPC server.

> 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.

I'm just working on 'single-user' but I'm still only dealing with
cached transactions.  I'm still coding my 'first attempt', so I don't
even know how account balances are supposed to work, or what
information I need and when I need it.

> --linas

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available