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" <jra...@ceridwen.us> написал:
> > > On Dec 24, 2014, at 12:22 AM, Dmitry Pavlov <zeldi...@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 > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel