Re: File Format : XML v MySQL / postgres / sqllite

[ebridges]

Hi,

Just catching up on the archives and came across this thread.

I began work about a month ago, for my personal use, of a simple easy-to-use
way to quickly get information out of a Gnucash Database:
https://github.com/ebridges/accounting-reports

Right now it's pretty minimal (balance reports, chart of accounts), but
could work as a way to illustrate how to use Piecash.  As well, I'm open to
suggestions (and PRs :-)) to improve it!

Cheers,
Ed




--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: File Format : XML v MySQL / postgres / sqllite

[cicko]

Hi, David,

Whether PyCash is for an average user really depends on what you consider
the average user to be. It is a Python library and, if you don't expect an
average user to know how to write Python code then no - it is not for an
average user.
What it offers, though, is a pure Python interface to a GnuCash book, which
needs to be stored in SQL format. This makes it cross-platform and takes the
compilation of custom GnuCash binaries out of the loop (definitely not for
an average user). Until Python bindings are complete and available on all
platforms, it is a wonderful alternative way to read your data and generate
any sort of report or action (I like to see the upcoming scheduled
transactions without starting GnuCash and eventually trigger some action).
In addition, it allows writing data, too, but one has to be well aware that
this is raw access to data and excludes any GnuCash business logic and
validations with the checks and balances that guarantee the consistency of
the records. It is a 3rd party component from the GnuCash point of view and
does not have any endorsement or support by GnuCash. Writing data for some
simple cases, or when you know exactly what you are doing (by checking the
GnuCash source, for example) is fine. I.e. I have a price importer for
Vanguard Australia retail funds and exchange rates. Somehow I find it easier
to implement the custom logic in Python than install another platform and
the system for downloading prices, which for some reason I also had issues
setting up.
Once you know what PieCash does, and check the great documentation with
examples, you can decide if it would help you with what you are trying to
achieve.
Cheers 



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-User-f1415819.html
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
If you are using Nabble or Gmane, please see 
https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: File Format : XML v MySQL / postgres / sqllite

[Sébastien de Menten]

It is indeed a python package so typically you write a script. For
instance, create the file test_piecash.py with the content

# start of the file
import piecash
book = piecash.open_book("/the/path/to/your/gnucash-book.gncash")

for transaction in book.transactions:
print(transaction.post_date)
for split in transaction.splits:
print("  ", split.account.name, split.value)
print()
# end of the file

and then run it with "python test_piecash.py" and you will see all your
transactions printed (do not forget to change "
/the/path/to/your/gnucash-book.gncash" with the path to your real gnucash
file save in the SQLite format).

You can see other examples of use in the piecash doc (like on
http://piecash.readthedocs.io/en/latest/tutorial/index_existing.html#access-to-objects
)

I was answering to this thread as the topic was about the file format and
how to access the file outside gnucash ... but indeed, it requires some
programming skills (but python is one of the most accessible language out
there).

If you have further questions or remarks that are piecash specific, better
to post on https://groups.google.com/forum/#!forum/piecash

kr

sebastien

On Sun, Jan 28, 2018 at 12:58 PM, David T.  wrote:

