On Nov 19, 2013, at 2:47 PM, Frédéric Perrin <[email protected]> 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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
