Future direction: reports founded on SQL repository.

[John Ralls]

> On Feb 5, 2015, at 2:29 PM, Allen S. Rout <asr at ufl.edu> wrote:
> 
> 
> 
> I've seen several references here to the policy direction that SQL
> (-lite or my-, or otherwise) will be the future preferred datastore.
> 
> Associated with these, there are discussions that the future of
> reporting interfaces will likely be through some flavor of reporting
> tool founded on the SQL interfaces.
> 
> There are FAQ entries which discourage SQL backend uses for most users.
> 
> I've got an itch I'd really like to scratch:  now that I'm
> programmatically submitting payments through the python API, the major
> time sink and source of error in my duties as Hackerspace treasurer are
> in clicking through the "generate a customer report for _this_ one",
> "generate a report for _that_ one".
> 
> If there's interest, I'd be interested in trying to build that report,
> and others as I come to grasp them, with a reporting infrastructure
> acceptable to the GnuCash devs.   I think I've already got a FSF
> assignment in place.  (though you don't mention that in your
> contribution FAQ page)..
> 
> 
> 
> So much for background; a few concrete questions:
> 
> + Have the GnuCash devs discussed any reporting infrastructure or
> frameworks which they would find preferable, or unacceptable?
> 
> + Are there any abstract reporting infrastructure characteristics that
> can be easily named in advance?  ("multi-platform" is the obvious start
> of that list...)  Any language-environment desires?
> 
> + I see that the Reports part of the Wishlist specifically mentions
> possibly using Python;  but recently in the mailing list, I read that
> the Python APIs aren't functioning on Windows, which makes me wonder if
> the wishlist is very far ahead of the currently achievable state?
> 
> + I see conversation about 'clickable' reports, and the wishlist
> specifically mentions Javascript in the context of the Gnucash report
> screen.   How strong is that desire?
> 
> 
> 
> Thank you for considering my message.

The only relationship we have with the FSF is that we use their license and some of their trade dress in our splash screen.

We’re not anywhere near ready to deprecate the XML backend in favor of SQL. There’s a huge amount of work to do in the core of the application before we can start on it. Consequently, we’re not really ready to specify a reporting library. On the other hand, we *would* like more thorough testing of the SQL backend, and if you can convince yourself that for your use-case it’s safe to use, meaning that you find no instances where changes go unsaved, then by all means use it and point whatever reporting tool you like at the database.

Python doesn’t come with Windows, so users have to install it themselves. The python bindings need to link against libpython, which means that we’d have to ship a full Python environment with GnuCash for users to be able to use the library, and we regard that as a non-starter. The same applies for OS X, by the way, because while OS X does ship Python, it’s a different version in every version of OS X so trying to run the installed interpreter with precompiled bindings is likely to crash.

That constraint applies to just about any “scripting” language you can think of, unfortunately. We do use Javascript in the graphical reports, but only to draw graphs of data that are extracted via Guile. The advantage of SQL is that it’s another way of getting at the data which doesn’t necessarily require access to the engine code. That frees up the use of a variety of scripting languages.

All in the somewhat distant future, though.

Regards,
John Ralls