> For what it’s worth, I was able to execute “sudo pip install piecash”
> successfully, but there is a gap for me at this point: what next? Is there
> a python shell? Am I supposed to write a script file (and once written,
> would I use some python command to run it? Which command?)? What, exactly,
> did I install?
>
> Clearly, piecash isn’t for the average end user…
>
> David
>
>
> On Jan 28, 2018, at 4:31 PM, Sébastien de Menten 
> wrote:
>
> Editing a gnucash book via piecash is not the approved way of doing it
> (advice from the gnucash core team that recommends to go through the
> gnucash engine) but a very nice way ;-)
>
> However, for reading gnucash books, it is an alternative as they are many
> to choose (to read from XML, to read from SQL, ...)
>
> On Jan 28, 2018 12:03, "D"  wrote:
>
>> Sébastien,
>>
>> I know that users are advised not to edit their Gnucash data directly; is
>> piecash an approved application to edit Gnucash data directly?
>>
>> David
>>
>>
>> On January 28, 2018, at 3:41 PM, Sébastien de Menten 
>> wrote:
>>
>>
>> David,
>>
>> This is one of the key reason for piecash to exist as it does not need
>> any compilation (it is a pure python package) and works even without having
>> gnucash installed.
>> It doesn't use gnucash libraries as it reads (and writes) directly to the
>> gnucash book through SQL.
>>
>>
>> I do not have a Mac so I can't test the installation directly but it
>> should be just a matter of installing the "piecash" package available on
>> PyPI (the python package index).
>>
>> Sebastien
>>
>> On Jan 28, 2018 08:00, "David T."  wrote:
>>
>>> Sebastien,
>>>
>>> The problem isn’t with Python (I am told that Macs already have Python
>>> on them). The problem as I understand it (John will no doubt correct me
>>> when my statements prove ill-informed or flat out wrong) has to do with the
>>> fact that GnuCash requires a specific version of Python, which can only be
>>> guaranteed by compiling GnuCash with the current version of Python. Short
>>> of shipping GnuCash with a complete Python installation, the only way
>>> around this is for individual users to compile locally. Which, as I noted,
>>> is a painful process for me. But thanks for the information.
>>>
>>> David
>>>
>>>
>>> On Jan 28, 2018, at 11:55 AM, Sébastien de Menten 
>>> wrote:
>>>
>>> Hello David,
>>>
>>> Regarding the use of python on windows and Mac, Anaconda has made a huge
>>> difference in the last years providing all packages in an easy precompiled
>>> version.
>>> You can have a look at https://conda.io/docs/user-
>>> guide/install/macos.html for the installation (which is simple and does
>>> not require any compiler).
>>>
>>>
>>> On Jan 28, 2018 05:42, "D"  wrote:
>>>
 Ah, yes that was my incorrect reference. Sorry for the crossed
 reference.

 I will note that my confusion stems in part from the fact that, as a
 Mac user, I have never used anything to do with python and Gnucash, on
 account of the high barrier to install the proper toolsets (i.e., compiling
 yourself). My previous attempts at this process always ended in frustration
 and failure. As a consequence, when I see anything that mentions python and
 Gnucash, my eyes glaze over.

 In the past, there hasn't been much to recommend beating my head
 against that wall, but perhaps the time has come to see what happens at
 this time, since there eh to be increasing numbers of ways to use python
 with Gnucash data.

 David

 On January 28, 2018, at 12:55 AM, John Ralls 
 wrote:

 I 

Re: File Format : XML v MySQL / postgres / sqllite

[D via gnucash-user]

Sébastien,

I know that users are advised not to edit their Gnucash data directly; is 
piecash an approved application to edit Gnucash data directly?

David

On January 28, 2018, at 3:41 PM, Sébastien de Menten  
wrote:

David,


This is one of the key reason for piecash to exist as it does not need any 
compilation (it is a pure python package) and works even without having gnucash 
installed.

It doesn't use gnucash libraries as it reads (and writes) directly to the 
gnucash book through SQL.



I do not have a Mac so I can't test the installation directly but it should be 
just a matter of installing the "piecash" package available on PyPI (the python 
package index).


Sebastien


On Jan 28, 2018 08:00, "David T."  wrote:

Sebastien,


The problem isn’t with Python (I am told that Macs already have Python on 
them). The problem as I understand it (John will no doubt correct me when my 
statements prove ill-informed or flat out wrong) has to do with the fact that 
GnuCash requires a specific version of Python, which can only be guaranteed by 
compiling GnuCash with the current version of Python. Short of shipping GnuCash 
with a complete Python installation, the only way around this is for individual 
users to compile locally. Which, as I noted, is a painful process for me. But 
thanks for the information.


David



On Jan 28, 2018, at 11:55 AM, Sébastien de Menten  wrote:


Hello David,


Regarding the use of python on windows and Mac, Anaconda has made a huge 
difference in the last years providing all packages in an easy precompiled 
version.

You can have a look at https://conda.io/docs/user-guide/install/macos.html for 
the installation (which is simple and does not require any compiler).



