Help with libdbi code

[Geert Janssens]

On Saturday 07 May 2016 16:23:56 Colin Law wrote:
> On 7 May 2016 at 15:56, John Ralls <jralls at ceridwen.us> wrote:
> > ..
> > Try changing gnc-backend-dbi.c line 2702 from
> > 
> >     type_name = "TIMESTAMP NULL DEFAULT 0";
> > 
> > to
> > 
> >     type_name = "TIMESTAMP NULL DEFAULT NULL";
> 
> I don't think it is necessary to specify DEFAULT NULL as that is the
> default.
> 
> Well That does prevent the error and nothing else undesirable seems to
> be happening.  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.
> 
> 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.

> 
> 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.

Regards,

Geert