Still around. At some point I really need to spend the time to write something worth posting here. Most of my notes end up in a private ticketing system with the goal of cleaning them up and posting publicly, but it’s not working out very well.
One thing I will be working on in the coming year is migrating many older/smaller projects over to GitHub. While SVN is still a very useful tool, GitHub is an amazing platform for collaborative development. I’ve been using it quite a bit in the last few months and I’ve come to really appreciate its usefulness. Where I once saw “forking” a project as harmful to a project, I’ve come to understand that Git doesn’t encourage a different model of thinking or coding, it just opens up some options that were not there before. The concern I had about developers taking the code, going off into a cave and not committing back is probably best handled by policy/development culture than it is by the version control system.
A lesson that I am continually (re)learning is that clarity comes after time has passed. By then the opportunity to undo harm (should it ever have been available) is often long gone. Realizing this either paralyzes you with indecision (I’m often afflicted by this), causes you to be cautious or perhaps encourages throwing caution to the wind. Such are the trials of an observant mind (optimistically speaking).
Life has been busy, very busy. Busy enough that I no longer have even a prayer of being bored. I could kick my childhood self for ever even daring to dream of growing up in a hurry. 😉
Targeting a single database with these options:
mysqldump -u MY_DB_BACKUP_USER -p MY_DB_NAME --add-drop-table --add-drop-database > my_db_name_mmddyyyy.sql
will successfully backup the database, but if you were to restore the database backup file back into a database with a newer schema (additional tables for example) like so:
mysql -u my_db_access_user -p MY_DB_NAME < my_db_name_mmddyyyy.sql
you would end up with a “merged” version of the database that would have new tables from the more recent schema and restored tables from the backup:
I learned this the hard way recently when attempting to restore a database to an earlier version following a failed Redmine 3.0.2 upgrade. While this didn’t break anything (other than maybe a future upgrade attempt that doesn’t properly handle existing tables), it wasn’t what I intended.
Going forward, if I want to backup a single database and have the backup file contain the statement necessary to first drop the database before restoring it (a full restore for example), I’ll need to call the
mysqlbackup command like so:
mysqldump -u MY_DB_BACKUP_USER -p --databases MY_DB_NAME --add-drop-table --add-drop-database > my_db_name_mmddyyyy.sql
--databases statement. If you didn’t know this, I hope it helps you from making the same mistake.
Even when hope is in short supply.