r21577 - gnucash/trunk/src/backend/xml - Fix xml backend to load and save invoice kvp values.

Geert Janssens janssens-geert at telenet.be
Wed Dec 7 11:15:32 EST 2011


Op woensdag 7 december 2011 10:34:33 schreef Derek Atkins:
> John Ralls <jralls at ceridwen.us> writes:
> >     This is effectively my "feature" flags suggestion from before. 
> >     You flag (new) features as they are used, and refuse to load
> >     the database if there are used features that you don't
> >     understand.
> > 
> > Something to look at adding for 2.6 to get ready for the database
> > overhaul in 2.8/3.0. It's not in 2.4, and it would need a new "feature"
> > table to hold the features so it probably shouldn't go in.
> 
> Luckily the features table is one that doesn't affect the rest of the
> database, so we could add it in without breaking <=2.4.8; but yes, only
> versions >= 2.4.9 would know to check it, so it wouldn't necessarily
> help older versions.
> 
To avoid confusion:
You propose to add a features table for the upcoming 2.6 and backport it to 
2.4.9. So all (stable) versions as of 2.4.9 know how to handle it.

Together with this, I presume we should bump the compat version parameter, so 
that older versions of GnuCash will not attempt to load data files with that 
depend on the features table ? I don't see another way to prevent unintended 
access to newer features by older versions.

Does it have to be a complete feature table by the way ? Or is just adding a 
single number (like the minimum required gnucash version to open the data 
file) sufficient. I don't see how an older version otherwise would know what 
features to check in order to determine if it is still compatible.

Another question: who will be implementing this ? I don't feel comfortable 
enough in either backend to do this. If it weren't for Alex' example, I would 
have quite some difficulty also to simply add a new data field.

Geert


More information about the gnucash-devel mailing list