Help with libdbi code
geert.gnucash at kobaltwit.be
Sat May 7 11:47:05 EDT 2016
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
> 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
>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
> 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.
More information about the gnucash-devel