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

Geert Janssens geert.gnucash at kobaltwit.be
Mon Nov 5 15:11:40 EST 2018


Op maandag 5 november 2018 20:16:04 CET schreef 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

You have found us :)

Just reply to this e-mail message (use reply-to-all or reply-to-list in your 
mail client) and your answer will appear on gnucash-devel.

Regards,

Geert

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






More information about the gnucash-devel mailing list