[GNC-dev] [GNC] mysql backend, second user (lock, for example)

[Craig Arno]

Geert,

I just subscribed to the gnucash-devel mailing list.  Where do I find
the list so I can find and respond to your message?  I also need to
respond to Phil's message, in gnucash-devel.

Short answer, no we do not have different ideas.  I need to help you
understand my answer.  Looks like Phil is sharing the same confusion as
you, so must have been my wording.  I'd be happy to straighten this out
in gnucash-devel as soon as I can figure out how to get there, and spare
all the good users here from technobabble.

Craig


On 11/5/2018 1:49 AM, Geert Janssens wrote:
> Op maandag 5 november 2018 08:36:25 CET schreef craigarno:
>> Geert Janssens-4 wrote
>>
>>> Op zondag 4 november 2018 14:49:22 CET schreef craigarno:
>>>> Geert Janssens-4 wrote
>>> Whether it can work depends on
>>> whether the db layer we rely on has a notification mechanism for db
>>> changes we
>>> can hook into. The current db layer is provided by libdbi, which is not
>>> managed by the gnucash team and I haven't looked into this yet.
>> If your call to libdbi is in the same thread and is a blocking call for
>> synchronous operation, then there shouldn't be a problem with updating views
>> after successful return from the libdbi call.  Otherwise you may have to
>> look for semaphors to signal.
> This discussion really belongs on gnucash-devel. It's way to technical for the 
> gnucash-user list. So I have moved it, please follow up on the gnucash-devel 
> list.
>
>
> It looks like we are having a different idea of the network model gnucash will 
> use. I'm getting the feeling your idea is that gnucash will turn into a 
> client-server model, with the server part running on a server and a  client 
> interacting with this server. This is not the current design idea.
>
> The current plan is to have a desktop application that can connect to a 
> database using database semantics (row level locking, ACID support). But there 
> will be no gnucash server component as such. That database can be accessible 
> over the network from different gnucash programs installed on different 
> computers (and ideally devices). But that's where our current plan ends. And 
> in this design I don't think there's an easy way to manage coordinated view 
> updating across devices. I don't think you can have for example mysql signal 
> changes to a client application (though I may be mistaken). So while the 
> design will allow concurrent db access and modification, it will not allow 
> keeping views in sync without active db polling.
>
> But perhaps if we get to the point where the core functionality is separated 
> in it's own library, it should at least be easier for someone to write a 
> client server system on top of that.
>
> Regards,
>
> Geert
>