sqlite file format, anyone?

[Derek Atkins]

hi,

First, please learn to use the "enter" key.  Netiquette suggests
a hard 'enter' every 72 characters.

Second, the developers made a concious decision that the minimum
resolution is 1024x768 and have taken great efforts to make sure
the standard distribution works on that resolution.  In that vein
we decided that 800x600 was "too small" to display all the information
we want.  Considering that the only machines that are limited to 800x600
are at least 4-5 years old at this point, we decided this was
"reasonable".

As for your sqlite suggestion, I looked into it and honestly
I'd rather use embedded-mysql.  Indeed, I was planning to build
an embedded-mysql backend, but I was waiting for Matthew to finish
the postgres re-write in order to share SQL.

One of the major problems with SQLite is that it doesn't have any
data types.  They may consider this a feature, but I consider it a
bug.  It means that the application needs to do all the conversions
instead of the SQL engine.  Why not centralize that functionality
instead of forcing all application writers to re-implement the same
bindings?

Admittedly, a benefit of SQLite over MySQL is that it uses a single
file as oppsed to a directory of files (one file per table).  But
the ability to have automatic structural dis/integration by the SQL
engine implies an easier-to-codify implementation.  Having to write
all the code to sql-ize and de-sqlize all the gnucash objects is
a PitA -- mysql gives you tools to help.

Having said that, I encourage you to submit bug reports and patches.
I also encourage you to work with Matthew and other developers to
improve the SQL backend(s).  As I mentioned earlier I was planning to
implement an embedded-mysql backend, but I haven't started yet.  My
hope is that we can build a common schema across all SQL engines that
we support (hopefully not TOO many ;) and can build a common set of
SQL generation functions (and maybe even query-response parsing
routines, but that might be harder).

I also encourage you to show up on irc.gnome.org, channel #gnucash.

Thanks!

-derek

"Ben & Michelle Carlyle" <fuzzybsc at optusnet.com.au> writes:

> G'day,
> 
> I've just been discussing a few issues relating to gnucash on my local home user group lists[1]. The story so far is that I'm very impressed with the capabilities of gnucash, and although I've run into a large number of small issues they for the most part make me want to contribute rather than abandon gnucash. I've been coming from a windows/quicken background and have been considering gnucash as a replacement for my personal finance tracking currently done by that product. My experimental setup as a P133 laptop with 800x600 LCD display. The laptop runs a debian distrubution and it was the debian standard package I used to install.
> 
> I've seen plenty of problems working at this resolution with gnucash 1.8.4. In fact it's very difficult to use many features and impossible to use others. 1024x768 seems to be ok. I have several suggestions about improving the import mechanisms for QIF files. I think the loan druid and the mechanisms to do the scheduled transactions for loans could do with a little refinement. I have a full list of my early impressions which I may present at a later time, but I'd prefer to do so with patches in-hand. Anyway. That's not what I'm here to talk about.
> 
> Members of my user group have motivated me to ask about contributing to what I saw as the greatest current deficiency of gnucash going forwards as a personal finances application, and that is the load/save philosophy when it comes to files. Unlike quicken which saves transactions as they are entered, gnucash's file backend requires the entire file to be saved manually by a user. In my experimentation I encountered three seperated occasions under which gnucash locked up[2] and I lost valuble time associated with entering transactions. I've been running a side-by-side configuration with quicken and gnucash both keeping identical record sets during my experimentation. If I'd only been running gnucash I would have lost the transactions completely and would likely have had a hard time reconstructing where I was up to.
> 
> The lockups I can live with. They're to be expected in relatively new code. They occur with terrible regularity under Quicken. I have no problem with that. Such problems can be fixed on a case-by-case basis or design re-engineered as appropriate. The time wasted re-entering my data, though, made me lose much of my goodwill for the gnucash project. After a little prompting I downloaded the gnucash source and for the moment at least my goodwill is greatly increased as a result of seeing the backend module associated with PostgreSQL.
> 
> I don't want to run PostgresSQL. I'm not a database admin. I'm a senior software engineer for my company who has about four years experience developing rheems of code for a top-end civil engineering software project for railways in Hong Kong and other systems around the world. I do SCADA systems.
> 
> As part of my work I ran across a program called sqlite[3]. sqlite is a portable[4], fast, transaction-safe database engine which runs as a C library, and keeps each database in a single filesystem file. No special maitanence is required for the file. The library can be statically or dynamically linked. sqlite is widely used. There's a debian package, and many other packages available. sqlite is not just free software, but public domain software so can be used pretty much anywhere you like. I've used sqlite in largeish commercial applications and have been very pleased with the performance and simplicity, even when files became very large (64-bit file handles are supported).
> 
> This brings me to your PostgreSQL backend. I have a deep desire to mate the gnucash and sqlite technologies using a backend based-on or in a similar vein to the PostgreSQL backend. I know this is a bold statement, but my gut feeling at the moment is saying that it could become a better "standard" file format than the xml version (at least as long as the XML format doesn't support transactions). I don't want to lose my data, nor do I want others to lose their data.
> 
> The question is, if I do this work and it is good is there a chance of it being accepted into the base as an optional file format which doesn't require explicit saving? I suppose another obvious question is, "Have I correctly interpreted the use of the PostgreSQL as being a no-save data format".
> 
> Finally, I'd be very interested in all the advice that the gurus associated with this project could offer before I embark on such a major undertaking :)
> 
> If I do find the support to proceed I'll be working in my spare time outside my office hours and hours of unpaid overtime :) I don't want to do something that won't have the support of the general community.
> 
> Right now I'm quite fired up about the possibility of having a replacement for my Quicken accounting system that meets all of my needs. If I can defeat this hurdle I'll be very interested in contributing further work as gnucash will undoubtably become my new home accounting system. Pehaps I'll even be able to work together with some local business-people to help add an Australian bent to the system, both in terms of Australian personal tax law and business tax issues such as GST (an issue also found in Canada).
> 
> [1] www.humbug.org.au
> [2] Locked up, as in became unrepsonsive and had to be killed. No cpu was being used, and it usually occured as the result of pressing a button or tab on a gnucash display
> [3] www.sqlite.org
> [4] At least windows, all the traditional unicies, linux etc, and various embedded environments
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available