Scrubbing during SQL load can't commit the changes from the scrub
because the backend's m_loading member is true so disable scrubbing
during database load and edit/commit all transactions again after
loading is complete.
For wrong value type when retrieving a value from the SQL results row.
Profiling showed that most of the SQL load time was spent in handling
these exceptions, and using std::optional instead produced a > 11x
speedup (10 seconds vs. 115 seconds) when loading a large file.
There are a very few left that need deeper study, but this gets
rid of most of the noise. For the most part it's just getting rid of
extra variables or removing an assignment that is always
replaced later but before any reads of the variable. A few are
discarded result variables.
This prevents calling xaccAccountRecomputeBalanceInCurrency on each split that gets added,
which was exponentially increasing load times. On a huge test book the
load time dropped from 53 minutes to 1m20s.
In addition to not begining to edit already-loaded transactions,
don't try to load splits that are already loaded. It shouldn't
be possible to load a transaction without also loading its splits.
An extra XaccTransBeginEdit, never committed, for transactions that
the backend tried to load when they were already there. That made
the register think that something else had it open.
SQLite backend.
Release Note: This bug caused data loss if you saved your SQLite3
database to a different file or database.
The problem is that in SQLite3 (though not in MySQL or PgSQL) the
subquery ((SELECT DISTINCT guid FROM transactions)) (note the double
parentheses) returns only the first guid in the subquery's results.
Some transactions are loaded by special queries and those queries are
also used to retrieve the transaction's slots so they weren't affected.
This crash started to appear as of commit 80dbb9940b because the sequence
of split loading has changed as a result of the query optimizations.
Invoice transactions get loaded before the general transaction loading happens.
However because of this, when an invoice transaction was encountered again
during general transaction loading, it was (correctly) not created again
AND (incorrectly) not opened for subsequent editing. This caused
an assert to fail when the splits for this transaction are loaded
shortly afterwards. The solution is simply to ensure all transactions
are opened for editing during the general transaction loading call.
Wherin the problem is that MySQL's TIMESTAMP has a date range of
1970-01-01 00:00:01 to 2038-01-19 03:14:07 and is unable to handle
time_t of 0. MySQL's TIMESTAMP also assumes that input is in the server's
timezone and adjusts it to UTC. GnuCash has already done that conversion.
For each subclass, getting rid of GNC_SQL_OBJECT_BACKEND_VERSION which
was a bit misguided.
Also remove the bogus test the skipped loading a table if its version
didn't match GNC_SQL_OBJECT_BACKEND_VERSION which was even more misguided.
This will avoid a ninja-build from picking up a config.h generated by the autotools build
(in the root build directory). Picking up the wrong config.h may lead to all kinds of
subtle issues if the autotools run was done with different options than the cmake run.
It is split into
- /libgnucash (for the non-gui bits)
- /gnucash (for the gui)
- /common (misc source files used by both)
- /bindings (currently only holds python bindings)
This is the first step in restructuring the code. It will need much
more fine tuning later on.
John Ralls
Richard Cohen
Christopher Lam
Di Mang
Geert Janssens
Bill Nottingham