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

Geert Janssens geert.gnucash at kobaltwit.be
Mon Nov 5 04:49:34 EST 2018


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




More information about the gnucash-devel mailing list