On Jan 28, 2018 05:42, "D"  wrote:

Ah, yes that was my incorrect reference. Sorry for the crossed reference.

I will note that my confusion stems in part from the fact that, as a Mac user, 
I have never used anything to do with python and Gnucash, on account of the 
high barrier to install the proper toolsets (i.e., compiling yourself). My 
previous attempts at this process always ended in frustration and failure. As a 
consequence, when I see anything that mentions python and Gnucash, my eyes 
glaze over.

In the past, there hasn't been much to recommend beating my head against that 
wall, but perhaps the time has come to see what happens at this time, since 
there eh to be increasing numbers of ways to use python with Gnucash data.

David

On January 28, 2018, at 12:55 AM, John Ralls  wrote:

I suspect David was thinking of CuteCash, Christian Stimming’s experimental Qt 
GUI.

Regards,
John Ralls

> On Jan 27, 2018, at 10:44 AM, Sébastien de Menten  wrote:
>
> Hello David,
>
> I saw you were mentioning piecash in your message. If you talk about
> http://piecash.readthedocs.io/en/latest/, it is not a proof of concept for
> a frontend but an alternative to the gnucash python bindings to work with
> gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
> MySQL) and is alive and maintained (last release on the 20th December 2017).
>
> The following article https://arachnoid.com/gnucash_utilities/ shows some
> interesting use cases for it.
>
> With gnucash 3.0, piecash will also allow you to write your own reports
> using si python and jinja2 (work in progress).
>
> For people interested to contribute, https://github.com/sdementen/piecash.
>
>
> On Jan 27, 2018 18:27, "D via gnucash-user" 
> wrote:
>
> Mike,
>
> There is nothing new as far as I know about the file formats. You are right
> that the primary benefit to using sql is being able to generate data sets
> from sql that can used in reports. Processing a data file is no quicker in
> sql, since it all gets loaded in at start up. Sql, moreover, adds a
> database manager role to the mix; many users are not prepared to learn how
> to manage a database platform to manage their financial accounts.
>
> I stick with the XML because it also can store the data compressed; when
> dealing with the main data file and all its copies, the difference between
> 3mb and 13mb adds up quickly.
>
> Piecash, as I understand it, was a proof-of-concept experiment to see
> whether a python front end could be designed. It has not been maintained
> for some years now, and I recall recent discussion about changing its
> status with the project.
>
> As far as I know, there has been no change in recommendation to stay with
> xml.
>
> David
>
> On January 27, 2018, at 12:13 PM, Adrien Monteleone <
> adrien.montele...@gmail.com> wrote:
>
> I switched from XML to SQLite about a year ago. I perceive a performance
> improvement on loading, but that’s about it. (and I generally never shut
> the app down anyway)
>
> I haven’t attempted any custom reporting yet, but I plan to.
>
> I could be mistaken, but I think PyCash is 

Re: File Format : XML v MySQL / postgres / sqllite

[Sébastien de Menten]

David,

This is one of the key reason for piecash to exist as it does not need any
compilation (it is a pure python package) and works even without having
gnucash installed.
It doesn't use gnucash libraries as it reads (and writes) directly to the
gnucash book through SQL.


I do not have a Mac so I can't test the installation directly but it should
be just a matter of installing the "piecash" package available on PyPI (the
python package index).

Sebastien

On Jan 28, 2018 08:00, "David T."  wrote:

