recovery

[Josh Sled]

"Keith A. Milner" <kamilner at superlative.org> writes:
> On Wednesday 31 October 2007 07:02:16 Tarlika Elisabeth Schmitz wrote:
>> On Tue, 30 Oct 2007 20:55:07 -0600
>> I can see that it would be too slow to save a 13MB xml file after every
>> transaction. Why use xml anyway?
>
> Looking at the archives, I believe the current XML database was inherited by 
> the current devs. It seems everyone (or at least most people) agree that XML 
> is not the correct format to store the data in (great for data interchange, 
> not for storage).
>
> Changing this is a significant task, and one which few appear to be willing to 
> undertake, especially as it's likely to break some things and remove 
> some "back-door" capability that some people use.
>
> At one point there was a project to provide an optional PostgreSQL database 
> instead of the XML one. This is a fine idea in many environments as it can 
> provide multi-user capability, proper database referential integrity, better 
> data recoverability, etc.
>
> My understanding is that this project was never "finished" in that it's not 
> well supported and doesn't support some functionality which many consider to 
> be essential (such as business features, invoicing and such). I'm not sure 
> what, if any, plans there are for this.
>
> However, I believe that the overhead and complexity of setting up and 
> maintaining a postgreSQL database server is overkill for many people, who are 
> happy with a "local" file format, but would benefit from something better 
> than the current XML format. I wonder if this is part of the reason the 
> postgreSQL support seems to be going nowhere.
>
> Musing: perhaps there is some benefit in bundling a local, lightweight 
> database such as SQLite with Gnucash as a backend instead of the current XML 
> one, with the option to change this to PostgreSQL for users who want this. 
> Obviously this would require full support of the current business features as 
> well.

The PostgreSQL backend is quite dead; there is a more recent effort to get a
DB-agnostic GDA-based backend into gnucash, but it is proceeding slowly.

The desire is – as you suggest – to use sqllite as the default "file"
backend, replacing XML, to prevent the "DBMS setup overhead" for normal
users, but allow Postgres, MySQL, &c. for other users.


Tarlika Elisabeth Schmitz <gnucash at numerixtechnology.de> writes:
> In my view, the end user should not have to dig around log files in
> order to recover. Quicken does not need to to recover after a crash as
> every transaction is saved when committed. When OpenOffice crashes, you
> simply press a recover button. Would that not be possible with gnucash?

Of course it's possible; anything is possible.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20071031/d105f5f4/attachment.bin