Scenario: We have a few users on the site who have previously uploaded a logo for their site. Recently, we changed the dimensions of this logo and would like all accounts to reflect this change (we've also removed retina_rails from our app). So we plan on making a migration to remove retina rails while at the same time looping through each account and re uploading the logos to normalize across all logos.
Currently, this is what the migration looks like:
class RemoveRetinaDimensionsFromAccounts < ActiveRecord::Migration
def change
remove_column :accounts, :retina_dimensions, :text
end
ActsAsTenant.configure.require_tenant = false
Account.all.each do |account|
if account.logo?
account.logo.cache_stored_file!
account.logo.retrieve_from_cache!(account.logo.cache_name)
account.logo.recreate_versions!(:small, :small)
account.save!
end
end
ActsAsTenant.configure.require_tenant = true
end
This is what our carrierwave.rb file looks like:
CarrierWave.configure do |config|
if Rails.env.test?
config.storage = :file
config.enable_processing = false
elsif Rails.env.development?
config.storage = :file
config.cache_dir = "#{Rails.root}/tmp/uploads"
elsif Rails.env.staging?
config.storage = :fog
config.cache_dir = "#{Rails.root}/tmp/uploads"
config.fog_credentials = {
:provider => 'AWS', # required
:aws_access_key_id => Rails.application.secrets.aws_access_key_id, # required
:aws_secret_access_key => Rails.application.secrets.aws_secret_access_key, # required
:region => 'us-west-2' # optional, defaults to 'us-east-1'
}
config.fog_directory = 'blvd-staging' # required
config.fog_public = false
end
end
I've tried to follow the advice mentioned in this link https://github.com/carrierwaveuploader/carrierwave/wiki/How-to%3A-Recreate-and-reprocess-your-files-stored-on-fog but it is not working. I've tested to make sure the cache is saving files, and it is. However, when I try and retrieve_from_cache! I'm unable to do so (as the cached file does not have a name).
This is what my cached files look like:
tmp uploads ##########-#####-####
Thank you.
Turns out I did not run the desired code block within the change block inside the migration so the code was never being executed.