On Dec 7, 2011, at 8:15 AM, Geert Janssens wrote:
> Op woensdag 7 december 2011 10:34:33 schreef Derek Atkins:
>> John Ralls <jra...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
