Where does Gnucash save it backup files when using mysql data source

[L. D. James]

On 07/05/2015 02:27 PM, AC wrote:
> On 2015-07-05 11:05, L. D. James wrote:
>> I have never suggested backing up a database engine.  As far multiuser
>> software backup, I used Peachtree for many years.  It was a multiuser
>> environment software, and it always gave a backup option when exiting.
>> I usually performed the backups, but not all the time.
> Suggesting that the software perform an export on close when it utilizes
> a database engine for its primary data storage is indeed a backup.
>
> As for Peacthree, I took a quick look at the documentation.  It turns
> out that when you ask for a backup, it actually signals the database to
> perform the backup.  The client program does not actually do the work,
> it just acts as a messenger to deliver your request to the server.  The
> server itself performs the backup and, during the initial configuration
> of the server, it's told where to store that data.  For a multiuser
> installation, the documentation says that the storage location should be
> on a network server and not the client machine.  The true backup method
> was being hidden from the end user.  Of course, Peachtree (and the Sage
> database engine) were purpose written for that application and support
> for that was built into both the client and the server.
>
> It's a much different situation with more generic database engines like
> Oracle/MySQL, Postgres, etc.  The larger database engines (especially
> Oracle given its position in enterprise applications) have some support
> for this but it must be written in for every individual database
> created.  Gnucash would have to understand the basics of database access
> (reading/writing records) but it would also have to handle all sorts of
> concurrency and integrity controls (transactions, mutexes, semaphores,
> stored procedures, etc.) and how each engine implements them.  That is
> not an easy task and puts a significant burden on the developers.
>
>
>> I don't know of any database program, multiuser or single user that
>> doesn't have some type of export feature.  If you're suggesting that the
>> developer of Gnucash (and all other programs that have database access)
>> to discontinue allow exports I believe you are on a substantially wrong
>> tract.
> Database clients can have an export feature but it's often not a total
> export of the entire database.  More commonly it is some kind of subset
> of data (e.g. a report export, or a short date range export).  I haven't
> suggested that exports not be allowed but I don't agree that the exports
> you are looking for (which are de facto backups even if you claim you're
> not asking for a backup) are a good idea especially in a multiuser
> environment.
>
>> I'm glad the negativism that I'm receiving has not totally stopped the
>> development and consideration of mysql integration into gnucash as well
>> as the consideration for multiuser.  I spend nearly 3 years watching the
>> development before I started using it.  Most of the three years (and
>> preceding) I've saw this type of animate discouragement against the
>> growth of Gnucash.  I'm glad to see that it's grown despite the animate
>> opposition.
>>
>> The growth (myql integration) and mutiuser environment will be a benefit
>> for all.
> You may call it "negativism", I view it as a proper debate of a feature
> that is potentially dangerous to an inexperienced user and can create a
> support nightmare.  No feature in any software should ever be blindly
> accepted without discussion, that can lead to bad results.  The level of
> discourse would vary depending on the complexity of the feature.  Asking
> for a default font change from serif to sans-serif probably doesn't
> require much.  Asking for a feature that can potentially destroy a
> user's data if it is improperly implemented or utilized deserves more
> scrutiny.

That is precisely what I'm providing this input and available to assist 
in it's testing and implementation.

The locking mechanism that is suggested that needs to happen doing 
backup may not be as complicated as you suggest that it is. Currently 
when starting a new session of Gnucash, the second session does 
recognize the database is locked and informs the user.  It also gives 
the user the opportunity of overriding the lock or opening it in 
readonly mode.

There are cli features and API features to communicate to the database 
and lock the database.  Whatever you discover that Peachtree is doing 
can happen with Gnucash and Mysql.  Again with all the resistance, I see 
this coming to happen.  I'm available also to help.

People keep suggesting that just because a consideration to make Mysql 
the default storage unit, all of a sudden the database is going to grow 
so enormous that you have to spend the name or as one user mentioned 
spend a week being shutdown and backing up his 400gig database.

Even banks don't spend weeks backing up their data.  I can't imagine 
most users having to wait more than a few seconds with no access (having 
the database locked) during and export.

I have this suggestion because there will be users who will use the 
system the way it happens to be at this time.  They will connect to the 
data (currently by default an XML file) and use the override. Both will 
be working on it at the same time.  One of them will think their data 
was inputted into the system when it won't happen.

I'm suggesting resolutions that will protect the users from the problems 
that I already see.  Rather than staring out by mentioned problems as if 
I'm complaining, I'm offering suggestions and solutions.  I'm offering 
this for consideration and the scrutiny that you suggest.

I realize the database records will have to be locked.  I actually had a 
whole dialog that I was building on to present to the group of how to 
implement this using XML.  With all the resistance I'm getting, I'm 
afraid to offer the solutions at this stage.

I'll keep building them and offer them when I see more progress and less 
resistance to suggestions.

Again, there is API available to communicate with the database. Everyone 
logged in using the same application (Gnucash) will benefit from the 
API, that will only require a locked database for a second or a couple 
of seconds.  Kudos to someone who has such a huge accounting base that 
it will have to be locked for a couple of minutes rather than a couple 
of seconds.

Again, wouldn't mind helping.  I currently perform most of my database 
programing in Perl and Java.  I also use C++, but not as much... and by 
the way, I even use bash script and bare cli lines to communicate to 
some of my databases.

-- L. James

-- 
L. D. James
ljames at apollo3.com
www.apollo3.com/~ljames