MySQL sync

[Vladimir Bashkirtsev]

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