It's been rumoured that Derek Atkins said:
>
> Thanks for the reply. Comment inline...
>
> <[EMAIL PROTECTED]> 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 :)
I think I want to retract some of my comments. By default, when the gui
calls xaccTransRollback(), it will merely restore the data that was
previously cached in the engine. And should mostly be enough: its highly
unlikely that some other user changed the very same transaction, so its
a waste of bandwidth to have to double-check with the server.
In the event that the server data *did* change, then the 'standard'
way in which the server notifies changes should be sufficient, and
special 'rollbck' handling isn't really needed ...
> So there is plans to have an 'account rollback' method (to rollback
> edits to an Account*)?
Yes.
> 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?
Well, there's two ways that its important to support:
a) its the only way (currently) of copying data from a prexisting file
to a database. Its how one would migrate into sql.
b) off-line operation: Say a user builds up a cache of data, saves
it to a file, edits it off-line (e.g. while sitting at the airport)
and then comes back on-line. The user will then want to 'sync'
i.e. copy thier modified data into the server.
Scenario b) needs work. What we have is almost right, but both the GUI,
and a crisping up of the semantics is needed.
> 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.
Yep, that's what I would have recommended.
> > account balances were giving me heartaches.
>
> even know how account balances are supposed to work,
well, if the engine has *all* of the splits in an account, it totals
them up to get the running balances. But if it has a subset of all
splits, then ... let me leave it at tat .
--linas
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
