Bug#2584: MySQL schema broken for MariaDB 10.5

Sven Hartge <[email protected]>
Newsgroups gmane.comp.sysutils.backup.bacula.devel
Message-ID <[email protected]>
Hallo .*,

This references https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975970
and https://bugs.bacula.org/view.php?id=2584, both filed by Radoslav Bodó,
the latter on my request.

It seems MariaDB 10.5 has stricter schema checking when using foreign keys
and references.

(Yes, I know, MariaDB is not officially supported, but I think the same 
strictness applies to newer MySQL versions as well. Also all major Linux 
distributions now ship MariaDB as their default SQL server, so having a 
working schema would be a low hanging fruit.)

This uncovers some problems with the current MySQL schema in 9.6.6:

1) Tables need to be created before they can be referenced.

For example Job.PoolId references Pool.PoolId which fails
because Pool is created later. One may be able to fix this by reordering
the tables in the schema file. But I am under the unverified impression
that some references are circular. In that case one needs to disable the
foreign key checks before being able to import the schema.

2) Column definition must be exact.

This is wrong for ClientId which is sometimes defined as "INTEGER" and
sometimes as "INTEGER UNSIGNED". Those need to be identical.

3) Referenced Columns need to exist.

BaseFiles.BaseJobId REFERENCES Job, but table Job does not contain
BaseJobId, so this fails as well.

4) Constraints seem to fail and may even not be needed.

As Radoslav Bodó mentions in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975970#20
the foreign key constraints fail and may even not be needed, compared to
the Postgres schema.

More input here would be nice.

Debian freezes in the not so far future and it would really be a shame if
we need to remove Bacula from it or abandon the MySQL version because of
this.

Grüße,
Sven.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.