On 5/29/21 5:15 AM, Eric Bollengier via Bacula-devel wrote: > Hello Phil,
>> I have already in the past converted many of the TINYBLOB columns in my >> Bacula catalog schema to VARBINARY with no ill effects. I now need to >> redo a few of them because we just rewrote the File table. :) >> >> From my most recent nightly DB backup, these are the columns I currently >> have converted to VARBINARY: >> >> minbar:root:/dbdumps/minbar-20210521-04:55:25 # zgrep -i varbinary >> bacula*schema.sql.gz >> bacula.Client-schema.sql.gz: `Name` varbinary(64) NOT NULL, > > A directive name can be up to 127 bytes, and I'm looking to extend it at 256 > or even more in a short term. 'Directive name'? Client name? > A VolumeName, MediaType, etc.. have the same possible length. Right, I'll take another look at those then. VARBINARY(255) seems safe for now. >> I also need to re-convert File.MD5 to VARBINARY(32) and, now, change >> File.Filename to VARBINARY(255). >> >> What is the maximum possible size of File.LStat? That is another good >> candidate to become a VARBINARY. > > At this time, we can store up to a SHA512 in base64, I would suggest to do a > test. So the File.MD5 field may actually, despite its name, contain an SHA512? I will increase mine to VARBINARY(130) in that case, which should safely contain an sha512sum. Those are instant changes, by the way, once a column is VARCHAR or VARBINARY, because all that has to be changed is the metadata defining the permitted size of the field. ALTER TABLE File MODIFY COLUMN MD5 VARBINARY(130) NOT NULL; executes in 0.047 seconds on my database, with 82 million rows, and touches no actual table rows. -- 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
