On Jun 3, 2014, at 3:24 PM, Wm Tarr <wm.t...@gmail.com> wrote: > On 25/05/2014 15:07, John Ralls wrote: >> Database support? Remember, one of the requirements is that the database >> fields need to be summable in queries, so any database we use for the >> backend has to support the numeric representation. The ones on offer in the >> popular SQL databases are 64-bit int, 64-bit IEEE 754, and in all but >> SQLite3, fixed-point. > > The conversation seems to have moved on from database support for numbers but > is it actually an issue for SQLite3 from a storage POV ? > > SQLite3 isn't as strongly typed as the other supported DB's so there is no > reason why numbers of arbitrary precision and significance couldn't be stored > just as they are / could be with XML with the added advantage that in almost > all situations it will recognise what is stored as a number and do something > sensible with it. The "is this sensible" checking would be less than > required with XML as a backend. > > It seems to me we are looking at edge cases and unless I've misunderstood gnc > doesn't actually use the underlying DB except for storage anyway. Or does > this mean a move away from XML as a reference gnc file? >
That’s the intention, yes. Depending on how things go with the engine rewrite we may not get to it for 2.8, but we do intend that GnuCash will become a proper database application that runs mostly on SQL queries. At that point the XML backend will work by loading an in-memory SQL database at load and being written out from that database at save. If SQLite3 proves unsuitable we’ll have to either extend it to make it suitable or find an alternative, because it’s the obvious choice both for an in-memory database and as a default file-based backend. Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
