Help with libdbi code

[Colin Law]

On 7 May 2016 at 16:47, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> On Saturday 07 May 2016 16:23:56 Colin Law wrote:
>> ...
>> Can we be sure, though, that nowhere does the code
>> explicitly write 0 (as opposed to not asking for anything to be
>> written, so the default is written)?
>
> Good question. I haven't searched thoroughly through the code yet. However
> one spot that may cause this is gnc_dbi_safe_sync_all in gnc-backend-dbi.c
> line 1642. If there is a 0 timestamp somewhere in the DB, I assume it will
> plainly copy it. Of course this depends on whether some other code actually
> does write 0 timestamps. I haven't had time yet to search where timestamps
> are written or whether it's special cased somewhere in the backend code or
> anything.
>
> From the trace file however there's good hope that gnucash prefers to write
> NULL for an invalid timestamp, at least that's what it does for the slot
> table there.

Under what circumstances is that code called?

>
>> I could not find anything in the libdbi docs that explicitly says what
>> happens when a field containing NULL is fetched. I presume it is
>> going to return 0 however, so that should be OK.
>
> No, a NULL value in the database is explicitly tested for in
> gnc-backend-dbi.c line 2108. In that case gnucash will internally continue
> with NULL. So this situation appears to be taken into account.

Where the final NULL is a c NULL, so zero, of course.  So yes that should be ok.

>> The other area I can think of where this could cause problems is if
>> anywhere in the code issues a query specifying date <> 0 or > 0 or = 0
>> or other similar operation. These would have to be changed to IS NOT
>> NULL etc.
>
> True. I doubt gnucash does that already though. Gnucash reads the whole db
> in memory at load time and does all querying in-memory. It just writes back
> any change as well. Those write-backs typically use the guid to find the
> proper row in any table, not a timestamp.

I had forgotten that gnucash just reads the complete db in at startup.
I can see that means that probably there is no complex querying.

I am running with
type_name = "TIMESTAMP NULL";
and have not found any problems so far.

Should make check work?  I find that even before I make the change I am getting
 /qof/gnc-date/qof print date dmy buff:                               FAIL
GTester: last random seed: R02Sed570872cf591664699ffdaa1320d1f4
/bin/bash: line 1: 17264 Terminated              MALLOC_CHECK_=2
MALLOC_PERTURB_=$((${RANDOM:-256} % 256)) gtester --verbose test-qof

Do I have to do anything special to get the database tests to run?  I
see a configure option  --with-test-mysql-url=URL.  Do I have to set
that up?  If so what is the format please?

Colin