Help with libdbi code

[Colin Law]

On 7 May 2016 at 12:01, John Ralls <jralls at ceridwen.us> wrote:
>
>> On May 7, 2016, at 6:22 AM, Colin Law <clanlaw at gmail.com> wrote:
>>
>> On 7 May 2016 at 10:09, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
>>> ...
>>> I'm not sure you need to do this when connecting to the mysql database (not
>>> table) and before creating the new database. At that point there is no data
>>> in the new database so there can't be any NULL in a date field either.
>>>
>>> On the other hand it may be that you do have to do this if MySQL already
>>> complains when writing the DB schema which I consider unlikely (yet not
>>> impossible).
>>
>> I believe that it is necessary as the initial problem is encountered
>> when creating the database as one of the date fields has a default
>> value of zero.  In fact I have not found a case where the no_zero_date
>> option causes a problem other than when creating a new database, but I
>> have not tried very hard.  I had wondered whether an alternative
>> strategy of not providing a default value, but allowing the date to be
>> null in the database instead was possible, but I gather that would
>> involve significant work.  In addition it would cause problems when
>> upgrading gnucash as old databases would no longer be compatible.
>
> Hmm, the trace files from the bug report seemed to show that the error was from saving a slot row with a 0-valued date rather than from creating a table with a default value of 0.

No doubt you are right (again), it is probably not the actual creation
but the writing that is the issue.  Me jumping to conclusions again.
I will investigate whether it is necessary to change the options for
creating the db.

>
> The only issue with schema changes is that they make the database incompatible between GnuCash versions. I agree that it's dumb to declare a date field NOT_NULL and then store 0 in it. It was also my (apparently mis-)understanding that NO_ZERO_DATE also meant no NULL dates. If that's not the case and we can work around the schema change issue (easy if it really is just during DB creation) then that's a better way to address the problem.

I suggest I go ahead with changing the options as it will be a very
localised change with little chance of side effects so would be ok in
the next minor release.  Changing the schema to use null rather than
zero could have unexpected side effects and it would be difficult (I
imagine) to be certain that there was not a bit of code somewhere that
had been missed, that needed to be changed.

Regards

Colin