AUDIT: r15205 - gnucash/trunk - Load and store a commodity's KVP-frame (IFF it's non-empty).

[Christian Stimming]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek Atkins schrieb:
> 1) This patch doesn't actually change any data formats, because there's
>    no data in those fields.  So without additional changes (which I agree
>    should not get backported), there's no chance of a data format change.

Does that mean this code doesn't write any data (in the KVP fields) if
and only if there isn't any data written during runtime? If yes, then
I'd happily accept that code, BUT we'd have to be really sure we don't
accidentally back-port any of the code that would introduce data into
those kvp fields.

> Keep in mind that just making the XML parser not blow chunks on
> unrecognized tags isn't sufficient -- we also need to re-write out
> those unrecognized tags or we destroy data.   Reading and silently
> discarding is worse than erroring out.

*sigh* You're probably right, although a crashing gnucash is always not
a good thing. We should have some different method available if users
want to read a non-backward-compatible file, with the clear notion that
this will almost certainly mean data loss. Something like "Import
gnucash file from other version" or similar.

> So, I argue that this change still is safe because it's effectively
> unused code, but it would let us add additional information in a 2.2
> release and not destroy that data in 2.0, which is why I think we should
> backport this change.

I agree on the backport.

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQCVAwUBRX7IH2XAi+BfhivFAQKQNgQAsTOv6O3XpNqsbPCY8hnIrQhX7N/EuxOc
Og4ZMbaKtPWVvuyWQeGGx3NsSqo00O1QZRXLIOqaJUhz0u6Hal5wGrfzu0YtPnXv
BWKXldvrFeVHFqSERmgGMLPjl3xqmMGpkJDsu/FZsYfHm4KIBJ4J+pRNbJ11bJWx
LQG8MyCcmOc=
=lwvE
-----END PGP SIGNATURE-----