> Sebastien,
>
> The problem isn’t with Python (I am told that Macs already have Python on
> them). The problem as I understand it (John will no doubt correct me when
> my statements prove ill-informed or flat out wrong) has to do with the fact
> that GnuCash requires a specific version of Python, which can only be
> guaranteed by compiling GnuCash with the current version of Python. Short
> of shipping GnuCash with a complete Python installation, the only way
> around this is for individual users to compile locally. Which, as I noted,
> is a painful process for me. But thanks for the information.
>
> David
>
>
> On Jan 28, 2018, at 11:55 AM, Sébastien de Menten 
> wrote:
>
> Hello David,
>
> Regarding the use of python on windows and Mac, Anaconda has made a huge
> difference in the last years providing all packages in an easy precompiled
> version.
> You can have a look at https://conda.io/docs/user-guide/install/macos.html
> for the installation (which is simple and does not require any compiler).
>
>
> On Jan 28, 2018 05:42, "D"  wrote:
>
>> Ah, yes that was my incorrect reference. Sorry for the crossed reference.
>>
>> I will note that my confusion stems in part from the fact that, as a Mac
>> user, I have never used anything to do with python and Gnucash, on account
>> of the high barrier to install the proper toolsets (i.e., compiling
>> yourself). My previous attempts at this process always ended in frustration
>> and failure. As a consequence, when I see anything that mentions python and
>> Gnucash, my eyes glaze over.
>>
>> In the past, there hasn't been much to recommend beating my head against
>> that wall, but perhaps the time has come to see what happens at this time,
>> since there eh to be increasing numbers of ways to use python with Gnucash
>> data.
>>
>> David
>>
>> On January 28, 2018, at 12:55 AM, John Ralls  wrote:
>>
>> I suspect David was thinking of CuteCash, Christian Stimming’s
>> experimental Qt GUI.
>>
>> Regards,
>> John Ralls
>>
>> > On Jan 27, 2018, at 10:44 AM, Sébastien de Menten 
>> wrote:
>> >
>> > Hello David,
>> >
>> > I saw you were mentioning piecash in your message. If you talk about
>> > http://piecash.readthedocs.io/en/latest/, it is not a proof of concept
>> for
>> > a frontend but an alternative to the gnucash python bindings to work
>> with
>> > gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
>> > MySQL) and is alive and maintained (last release on the 20th December
>> 2017).
>> >
>> > The following article https://arachnoid.com/gnucash_utilities/ shows
>> some
>> > interesting use cases for it.
>> >
>> > With gnucash 3.0, piecash will also allow you to write your own reports
>> > using si python and jinja2 (work in progress).
>> >
>> > For people interested to contribute, https://github.com/sdementen/p
>> iecash.
>> >
>> >
>> > On Jan 27, 2018 18:27, "D via gnucash-user" 
>> > wrote:
>> >
>> > Mike,
>> >
>> > There is nothing new as far as I know about the file formats. You are
>> right
>> > that the primary benefit to using sql is being able to generate data
>> sets
>> > from sql that can used in reports. Processing a data file is no quicker
>> in
>> > sql, since it all gets loaded in at start up. Sql, moreover, adds a
>> > database manager role to the mix; many users are not prepared to learn
>> how
>> > to manage a database platform to manage their financial accounts.
>> >
>> > I stick with the XML because it also can store the data compressed; when
>> > dealing with the main data file and all its copies, the difference
>> between
>> > 3mb and 13mb adds up quickly.
>> >
>> > Piecash, as I understand it, was a proof-of-concept experiment to see
>> > whether a python front end could be designed. It has not been maintained
>> > for some years now, and I recall recent discussion about changing its
>> > status with the project.
>> >
>> > As far as I know, there has been no change in recommendation to stay
>> with
>> > xml.
>> >
>> > David
>> >
>> > On January 27, 2018, at 12:13 PM, Adrien Monteleone <
>> > adrien.montele...@gmail.com> wrote:
>> >
>> > I switched from XML to SQLite about a year ago. I perceive a performance
>> > improvement on loading, but that’s about it. (and I generally never shut
>> > the app down anyway)
>> >
>> > I haven’t attempted any custom reporting yet, but I plan to.
>> >
>> > I could 

Re: File Format : XML v MySQL / postgres / sqllite

[David T. via gnucash-user]

Sebastien,

The problem isn’t with Python (I am told that Macs already have Python on 
them). The problem as I understand it (John will no doubt correct me when my 
statements prove ill-informed or flat out wrong) has to do with the fact that 
GnuCash requires a specific version of Python, which can only be guaranteed by 
compiling GnuCash with the current version of Python. Short of shipping GnuCash 
with a complete Python installation, the only way around this is for individual 
users to compile locally. Which, as I noted, is a painful process for me. But 
thanks for the information.

David


