On Fri, Nov 14, 2014 at 3:31 AM, Derek Atkins <warl...@mit.edu> wrote:
> Sébastien de Menten <sdemen...@gmail.com> writes: > > > Where could I find detailed documentation on the GnuCash engine (and the > > constrains/invariants GnuCash enforces) ? Or would there be some > > code/program to check a GnuCash file is "sane/consistent" ? > > Only in the implementation. There is no documentation per se on this, > because we do not support modification of the database from outside the > GnuCash APIs. This also allows us to change the underlying storage > mechanisms without breaking things, because it's all abstracted. By > re-implementing it you're basically binding yourself to a particular > version of the database schema, which can (and will) change over time, > requiring you to duplicate the effort already happening in the gnucash > code. > > Moreover, you're also tied to a particular backend, which isn't very > nice. > > Indeed, piecash is only applicable to the SQL backend and depends on the version of the "SQL schema" used by GnuCash. But as GnuCash is rather good at keeping backward compatibility, my fears are not so high in this respect (we can a minor changes but that is ok). I can add a check on the different rows of the VERSION table to ensure explicitly that the schema has not changed. A major rewrite of GnuCash and/or the SQL backend would require a major rewrite of piecash, but that's OK, we are talking about 500 SLOC. If you want to modify the gnucash database, you really should use the > exported GnuCash APIs. > > If the current python bindings aren't pythonic enough for you, then I > urge you to spend the time to fix that instead of reimplementing > something that will absolutely break some time in the future. When it > will break I cannot tell you, but I can assure you it WILL break at some > point. > > I agree, it requires indeed to follow the evolution of GnuCash SQL schema. But these changes are well documented in the changelog. The official python bindings are C/SWIG based and are more complex to understand than the 500 SLOC of piecash. I have a preference to work with piecash even if I understand that it fragments the python bindings situation. But ok, I can't forbid myself to scratch this itch :-) kind regards, Sebastien _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel