misc/firestuff
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Remove use of ```, which doesn't render well

Browse Source
This commit is contained in:
Ian Gulliver
2019-05-05 18:05:36 +00:00
parent 13fa0ddca6
commit 0863dec941
6 changed files with 33 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
2011-11-29-safer-data-changes.html
View File

@@ -9,10 +9,12 @@
<li>Don't run one-off executables against your database. Instead, have the executable print out SQL that it would have run to update the database. If something goes wrong, you don't have to model the behavior of the program; you can just look at the SQL.</li>
<li>Check the SQL files into source control somewhere. Manual changes tend to breed more manual changes to fix the fixes, so you never know when you'll want a record of what you twiddled in the past.</li>
<li>Include all fields from the primary key in the WHERE clause. This ensures that each statement only modifies one row. Even if this results in a huge list of changes, at least you know exactly what changed.</li>
<li>Include as many additional gating clauses as possible, linked with AND. For example, if you have a table of products and you want to set the price to 0.99 for everything that is currently set to 1.00, do:
<code>UPDATE Products SET Price=0.99 WHERE ProductId=2762 AND Price=1.00;
</code>
This ensures that if something else changes Price just before you run your change, you don't destroy that update.</li>
<li><p>Include as many additional gating clauses as possible, linked with AND. For example, if you have a table of products and you want to set the price to 0.99 for everything that is currently set to 1.00, do:</p>
<pre><code>UPDATE Products SET Price=0.99 WHERE ProductId=2762 AND Price=1.00;
</code></pre>
<p>This ensures that if something else changes Price just before you run your change, you don't destroy that update.</p></li>
<li>Record the number of rows affected by each statement, in case something unexpected happens.</li>
<li>Use transactions sensibly. Overly huge grouping of statements can block replication, but consider whether your changes will be toxic if partially applied.</li>
<li>Stop running changes on errors or warnings and let a human examine the output. Warnings like string truncation can be a sign of a broken change.</li>