> On Jan 28, 2018, at 11:55 AM, Sébastien de Menten  wrote:
> 
> Hello David,
> 
> Regarding the use of python on windows and Mac, Anaconda has made a huge 
> difference in the last years providing all packages in an easy precompiled 
> version.
> You can have a look at https://conda.io/docs/user-guide/install/macos.html 
>  for the installation 
> (which is simple and does not require any compiler).
> 
> 
> On Jan 28, 2018 05:42, "D" > 
> wrote:
> Ah, yes that was my incorrect reference. Sorry for the crossed reference.
> 
> I will note that my confusion stems in part from the fact that, as a Mac 
> user, I have never used anything to do with python and Gnucash, on account of 
> the high barrier to install the proper toolsets (i.e., compiling yourself). 
> My previous attempts at this process always ended in frustration and failure. 
> As a consequence, when I see anything that mentions python and Gnucash, my 
> eyes glaze over.
> 
> In the past, there hasn't been much to recommend beating my head against that 
> wall, but perhaps the time has come to see what happens at this time, since 
> there eh to be increasing numbers of ways to use python with Gnucash data.
> 
> David
> 
> On January 28, 2018, at 12:55 AM, John Ralls  > wrote:
> 
> I suspect David was thinking of CuteCash, Christian Stimming’s experimental 
> Qt GUI.
> 
> Regards,
> John Ralls
> 
> > On Jan 27, 2018, at 10:44 AM, Sébastien de Menten  > > wrote:
> >
> > Hello David,
> >
> > I saw you were mentioning piecash in your message. If you talk about
> > http://piecash.readthedocs.io/en/latest/ 
> > , it is not a proof of concept for
> > a frontend but an alternative to the gnucash python bindings to work with
> > gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
> > MySQL) and is alive and maintained (last release on the 20th December 2017).
> >
> > The following article https://arachnoid.com/gnucash_utilities/ 
> >  shows some
> > interesting use cases for it.
> >
> > With gnucash 3.0, piecash will also allow you to write your own reports
> > using si python and jinja2 (work in progress).
> >
> > For people interested to contribute, https://github.com/sdementen/piecash 
> > .
> >
> >
> > On Jan 27, 2018 18:27, "D via gnucash-user"  > >
> > wrote:
> >
> > Mike,
> >
> > There is nothing new as far as I know about the file formats. You are right
> > that the primary benefit to using sql is being able to generate data sets
> > from sql that can used in reports. Processing a data file is no quicker in
> > sql, since it all gets loaded in at start up. Sql, moreover, adds a
> > database manager role to the mix; many users are not prepared to learn how
> > to manage a database platform to manage their financial accounts.
> >
> > I stick with the XML because it also can store the data compressed; when
> > dealing with the main data file and all its copies, the difference between
> > 3mb and 13mb adds up quickly.
> >
> > Piecash, as I understand it, was a proof-of-concept experiment to see
> > whether a python front end could be designed. It has not been maintained
> > for some years now, and I recall recent discussion about changing its
> > status with the project.
> >
> > As far as I know, there has been no change in recommendation to stay with
> > xml.
> >
> > David
> >
> > On January 27, 2018, at 12:13 PM, Adrien Monteleone <
> > adrien.montele...@gmail.com > wrote:
> >
> > I switched from XML to SQLite about a year ago. I perceive a performance
> > improvement on loading, but that’s about it. (and I generally never shut
> > the app down anyway)
> >
> > I haven’t attempted any custom reporting yet, but I plan to.
> >
> > I could be mistaken, but I think PyCash is designed to parse the XML file
> > so you can still get the reporting you want.
> >
> > Regards,
> > Adrien
> >
> >> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet <
> > mikestillingfl...@fastmail.co.uk 

Re: File Format : XML v MySQL / postgres / sqllite

[Sébastien de Menten]

Hello David,

Regarding the use of python on windows and Mac, Anaconda has made a huge
difference in the last years providing all packages in an easy precompiled
version.
You can have a look at https://conda.io/docs/user-guide/install/macos.html
for the installation (which is simple and does not require any compiler).


On Jan 28, 2018 05:42, "D"  wrote:

> Ah, yes that was my incorrect reference. Sorry for the crossed reference.
>
> I will note that my confusion stems in part from the fact that, as a Mac
> user, I have never used anything to do with python and Gnucash, on account
> of the high barrier to install the proper toolsets (i.e., compiling
> yourself). My previous attempts at this process always ended in frustration
> and failure. As a consequence, when I see anything that mentions python and
> Gnucash, my eyes glaze over.
>
> In the past, there hasn't been much to recommend beating my head against
> that wall, but perhaps the time has come to see what happens at this time,
> since there eh to be increasing numbers of ways to use python with Gnucash
> data.
>
> David
>
> On January 28, 2018, at 12:55 AM, John Ralls  wrote:
>
> I suspect David was thinking of CuteCash, Christian Stimming’s
> experimental Qt GUI.
>
> Regards,
> John Ralls
>
> > On Jan 27, 2018, at 10:44 AM, Sébastien de Menten 
> wrote:
> >
> > Hello David,
> >
> > I saw you were mentioning piecash in your message. If you talk about
> > http://piecash.readthedocs.io/en/latest/, it is not a proof of concept
> for
> > a frontend but an alternative to the gnucash python bindings to work with
> > gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
> > MySQL) and is alive and maintained (last release on the 20th December
> 2017).
> >
> > The following article https://arachnoid.com/gnucash_utilities/ shows
> some
> > interesting use cases for it.
> >
> > With gnucash 3.0, piecash will also allow you to write your own reports
> > using si python and jinja2 (work in progress).
> >
> > For people interested to contribute, https://github.com/sdementen/
> piecash.
> >
> >
> > On Jan 27, 2018 18:27, "D via gnucash-user" 
> > wrote:
> >
> > Mike,
> >
> > There is nothing new as far as I know about the file formats. You are
> right
> > that the primary benefit to using sql is being able to generate data sets
> > from sql that can used in reports. Processing a data file is no quicker
> in
> > sql, since it all gets loaded in at start up. Sql, moreover, adds a
> > database manager role to the mix; many users are not prepared to learn
> how
> > to manage a database platform to manage their financial accounts.
> >
> > I stick with the XML because it also can store the data compressed; when
> > dealing with the main data file and all its copies, the difference
> between
> > 3mb and 13mb adds up quickly.
> >
> > Piecash, as I understand it, was a proof-of-concept experiment to see
> > whether a python front end could be designed. It has not been maintained
> > for some years now, and I recall recent discussion about changing its
> > status with the project.
> >
> > As far as I know, there has been no change in recommendation to stay with
> > xml.
> >
> > David
> >
> > On January 27, 2018, at 12:13 PM, Adrien Monteleone <
> > adrien.montele...@gmail.com> wrote:
> >
> > I switched from XML to SQLite about a year ago. I perceive a performance
> > improvement on loading, but that’s about it. (and I generally never shut
> > the app down anyway)
> >
> > I haven’t attempted any custom reporting yet, but I plan to.
> >
> > I could be mistaken, but I think PyCash is designed to parse the XML file
> > so you can still get the reporting you want.
> >
> > Regards,
> > Adrien
> >
> >> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet <
> > mikestillingfl...@fastmail.co.uk> wrote:
> >>
> >> Dear All,
> >>
> >> XML is the default when creating a new file.
> >>
> >> I have seen various quite dated questions about the decision process of
> > selecting which db to use.
> >>
> >> I think that the main advantage of using MySQL would be the ability to
> > generate custom reports.
> >>
> >> Are there any other advantages and are there any differences in the
> > interface between the various db's. Does the forum still recommend XML.
> >>
> >> Regards
> >>
> >> --
> >> Mike Stillingfleet
> >> mikestillingfl...@fastmail.co.uk
> >> ___
> >> gnucash-user mailing list
> >> gnucash-user@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> >> -
> >> Please remember to CC this list on all your replies.
> >> You can do this by using Reply-To-List or Reply-All.
> >
> > ___
> > gnucash-user mailing list
> > gnucash-user@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -
> > Please remember to CC this list on all your replies.
> > You 

