Except for a number of bugs (and a lot of testing, and a load/save UI), the GDA backend basically works for the objects outside of the business objects. I also want to add an audit trail for changes and version support to detect when a db needs to be updated to a newer version.
Some thoughts: - the GDA backend pulls the data from the engine objects and builds an INSERT/UPDATE query using the values. This requires the backend to know what values/types need to be persistent. - the GDA backend pushes data from the db into the engine objects using the standard exposed API. This leads to a commit which is not needed because the data has just been loaded. There also, occasionally, seems to be some special magic that happens (e.g. convincing the Account to sort/provide the running balance when splits are loaded). Proposed solution: - convert the rest of the engine objects to be based on GObject - create a new GObject interface which has methods for 1) getting a dictionary of persistent data for the object 2) getting/setting persistent data. The goal would be to have the engine object and its class have a bigger role in defining the db table columns in order to better encapsulate persistence information in the engine objects. The backend would then be required to transfer the persistence information for an object to/from the db or file. Thoughts? Phil _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
