Backwards compatibility with new currency issue and bug 336843.
jralls at ceridwen.us
Tue Nov 19 17:56:23 EST 2013
On Nov 19, 2013, at 2:47 PM, Frédéric Perrin <fred at fperrin.net> wrote:
> Le mardi 19 à 23:38, Frédéric Perrin a écrit :
>> Le mardi 19 à 23:05, Derek Atkins a écrit :
>>> On Tue, November 19, 2013 4:58 pm, Frédéric Perrin wrote:
>>> 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.
>> That would also limit the modifications to the commodity class, rather
>> tham having each backend checking whether the commodity is used.
>> The attached patch compiles and seems to do what we want from 5 minutes
>> of testing.
> That won't fix files that have been edited between the addition of the
> new currency and the installation of this patch. Do we care ?
Actually, between the addition of stuffing the user_symbol KVP with the
symbols from iso-codes. That’s about a month.
I don’t want to say that we shouldn’t care, but I don’t think we should
worry too much about it. We’ve been pretty clear that 2.5.x shouldn’t be
used for production data.
More information about the gnucash-devel