Derek Atkins wrote:
Vladimir Bashkirtsev <vladi...@bashkirtsev.com> writes:
Derek Atkins wrote:
Vladimir Bashkirtsev <vladi...@bashkirtsev.com> writes:
However, changing the architecture of GnuCash to be a pure DB app would
entail rewriting MOST of the engine. I wouldn't recommend going that
route in the short term.
Well... Rewriting most of engine is definitely not something I plan. :)
So I should take on board your idea to go with audit log. It should
not be too hard to implement. Then use autoincrement in DB and have
GnuCash to check it at regular intervals and before any operation
which requires access to the data. If there's new entries in the log
then just replay them to get updated. Something tells me that ability
to store log records and ability to replay them back already is part
of the engine.
Have I missed anything? If not then I am quite excited and... (read below)
Well, right now we do not have an audit log, nor do we have a way
to replay the audit log. That would have to be developed.
Note that it might also be part of an "Undo" feature, which would
also be nice to have.
-derek
As very quick solution for semi-multiuser solution is to have only one
copy of GnuCash to have write access and rest just with read access
re-reading DB each time update timestamp is changed.
UGGH... And how do you decide which copy of GnuCash is the master
(read-write) vs slave (read-only)? And what if that copy goes away?
And how do the various GnuCash copies talk to each other?
Seriously, either do multi-user right or don't do it.. Quick hacks
like these have their own sets of issues and require just as much
programming as doing it right the first time.
Makes sense. However I need to strike a balance between what I need and
what I can contribute.
I will finish reading the source and will come back to discussion which
way it may go.
Vladimir
-derek
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
