MySQL sync
Vladimir Bashkirtsev
vladimir at bashkirtsev.com
Mon Aug 17 14:19:58 EDT 2009
Derek Atkins wrote:
> Vladimir Bashkirtsev <vladimir at bashkirtsev.com> writes:
>
>
>> Derek Atkins wrote:
>>
>>> Vladimir Bashkirtsev <vladimir at 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
>
>
More information about the gnucash-devel
mailing list