Entity-Relationship Diagram

Phil Longstaff plongstaff at rogers.com
Fri Apr 22 14:20:18 EDT 2011


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



More information about the gnucash-devel mailing list