Re: File Format : XML v MySQL / postgres / sqllite

[John Ralls]

I suspect David was thinking of CuteCash, Christian Stimming’s experimental Qt 
GUI.

Regards,
John Ralls

> On Jan 27, 2018, at 10:44 AM, Sébastien de Menten  wrote:
> 
> Hello David,
> 
> I saw you were mentioning piecash in your message. If you talk about
> http://piecash.readthedocs.io/en/latest/, it is not a proof of concept for
> a frontend but an alternative to the gnucash python bindings to work with
> gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
> MySQL) and is alive and maintained (last release on the 20th December 2017).
> 
> The following article https://arachnoid.com/gnucash_utilities/ shows some
> interesting use cases for it.
> 
> With gnucash 3.0, piecash will also allow you to write your own reports
> using si python and jinja2 (work in progress).
> 
> For people interested to contribute, https://github.com/sdementen/piecash.
> 
> 
> On Jan 27, 2018 18:27, "D via gnucash-user" 
> wrote:
> 
> Mike,
> 
> There is nothing new as far as I know about the file formats. You are right
> that the primary benefit to using sql is being able to generate data sets
> from sql that can used in reports. Processing a data file is no quicker in
> sql, since it all gets loaded in at start up. Sql, moreover, adds a
> database manager role to the mix; many users are not prepared to learn how
> to manage a database platform to manage their financial accounts.
> 
> I stick with the XML because it also can store the data compressed; when
> dealing with the main data file and all its copies, the difference between
> 3mb and 13mb adds up quickly.
> 
> Piecash, as I understand it, was a proof-of-concept experiment to see
> whether a python front end could be designed. It has not been maintained
> for some years now, and I recall recent discussion about changing its
> status with the project.
> 
> As far as I know, there has been no change in recommendation to stay with
> xml.
> 
> David
> 
> On January 27, 2018, at 12:13 PM, Adrien Monteleone <
> adrien.montele...@gmail.com> wrote:
> 
> I switched from XML to SQLite about a year ago. I perceive a performance
> improvement on loading, but that’s about it. (and I generally never shut
> the app down anyway)
> 
> I haven’t attempted any custom reporting yet, but I plan to.
> 
> I could be mistaken, but I think PyCash is designed to parse the XML file
> so you can still get the reporting you want.
> 
> Regards,
> Adrien
> 
>> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet <
> mikestillingfl...@fastmail.co.uk> wrote:
>> 
>> Dear All,
>> 
>> XML is the default when creating a new file.
>> 
>> I have seen various quite dated questions about the decision process of
> selecting which db to use.
>> 
>> I think that the main advantage of using MySQL would be the ability to
> generate custom reports.
>> 
>> Are there any other advantages and are there any differences in the
> interface between the various db's. Does the forum still recommend XML.
>> 
>> Regards
>> 
>> --
>> Mike Stillingfleet
>> mikestillingfl...@fastmail.co.uk
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> 
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: File Format : XML v MySQL / postgres / sqllite

[Sébastien de Menten]

Hello David,

I saw you were mentioning piecash in your message. If you talk about
http://piecash.readthedocs.io/en/latest/, it is not a proof of concept for
a frontend but an alternative to the gnucash python bindings to work with
gnucash books stored in any of the 3 SQL backends (SQLite, postgres and
MySQL) and is alive and maintained (last release on the 20th December 2017).

The following article https://arachnoid.com/gnucash_utilities/ shows some
interesting use cases for it.

With gnucash 3.0, piecash will also allow you to write your own reports
using si python and jinja2 (work in progress).

For people interested to contribute, https://github.com/sdementen/piecash.


On Jan 27, 2018 18:27, "D via gnucash-user" 
wrote:

Mike,

There is nothing new as far as I know about the file formats. You are right
that the primary benefit to using sql is being able to generate data sets
from sql that can used in reports. Processing a data file is no quicker in
sql, since it all gets loaded in at start up. Sql, moreover, adds a
database manager role to the mix; many users are not prepared to learn how
to manage a database platform to manage their financial accounts.

