BigW Consortium Gitlab

  1. 17 Nov, 2017 1 commit
    • Prevent update_column_in_batches on large tables · d8be9814
      Sean McGivern authored
      add_column_with_default is implemented in terms of update_column_in_batches, but
      update_column_in_batches can be used independently. Neither of these should be
      used on the specified large tables, because they will cause issues on large
      instances like GitLab.com.
      
      This also ignores the cop for all existing migrations, renaming
      AddColumnWithDefaultToLargeTable where appropriate.
  2. 10 Oct, 2017 1 commit
  3. 14 Aug, 2017 1 commit
  4. 01 Aug, 2017 1 commit
  5. 26 Jul, 2017 1 commit
  6. 14 Jul, 2017 1 commit
  7. 13 Jun, 2017 1 commit
  8. 29 May, 2017 1 commit
  9. 28 Apr, 2017 3 commits
  10. 05 Apr, 2017 1 commit
  11. 07 Mar, 2017 1 commit
  12. 23 Feb, 2017 1 commit
  13. 10 Feb, 2017 1 commit
    • Enforce use of add_concurrent_foreign_key · 766060bc
      Yorick Peterse authored
      This adds a Rubocop rule to enforce the use of
      add_concurrent_foreign_key instead of the regular add_foreign_key
      method. This cop has been disabled for existing migrations so we don't
      need to change those.
  14. 08 Feb, 2017 2 commits
  15. 29 Jun, 2016 1 commit
    • Added RuboCop cops for checking DB migrations · c740445a
      Yorick Peterse authored
      There are currently two cops for this:
      
      * Migration/AddIndex: checks if indexes are added concurrently
      * Migration/ColumnWithDefault: checks if columns with default values are
        added in a concurrent manner
      
      Both cops are fairly simple and make no attempt at correcting the code
      as this is quite hard to do (e.g. modifications may need to be applied
      in various places in the same file). They however should provide enough
      to catch people ignoring the comments in generated migrations telling
      them to use add_concurrent_index or add_column_with_default.