[Fwd: Re: SQLite and transactional security]

Matthew Vanecek mevanecek at yahoo.com
Thu Sep 11 23:26:42 CDT 2003


2On Thu, 2003-09-11 at 19:25, Benjamin wrote:
> In another interesting twist the last time I mentioned sqlite on this 
> mailing list one of the biggest hurdles to acceptance seemed to be the 
> lack of time and date functions. Experimental time and date functions 
> have now been introduced into the latest sqlite versions.
> 

Gnucash itself already provides some pretty decent date/time functions. 
Considering the typeless nature of SQLite, those should do fairly well. 
I.e., you store a Timespec as "2003-09-11 07:45:56.034289 -0400" in
SQLite (well, in PG, too), and SQLite gives you back the same (PG gives
you back the appropriate timestamp for the PG server).  You
automatically run the timestamp string through the gnucash
"timestamp-to-local-timestamp" function, and voila! you have your local
timestamp.


> I have read through the pg backend a few times, now, and I think I have 
> the basic philosophies understood. I'm still coming to terms with a 
> wider understanding of the qof and higher-level constructs. Perhaps I'll 
> have a go at porting the pg backend over to sqlite at some point, unless 
> someone has a better idea about a starting point. I am currently on 
> holidays so the heat at work is off for the moment, but I'm buying a 
> house as well so I don't necessarily have a lot of time :) I will give 
> it a go, though. No promises about completion.
> 

Our current direction is to use libdbi, which allows the use of multiple
DBMSs.  SQLite is of interest due to its single-file nature, but it
would still be accessed via libdbi.  The current PG backed is somewhat
limiting because it is so difficult to extend.  The query-building code
especially is fraught with danger under some circumstances
(specifically, Transaction Searches), although by-and-large it does a
decent job of generating 'working' SQL.  But it can't be extended easily
or cleanly.  So I'm rewriting that, as well as changing to the libdbi
model.

My goal is to generate ANSI SQL from Gnucash QofQueries, which means
that the DBMS used should support ANSI SQL.  I think MySQL is the only
DBMS under consideration that is not ANSI SQL-compliant.
-- 
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20030911/9ab42ddd/attachment.pgp


More information about the gnucash-devel mailing list