I stick with the XML because it also can store the data compressed; when
dealing with the main data file and all its copies, the difference between
3mb and 13mb adds up quickly.

Piecash, as I understand it, was a proof-of-concept experiment to see
whether a python front end could be designed. It has not been maintained
for some years now, and I recall recent discussion about changing its
status with the project.

As far as I know, there has been no change in recommendation to stay with
xml.

David

On January 27, 2018, at 12:13 PM, Adrien Monteleone <
adrien.montele...@gmail.com> wrote:

I switched from XML to SQLite about a year ago. I perceive a performance
improvement on loading, but that’s about it. (and I generally never shut
the app down anyway)

I haven’t attempted any custom reporting yet, but I plan to.

I could be mistaken, but I think PyCash is designed to parse the XML file
so you can still get the reporting you want.

Regards,
Adrien

> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet <
mikestillingfl...@fastmail.co.uk> wrote:
>
> Dear All,
>
> XML is the default when creating a new file.
>
> I have seen various quite dated questions about the decision process of
selecting which db to use.
>
> I think that the main advantage of using MySQL would be the ability to
generate custom reports.
>
> Are there any other advantages and are there any differences in the
interface between the various db's. Does the forum still recommend XML.
>
> Regards
>
> --
>  Mike Stillingfleet
>  mikestillingfl...@fastmail.co.uk
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: File Format : XML v MySQL / postgres / sqllite

[D via gnucash-user]

Mike,

There is nothing new as far as I know about the file formats. You are right 
that the primary benefit to using sql is being able to generate data sets from 
sql that can used in reports. Processing a data file is no quicker in sql, 
since it all gets loaded in at start up. Sql, moreover, adds a database manager 
role to the mix; many users are not prepared to learn how to manage a database 
platform to manage their financial accounts.

I stick with the XML because it also can store the data compressed; when 
dealing with the main data file and all its copies, the difference between 3mb 
and 13mb adds up quickly.

Piecash, as I understand it, was a proof-of-concept experiment to see whether a 
python front end could be designed. It has not been maintained for some years 
now, and I recall recent discussion about changing its status with the project.

As far as I know, there has been no change in recommendation to stay with xml.

David

On January 27, 2018, at 12:13 PM, Adrien Monteleone 
 wrote:

I switched from XML to SQLite about a year ago. I perceive a performance 
improvement on loading, but that’s about it. (and I generally never shut the 
app down anyway)

I haven’t attempted any custom reporting yet, but I plan to.

I could be mistaken, but I think PyCash is designed to parse the XML file so 
you can still get the reporting you want.

Regards,
Adrien

> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet 
>  wrote:
> 
> Dear All,
> 
> XML is the default when creating a new file.
> 
> I have seen various quite dated questions about the decision process of 
> selecting which db to use.
> 
> I think that the main advantage of using MySQL would be the ability to 
> generate custom reports.
> 
> Are there any other advantages and are there any differences in the interface 
> between the various db's. Does the forum still recommend XML.
> 
> Regards
> 
> -- 
>  Mike Stillingfleet
>  mikestillingfl...@fastmail.co.uk
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: File Format : XML v MySQL / postgres / sqllite

[Adrien Monteleone]

I switched from XML to SQLite about a year ago. I perceive a performance 
improvement on loading, but that’s about it. (and I generally never shut the 
app down anyway)

I haven’t attempted any custom reporting yet, but I plan to.

I could be mistaken, but I think PyCash is designed to parse the XML file so 
you can still get the reporting you want.

Regards,
Adrien

> On Jan 27, 2018, at 12:55 AM, Mike Stillingfleet 
>  wrote:
> 
> Dear All,
> 
> XML is the default when creating a new file.
> 
> I have seen various quite dated questions about the decision process of 
> selecting which db to use.
> 
> I think that the main advantage of using MySQL would be the ability to 
> generate custom reports.
> 
> Are there any other advantages and are there any differences in the interface 
> between the various db's. Does the forum still recommend XML.
> 
> Regards
> 
> -- 
>  Mike Stillingfleet
>  mikestillingfl...@fastmail.co.uk
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

___
gnucash-user mailing list
gnucash-user@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.