2010/11/20 Christian Stimming <stimm...@tuhh.de>: > Am Samstag, 20. November 2010 schrieb John Ralls: >> > I have one question: are we shipping 2.4.0 with default backend SQL or >> > XML? >> >> I think we are (and should) leaving the default as XML for 2.4. There isn't >> a substantial benefit for the ordinary user to switch to sql until we (1) >> rewrite (or replace) qof so that it doesn't need to lock the whole >> database and (2) rework the backend to make better use of sql's data >> integrity features (which means moving those functions out of qof). > > Absolutely. The default "Save As" format is and should be XML, as long as > (like John said) SQL doesn't provide any user-visible benefit for the normal > user, and as long as we haven't seen this backend in error-free operation for > a time frame that starts to get comparable to the XML backend.
I certainly agree with this. I would like to add to John's comment about database backend improvements: I'd like to see the gnucash project look at using the database much more incrementally, initially loading as little of it as possible initially and then transacting during the session only with those parts of the database that are involved in whatever the user happens to be doing. This would result in reduced startup times, especially important for those, like me, who have a lot of Gnucash data. I think it would also simplify the code. In effect, a part of gnucash now is doing custom-coded database operations on an in-memory database. This stuff would be replaced by a lot less SQL code. But an important question would involve the impact on responsiveness/performance. Substituting a general-purpose disk-based relational database for custom code talking to in-memory data is likely to be slower. How much slower? It might be fast enough (these things do get used for transaction-processing, after all), it might not. And the various database choices have different performance characteristics. So this would have to be looked at carefully before committing to such an approach. (I've mentioned this before and I understand why the current version was done the way it was -- doing something like I'm suggesting would involve a lot more internal upheaval than the current db backend -- and I want to make clear that I am not criticizing that decision.) /Don > > Regards, > > Christian > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
