2.4.0 with XML as default (, what's left to do)

[Donald Allen]

2010/11/20 Christian Stimming <stimming at 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 at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>