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

[John Ralls]

On Dec 8, 2011, at 6:33 AM, Derek Atkins wrote:

> John Ralls <jralls at ceridwen.us> writes:
> 
>>> 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.)
> 
> Actually, we could cheat...  We could store it in the Book's KVP Frame!
> Then all we need to do is add code to 2.4.x that looks for the frame and
> if it exists at all the fail to load the data (because it should be
> empty).  Then in 2.6 we create the frame IFF we use a "new feture"
> (e.g. credit notes) -- and we also check the frame for features we know.
> 

Yes, we could. But I prefaced it with "I'd do it", and I want to move away from using KVP...
However, as a quick way to get it into 2.4, KVP is a good idea.

>> 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.
> 
> I don't think the latter part is necessary.  I think you only need to
> add items where 'is_used=true'.  I don't see why you need to add any
> 'is_used=false' items.

I thought about that, but the idea of a table containing only primary keys was too weird. 
> 
>> The devil is in the details for knowing that it has written data that
>> only a feature would know about.
> 
> True.
> 
>> 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 thought we already did that?

I'll look again, but it sure looked to me on Tuesday that load uses SELECT *.
> 
>> I don't think that we can get this ready for a release this weekend....
> 
> No, probably not..  At least not for SQL.  I think the XML can be done
> (throw an error if you see anything) in time.

Actually, just checking for the existence of any keys starting with "feature" in the Book's KVP and raising a GNC_BACKEND_TOO_NEW could be done pretty quickly in both.

Regards,
John Ralls