There's no hidden feature in GnuCash.
SQL: select count(*) from transactions; and select count(*) from splits;
grep an uncompressed XML file: grep -c ''
path/to/file.gnucash; use '' to count the splits.
You can also look at the top of your XML file between the book slots and the
commodities t
Just out of curiosity, how does one determine those numbers? An SQL query?
grep | wc on the xml? Some feature of gnuCash I’ve never discovered?
> On Aug 8, 2022, at 3:54 PM, Derek Atkins wrote:
>
>
> On Mon, August 8, 2022 3:21 pm, Robert Simmons wrote:
>>> Accounting systems primarily
On Mon, August 8, 2022 4:33 pm, Robert Simmons wrote:
> That makes sense. So, performance would not be an argument for SQL and
> against a graph database.
Nor would it be an argument for graph and against SQL. But transactional
data is so structured that SQL really does make sense.
> Please re
That makes sense. So, performance would not be an argument for SQL and
against a graph database.
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/g
On Mon, August 8, 2022 3:21 pm, Robert Simmons wrote:
>> Accounting systems primarily perform the same operation on large numbers
> of data elements.
>
> I wish I had time to devote to this. I use graph databases in many of the
> other systems that I develop. This would be a great pivot point on
> Accounting systems primarily perform the same operation on large numbers
of data elements.
I wish I had time to devote to this. I use graph databases in many of the
other systems that I develop. This would be a great pivot point on which to
create a new open source project and see which paradigm
> we should consider changing the license to GPL-Affero to preclude someone
using GnuCash in a non-Free software-as-a-service scheme
That is a consideration. When I hit the point of needing to write quite a
lot of code to get GnuCash to do exactly what I want, I looked into other
projects. I took
> On Aug 8, 2022, at 11:04 AM, Robert Simmons wrote:
>
> Another observation: the current GnuCash mixes data and display layers.
>
> For a new system, I would suggest separating everything completely. Have a
> database and lib layer that interacts with the database. Then expose the
> lib to C
> On Aug 8, 2022, at 10:53 AM, Robert Simmons wrote:
>
> Understood.
>
> After looking under the hood a good bit as well as thinking about the
> problems of accounting and databases in general I have a side question:
>
> If you're working on a rewrite of some kind, why not use a graph databa
Another observation: the current GnuCash mixes data and display layers.
For a new system, I would suggest separating everything completely. Have a
database and lib layer that interacts with the database. Then expose the
lib to C, Python, C++, Rust, Go, whatever. You can then have a REST layer
buil
Understood.
After looking under the hood a good bit as well as thinking about the
problems of accounting and databases in general I have a side question:
If you're working on a rewrite of some kind, why not use a graph database
as the back end rather than SQL?
The reason is that a graph database
On Mon, August 8, 2022 1:44 pm, john wrote:
> The intended end-user process is to use the program, not the bindings.
>
> As to why the job-creating functions don't increment the counters, I think
> because the design allows the user to override the counter-based ids in
> the GUI. Derek wrote the
The intended end-user process is to use the program, not the bindings.
As to why the job-creating functions don't increment the counters, I think
because the design allows the user to override the counter-based ids in the
GUI. Derek wrote the code so he's the authority on the why's and wherefore
> unless your script is going to create jobs and immediately exit
Yes. I see no other way to do this other than directly changing the
database. There is nothing in the Python bindings that can do it. I'm
keeping a count "job_num" that I'm using with "str(job_num).zfill(6)" to
make it look correct
If these functions are not public, why don't the proper functions for
creating Jobs and other objects increment the counters?
If I'm understanding correctly, Python bindings provide no way to increment
counters (since exposing some of those incrementX functions were mistakenly
not in the private h
All of the incrementFooID functions are declared in the respective private
headers, so that functionality is not intended to be public API. The why is
lost to history, those functions were created in a drive-by contribution.
Your workaround of writing directly to the database is ill-advised unle
Little error there. I improved the query while writing: "This sets the Job
ID counter to 3, but you would change that 3 to whatever the ID you want."
should be "This increments the Job ID to the next"
___
gnucash-user mailing list
gnucash-user@gnucash.org
I have a workaround.
Here's the Python for anyone who needs it. This sets the Job ID counter to
3, but you would change that 3 to whatever the ID you want.
import pathlib
import sqlite3
target = pathlib.Path('test.gnucash')
con = sqlite3.connect(target)
cur = con.cursor()
cur.execute('UPDATE slo
I think I have tracked down the issue with Job ID incrementation.
The Python bindings are built from the header files using SWIG, if I
understand correctly. Looking at the file libgnucash/engine/gncJob.c I can
see the function:
gchar *gncJobNextID (QofBook *book)
{
return qof_book_increment_a
19 matches
Mail list logo
