Report wrapper to call python scripts?

[Dmitry Pavlov]

Personally, i'm still on file storage so based on that maybe it's a good
time now to look at sql one and try migrate to it and gain advantage of sql.
24 дек. 2014 г. 19:54 пользователь "John Ralls" <jralls at ceridwen.us>
написал:

>
> > On Dec 24, 2014, at 12:22 AM, Dmitry Pavlov <zeldigas at gmail.com> wrote:
> >
> > A brief search through list did not bring any results, so I decided to
> > start a new one.
> >
> > First of all: no offence but most gnucash reports are poorly implemented.
> > It's not because they useless or looks not pretty (most of them are
> useful
> > and good, calm down :)) . The reason is that a model (i.e. data of the
> > report) is completely messed up with the view (html tags) in report
> > generation code + html creation tag by tag is really outdated now, there
> > are more proper tools like templates for that.
> >
> > Of course it's a really huge work to rewrite that completely in more
> > model-view style or rewrite that in different language.
>
> Not only no offense, no kidding!
>
> >
> > So I have idea: Gnucash already have an infrustructure of invoking scheme
> > reports, saving settings, etc.
> > What about implementing some "wrapper" report that can just invoke some
> > script (for example that use python bindings). In it's settings we can
> > point to specific script and all guile invocation would just
> > 1. include execution of that script with passing parameters from options
> > 2. grab output that is supposed to be report content (html for now) and
> > include that as it's own result
>
> Isn't our report system already too complicated?
>
> Geert has already mentioned that we're going to re-engineer GnuCash to use
> a SQL database internally; this is our plan for implementing concurrent
> multi-user access. That alone will vastly simplify the reporting
> architecture. It will also mean that SQLite3 rather than XML will be the
> preferred file format for most users and MySql or PostgresQL for those who
> need multi-user capabilities or who like running a DB Server. That in turn
> moves the preferred mechanism for custom reporting entirely out of GnuCash:
> Simply fire up your SQL report generator of choice, write your query, and
> run the report.
>
> You can actually do that now, as long as you don't trip over one of the
> corners where GnuCash writes to KVP without doing an edit-commit on the
> object owning the KVP. I can't say that it's the recommended approach for
> all custom reporting because of those corners, but if you can satisfy
> yourself that the SQL backend works correctly for your usage it's certainly
> easier and more future-resistant that writing a custom report in Scheme.
>
> Regards,
> John Ralls
>
>