DEV: create missing indexes

DEV: create missing indexes

These indexes should have been created in aa2a9da4

diff --git a/db/migrate/20200429095034_add_topic_thumbnail_information.rb b/db/migrate/20200429095034_add_topic_thumbnail_information.rb
index ee48265..2902d77 100644
--- a/db/migrate/20200429095034_add_topic_thumbnail_information.rb
+++ b/db/migrate/20200429095034_add_topic_thumbnail_information.rb
@@ -16,6 +16,16 @@ class AddTopicThumbnailInformation < ActiveRecord::Migration[6.0]
       ADD COLUMN IF NOT EXISTS image_upload_id bigint
     SQL
 
+    execute <<~SQL
+      CREATE INDEX CONCURRENTLY IF NOT EXISTS
+      index_posts_on_image_upload_id ON posts USING btree (image_upload_id);
+    SQL
+
+    execute <<~SQL
+      CREATE INDEX CONCURRENTLY IF NOT EXISTS
+      index_topics_on_image_upload_id ON public.topics USING btree (image_upload_id);
+    SQL
+
     ActiveRecord::Base.transaction do
       add_column :theme_modifier_sets, :topic_thumbnail_sizes, :string, array: true
 

GitHub sha: f4a53bd8

  1. Any reason that ON public.topics is used for one and ON posts (public missing) on the other?
  2. Shouldn’t all these be re-runnable as well, if the first part of the migration is?
add_column :theme_modifier_sets, :topic_thumbnail_sizes, :string, array: true

      create_table :topic_thumbnails do |t|
        t.references :upload, null: false
        t.references :optimized_image, null: true
        t.integer :max_width, null: false
        t.integer :max_height, null: false
      end

      add_index :topic_thumbnails, [:upload_id, :max_width, :max_height], name: :unique_topic_thumbnails, unique: true

E.g.

if !column_exists?(:theme_modifier_sets, :topic_thumbnail_sizes)
  add_column :theme_modifier_sets, :topic_thumbnail_sizes, :string, array: true
end

I guess this index is fine because the table is brand new – the name should be OK.

add_index :topic_thumbnails, [:upload_id, :max_width, :max_height], name: :unique_topic_thumbnails, unique: true

good catch … rushed cut and paste fail will fix

It is a bit of a lazy change but these are all tiny tables so the changes are extremely low risk. keeping it all in a transaction means it is re-runnable.

1 Like

Cool! Thanks for clearing up :+1:

1 Like