Page MenuHomePhabricator

Add a retroactive migration to expand the `contentHash` field
ClosedPublic

Authored by epriestley on Jun 8 2017, 2:07 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Apr 25, 3:45 AM
Unknown Object (File)
Thu, Apr 4, 3:07 PM
Unknown Object (File)
Thu, Apr 4, 2:10 PM
Unknown Object (File)
Mar 23 2024, 1:03 PM
Unknown Object (File)
Feb 13 2024, 4:45 PM
Unknown Object (File)
Jan 10 2024, 9:26 PM
Unknown Object (File)
Jan 1 2024, 6:49 PM
Unknown Object (File)
Jan 1 2024, 6:09 AM
Subscribers

Details

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.

Diff Detail

Repository
rP Phabricator
Branch
retro1
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 17453
Build 23399: Run Core Tests
Build 23398: arc lint + arc unit

Event Timeline

Gimmie a second, this is 100% wrong right now.

  • Use the correct column type.
  • Use the correct SQL syntax.
amckinley added a subscriber: amckinley.

Assuming I correctly understand all the discussion in D18037, this looks good to me.

This revision is now accepted and ready to land.Jun 8 2017, 2:18 PM

Alright, let's see how far we get with this.

This revision was automatically updated to reflect the committed changes.