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

[Derek Atkins]

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.

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

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

> Regards,
> John Ralls

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available