On 11/28/20 2:14 PM, Radoslav Bodó wrote:
>> 3) Referenced Columns need to exist.
>>
>> BaseFiles.BaseJobId REFERENCES Job, but table Job does not contain
>> BaseJobId, so this fails as well.
>
> It's not important for the root issue, but Sven insisted to comment that
> anyway. To be complete I think that point of BaseFiles.BaseJobId is to
> reference Job table/entity by it's primary key JobId ("REFERENCES
> Job(JobId)"). That would be the usual order of things. The behavior of
> mariadb syntax parsing changed, hence the error...
>
>
> The main point is:
>
> * the REFERENCES in mysql schema broke on mariadb 10.5 (default for
> Debian Bullseye)
> * there's no foregin keys/constraints in postgresql schema anyway
> * dropping all "REFERENCES" from mysql schema fixes the issue
Honestly, there's no really sound reason why Bacula needs foreign keys
in MySQL at all, because it manages its data well and cleans up properly
after itself anyway. Foreign key constraints in MySQL do impact
performance, so Bacula is probably better off overall without them,
especially since Bacula's mysql driver code isn't really very good about
checking for and properly handling DB write failures in the first place.
It just declares mission failure and gives up.
--
Phil Stracchino
Babylon Communications
ph...@caerllewys.net
p...@co.ordinate.org
Landline: +1.603.293.8485
Mobile: +1.603.998.6958
_______________________________________________
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel
