On Dec 8, 2011, at 6:33 AM, Derek Atkins wrote: > John Ralls <jra...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
