in reply to Re^2: Tracking and deploying changes in (MySql/Maria) DB schema ...
in thread Tracking and deploying changes in (MySql/Maria) DB schema ...

Maybe I should have been more explicit about needing the incremental steps (i.e. ALTER TABLEs) and not just a diff between states.

Thought it's obviously better done this way. ( and easier documented)

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

  • Comment on Re^3: Tracking and deploying changes in (MySql/Maria) DB schema ...

Replies are listed 'Best First'.
Re^4: Tracking and deploying changes in (MySql/Maria) DB schema ...
by soonix (Chancellor) on May 23, 2019 at 00:58 UTC
    my crazy idea: Have a cron job doing hourly (or so)
    mysqldump ... git commit ...
    If the cron job is scheduled often enough, it would register the modifications with enough granularity.

      This is not crazy. It works. We did it like this with a huge MySQL DB for about 10 years. Best regards, Karl

      «The Crux of the Biscuit is the Apostrophe»

      perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'Help

        What about impact on resource usage? (That was my main reason for preliminarily calling it crazy)
Re^4: Tracking and deploying changes in (MySql/Maria) DB schema ...
by erix (Prior) on May 23, 2019 at 21:01 UTC
      This looks good, will try it out, thanks! :)

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

        And what are you going to tell the client in order to get him to install, configure and maintain this thing that he probaply doesn't want? I mean, it's a database plugin right, so it must run on the server.


        holli

        You can lead your users to water, but alas, you cannot drown them.