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...
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
