Here is my response concerning the mysql_tables_change (see your email below).

I cannot make changes of the kind that you suggest where some change items that are not broken or items where I cannot reproduce a problem. This is especially since this is a production release, which I cannot risk creating new problems, and the fact that I am leaving for three weeks in the next couple of days.

At least I am happy that you now have a solution that fixes your problem. When I get back from vacation, I will look at the code you have that might reduce problems when upgrading from older databases.

Best regards,


On 08/05/2017 04:50 PM, Phil Stracchino wrote:
Rather than re-opening the ticket again - the schema patch doesn't do
NEARLY as much as it looks as though it does.

The make_mysql_tables script currently creates a new Bacula schema in
which all DATETIME fields *except one* are left as unadorned DATETIME
with no NOT NULL or DEFAULT.  The one exception is the DATETIME field in
Snapshot, and we talked about that and you agreed the NOT NULL was
unnecessary.  So the patch removes it, so that the column is not
declared NOT NULL without a default.

The Snapshot table also contains one BIGINT declared NOT NULL without a
DEFAULT, which is invalid.  The patch adds a DEFAULT 0 to that column.

Those are the only changes made to  One NOT NULL
removed, one DEFAULT added.

The change to does only one thing:  It makes all
the DATETIME columns in an *existing* Bacula catalog database match the
DATETIME columns in a brand new one created by make_mysql_tables.  (It
should also fix the missing DEFAULT on Snapshot.CreateTDate, but I just
realized this morning I missed that.)

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Bacula-devel mailing list

Reply via email to