Unsupported Screen Size: The viewport size is too small for the theme to render properly.

Feature Request: Remove Sqlyog Version From Scheduled Backup Files

forums forums SQLyog SQLyog: Bugs / Feature Requests Feature Request: Remove Sqlyog Version From Scheduled Backup Files

Tagged: 

This topic contains 4 replies, has 0 voices, and was last updated by  number_one 4 years, 3 months ago.

  • Author
    Posts
  • #13359

    imaginatian
    Member

    We use the Scheduled Backup feature to export a number of tables every day.  Some of these tables hold critical information that shouldn’t change without approval.  One of the controls we have is to monitor any changes in the content of the exported files by taking a hash value for the file and using this to compare against the previous version.  If there has been no change we can safely discard the latest version.  This gives us a complete change history for the tables.  It also allows us to know when our test and production systems are different, which, when a planned change occurs, is allowed.

     

    The problem we have is that every time we upgrade SQLyog the files all report a change and we have to double check the content more closely i.e. manually.  The reason for this change is that the export process puts a comment at the top of each file which includes the version number for SQLyog and, for our system, MySQL.  As we upgrade SQLyog in production a week or so after having done so in test we double the number of times that changes are found.

     

    It would be great if there was a tick box option within the Schedule Backup Wizard that allowed for the suppression of this information.  I don’t mind if it still boasts that the file was produced by SQLyog!  All I want is the ability to suppress the version numbers from the example below. 


    /*
    SQLyog Job Agent v12.1 (64 bit) Copyright(c) Webyog Inc. All Rights Reserved.


    MySQL - 5.6.17 : Database - sys-controls
    *********************************************************************
    */

    Regards,

     

    Ian

  • #35350

    We can look into it. But why don’t you just take hash of content of file excluding 


    /*
    SQLyog Job Agent v12.1 (64 bit) Copyright(c) Webyog Inc. All Rights Reserved.


    MySQL - 5.6.17 : Database - sys-controls
    *********************************************************************
    */

    ?

    Just taking hash after removing this header should work.

  • #35351

    imaginatian
    Member

    Apologies – should have put that the export is monitored by GitLab, which is doing the compare via a hash value and reporting “changes” whenever SQLyog is upgraded.  This can only work on the full file, as far as I know.

     

    Other tools we use either don’t export the version number or have the ability, via flags, to suppress it, and so are Git friendly.  Just hoping for the same from SQLyog to make life a little bit easier.

     

    Another solution is to ask you not to release fixes and improvements so often!

     

    Regards,

     

    Ian

  • #35352

    peterlaursen
    Participant

    Now look at this

     

    /*

    SQLyog Job Agent v12.1 (64 bit) Copyright(c) Webyog Inc. All Rights Reserved.

    MySQL – 5.6.17 : Database – sys-controls

    *********************************************************************

    */

     

     

     

    What about the MySQL version information (“MySQL – 5.6.17 : Database – sys-controls”) .. is this a problem? Would this (below) be OK for your needs?

     

     

    /*

    SQLyog Job Agent – Copyright(c) Webyog Inc. All Rights Reserved.

    MySQL – 5.6.17 : Database – sys-controls
    *********************************************************************
    */

     

     

     

    I think practically all backup programs – including mysqldump – provide such information on top of the dump.  And in case you use multiple programs it could be useful to identify what program generated a specific dump. 

  • #35353

    imaginatian
    Member

    Hi,

     

    The MySQL version number is also an issue, although that doesn’t change as often as SQLyog is updated.  Any change to MySQL is usually a bit more planned!

     

    We only export using SQLyog.

     

    You’re suggested header would be great.  Note that you don’t need to remove the 32/64 bit version information.

     

    Regards,

     

    Ian

  • #35354

    number_one
    Participant

    I think practically all backup programs – including mysqldump – provide such information on top of the dump.  And in case you use multiple programs it could be useful to identify what program generated a specific dump. 

     

    This doesn’t necessarily help for the problem at hand, but running mysqldump directly does include options to not add this type of information.

     

    For example:

     

    Don’t output date that export was run:


    --skip-dump-date

    Don’t output program version. server version, host info, etc:


    --skip-comments

    And if you are wanting to only track schema changes (without data at all), in addition to adding the –no-data parameter you can also post-process the file to remove autoincrement values from the table definitions:


    mysqldump [options] | sed s/ AUTO_INCREMENT=[0-9]*//g > exported_file.sql

    Here’s a full example that won’t include anything other than the raw schema **EDITED to add quote around sed expression**


    mysqldump -u[username] -p[password] --no-data --opt --routines --triggers --skip-dump-date --skip-comments --databases [database_name] | sed 's/ AUTO_INCREMENT=[0-9]*//g' > exported_schema_file.sql

You must be logged in to reply to this topic.