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

[John Ralls]

On Dec 7, 2011, at 8:15 AM, Geert Janssens wrote:

> 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.
> 

I'd do it as a table with a feature name and a boolean "is-used" in SQL, and 
<xs:element name="features" required="true">
    <xs:element name="feature_name" required="false" multiple="true">
          <xs:attribute name="is_used" required="true" type="boolean"/>
    </xs:element>
</xs:element> 
in XML. (Sorry for the syntax, I'm pretty rusty at XML-Schema and didn't go look up the right attribute names.)
Gnucash would scan the table for any features with is_used="true" that it didn't know about and would raise an error if it found one. When writing it would add to the features table/element any new features that it knows about with is_true set appropriately.

The devil is in the details for knowing that it has written data that only a feature would know about. 

We should probably change the load logic in the SQL backend to query for specific field names instead of SELECT * and rely on the fields being presented in the right order while we're at it. That would be a lot more robust, and not just in the face of changing schema: SQL doesn't actually guarantee that fields will be returned in any particular order from a SELECT * , it just usually works out that they are.

I don't think that we can get this ready for a release this weekend....

Regards,
John Ralls