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.
- Also, remove unnecessary "static" in gnucash-style.c
The second one in guid.cpp is UB:
libgnucash/engine/guid.cpp:137:5: warning: undefined behavior, source object type 'const gnc::GUID' is not TriviallyCopyable [bugprone-undefined-memory-manipulation]
memcpy (&target, &source, sizeof (GncGUID));
^
properly - corrupted business data
Turned out to be a pointer/value mismatch between <CT_NUMERIC>load()
and most of the setter functions, so the address was getting set
as the value.
Be smarter about what is path and key for each slot.
Instead of assuming a slash is always a path separator (first attempt
on unstable) or never a separator (second attempt),
track the parent path while loading kvp slots from the db
and deduce the slot's name by substracting this parent path.
The import-map-bayes uses a three-part key that uses the same delimiter
as a path and the SQL backend was throwing away everything except the
account guid.
Added more slot types including import-map-bayes ones to the test xml
file to help debug this and to catch it in the future.
Also don't pass std::string.c_str() to a std::vector<std::string>
constructor, just pass the string.
transaction number or split action (requires at least GnuCash 2.5.0)
Strip leading delimiters from KVP keys when reading them from the
database. Leading delimiters are incorrectly included in databases
created with GnuCash 2.6.x.
The template avoids the need to cast to and from void*, and adds flexibility to
the targeted function's signature.
test-stuff.h defines a macro, "failure" which is used as an identifier
in the standard IO library, so I moved any inclusion of test-stuff.h to
the last include position so that "failure" wouldn't be defined before
the IO library was included.
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.
David Seifert
John Ralls
Richard Cohen
Bill Nottingham
Geert Janssens
lmat