On Fri, 2011-04-22 at 10:51 -0700, John Ralls wrote: > Correct. I think we need to do a better job of decoupling the backends > from the internal data structures. Part of that should be to move most > of the "scrubbing" functions to the XML backend and to either make the > XML backend more flexible or to have more than one, for different > versions of the XML schema. (The SQL backend is already quite flexible > (good job, Phil): Its schema is data-driven, albeit with compiled-in > data -- but that can be fixed with a very few lines of code. ) With > that decoupling, the 2.2/2.4 backends (this applies to both XML and > SQL) can continue to save the former KVP fields in the KVP way and > newer backends can do whatever we think is most efficient at the time.
I did spend a bit of time thinking about moving the schema into the object so that the backend would ask for it - what info do you want me to store and in what format? Got me thinking about Memento design pattern and other ideas like that. I never carried through with it, although I did view gobject-ification and accessing values via gobject_get()/gobject_set() as a step forward in that. > One of the absolute worst aspects of the KVP design, BTW, is that it > breaks object integrity. Instead of passing a data structure to an > object as asking the object to deal with it, code all over the place > gets a pointer to the top KVPFrame and has its wicked way with the > contents so that the object has no idea what it has. Very naughty, > indeed. True. However, it allows other code to attach information to objects and then retrieve it. Maybe we should replace it with an "attach-struct-by-name"/"retrieve-attached-struct-by-name" idea. The tax code, instead of storing KVP values, would create a GncTax structure and use gnc_instance_attach_struct(myAccount, myTaxStruct, "tax") and retrieve it with (GncTax*)gnc_instance_get_attached_struct(myAccount, "tax"). Then, when an account was saved, the tax code (and other bits of code which attach to an account) would be called to save their individual structs. When an account is loaded, same thing. This kind of idea could easily work for the sql backend. The XML backend could embed a <tax> ... </tax> substruct inside <gnc:account>...</gnc:account> Obviously, this would break backward compatibility before 2.4, so perhaps the tax code would need a convert_from_slots() method to go along with load_your_stuff() and save_your_stuff(). Phil _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
