reporting, again aka python for people (was: History Quotes)

[John Ralls]

> On Nov 14, 2015, at 8:52 PM, Edward Doolittle <edward.doolittle at gmail.com> wrote:
> 
> On 14 November 2015 at 18:02, Sébastien de Menten <sdementen at gmail.com>
> wrote:
> 
> On Sat, Nov 14, 2015 at 3:35 PM, Wm... <tcnw81 at tarrcity.demon.co.uk> wrote:
>> 
> 
> 
>>> ===
>>> Some thoughts:
>>> 
>>> at the moment (I think) piecash can only talk to GnuCash's data if it is
>>> in SQL.  How much work would be involved in getting piecash's SQLAlchemy
>> to
>>> read [1] XML?  Do you think the effort would be worth it?  My concern is
>>> that even if piecash or similar is the route to reporting freedom there
>>> will still be some people that will resist changing file format even if
>>> they are told "it is all sql inside!"
>> 
> 
> 
>> piecash is based on sqlalchemy to connect all tables together and take care
>> of the sql transactions (commit, rollback, etc). Adapting it to XML would
>> mean rewriting all the GnuCash logic to manage SQL transactions (which are
>> free with sqlalchemy) => not sure it fits the approach.
>> 
> 
> 
>> Would you see specific issues with going sqlite vs XML ? for most of users,
>> it is rather transparent (except if the user wants to process XML but then
>> piecash is not relevant). Going postgres or mysql is another story and is
>> more relevant for advanced users wanting to access their gnucash books
>> from multiple locations in a 'server' mode (vs a 'dropbox' mode).
> 
> 
> Here's an ugly hack: Currently GnuCash gives the option to save data in XML
> or sqlite. Why not both XML and sqlite? I'm guessing that it shouldn't be
> too hard to activate both.
> 
> Then the issue would be keeping the XML file and the SQL file in sync.
> Here's one way: If the SQL file were modified by an external application,
> say, then GnuCash could be opened, reading the SQL file, then writing both
> the XML and SQL. Same if the XML file were modified: read the XML then
> write both the XML and SQL.
> 
> Scripts that accessed either of the saved files (XML, SQL) would have to
> check that the file it used was at least as up-to-date as the other before
> generating reports and/or making modifications.
> 

Ugly indeed and pointless as well. We’re not going to change our policy that the only supported way to modify the GnuCash database, whether SQL or XML, is through the GnuCash API and using that API gives the external program the ability to read and write either XML or SQL.

Regards,
John Ralls