Re^6: Tracking and deploying changes in (MySql/Maria) DB schema ...

Replies are listed 'Best First'.
Re^7: Tracking and deploying changes in (MySql/Maria) DB schema ... by karlgoethebier (Abbot) on May 23, 2019 at 14:17 UTC
Terrific, to be honest. A restore of a full dump lasted one day or so. If this is what you where talking about. Totally out of question. But this case happened 2 or 3 times. In most cases it was enough to roll back/change 2 or 3 tables. Due to some strange design this had no impact on data consistency. At least the customer believed this. BTW, unfortunately MySQL dumps are plain text files. This design is totally fubar IMHO. 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	[reply] [d/l]
Re^8: Tracking and deploying changes in (MySql/Maria) DB schema ... by soonix (Canon) on May 24, 2019 at 05:42 UTC
No, I meant a `mysqldump --no-data …`	[reply] [d/l]
Re^9: Tracking and deploying changes in (MySql/Maria) DB schema ... by karlgoethebier (Abbot) on May 24, 2019 at 11:39 UTC
Ja, sure. Regards, Karl P.S.: Some use to shred the schema as well as the data. And perhaps I replied too fast 🤪 «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	[reply] [d/l]


Do you know where your variables are?
	PerlMonks