Backwards compatibility with new currency issue and bug 336843.
derek at ihtfp.com
Tue Nov 19 17:05:46 EST 2013
On Tue, November 19, 2013 4:58 pm, FrÃ©dÃ©ric Perrin wrote:
> Hi Mike,
>> The new ZMW currency was introduced in May with r22965, commit
>> ab0cfdce5a. Reverting the commit fixes the problem, but obviously this
>> is not a "fix" and the problem lies elsewhere.
>> I'll file a bug for this, I mention here only as information for
>> anyone following the bug 336843 thread.
> I haven't found the bug report in Bugzilla, have you had time to open it
> yet or is my search-fu lacking ?
> Anyway, this is due to r23345 : since we set the user_symbol of every
> currency at startup, the KVP of every currency, even those not used, now
> contains simething. Therefore, in gnc_commodity_dom_tree_create(),
> kvpnode is !NULL, and every currency gets dumped to the XML file at save
> time. That includes the new ZMW, and when your old gnucash that doesn't
> know about ZMW sees that currency, it aborts with "Invalid commodity".
> I suppose we don't want to dump every currency into the save file
> whenever the file is written. Do we want to check currency->usage_count ?
> Do we want an API Bool gnc_account_currency_used(Account, gnc_commodity) ?
> Thoughts ?
I would recommend we do something slightly different. I would have TWO
setter functions, a "set_default()" as well as a "set()". The
gnc_commodity object can be extended to cache the value. The
set_default() would only set the cached value. The set() function would
both set the cached value *and* set the kvp. The get() function could
first check the kvp() and, if that is empty or non-existing it can use the
cached value. Either that, or at load time we cache the value from the
kvp if it exists and then get() only needs to read the cached value.
Derek Atkins 617-623-3745
derek at ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
More information about the gnucash-devel