From 8ef9490f66a3813d015a95078d711d1f4c997110 Mon Sep 17 00:00:00 2001 From: epriestley Date: Thu, 8 Jun 2017 07:00:57 -0700 Subject: [PATCH] Add a retroactive migration to expand the `contentHash` field Summary: See D18037. The migration there may cause us to write new file records as a side effect. Ideally, we would rewrite that migration to not ever have this kind of side effect. However, that would make it much more complicated, and it's already very complicated. Instead, retroactively expand the size of this field before `storage adjust` does it, so it has the right size by the time we hit the migration in D18037. Test Plan: @chad, can you `arc patch` this and see if it works? It's possible that it will get us about five lines deeper and then we'll just hit another similar exception, and that this isn't really a viable way forward. Reviewers: chad, amckinley Reviewed By: amckinley Subscribers: amckinley, chad Differential Revision: https://secure.phabricator.com/D18107 --- .../sql/autopatches/20170404.files.retroactive-content-hash.sql | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 resources/sql/autopatches/20170404.files.retroactive-content-hash.sql diff --git a/resources/sql/autopatches/20170404.files.retroactive-content-hash.sql b/resources/sql/autopatches/20170404.files.retroactive-content-hash.sql new file mode 100644 index 0000000000..7c4eb0f013 --- /dev/null +++ b/resources/sql/autopatches/20170404.files.retroactive-content-hash.sql @@ -0,0 +1,2 @@ +ALTER TABLE {$NAMESPACE}_file.file + CHANGE contentHash contentHash BINARY(64); -- 2.51.2