Backwards compatibility with new currency issue and bug 336843.

[John Ralls]

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.

Regards,
John Ralls