search

cloudinary / cloudinary_gem

Cloudinary GEM for Ruby on Rails integration
https://cloudinary.com
420 stars 285 forks source link

Don't talk to server during tests (ActiveRecord callbacks) #148

Open adambrod opened 9 years ago

adambrod commented 9 years ago

This is related to https://github.com/cloudinary/cloudinary_gem/issues/23

It seems the cloudinary gem still makes remote calls to https://api.cloudinary.com/v1_1/[accountname]/image/destroy when destroy() is invoked on a model, even when CarrierWave is configured to use the file store and enable_processing is false

if Rails.env.test? or Rails.env.cucumber?
  CarrierWave.configure do |config|
    config.storage = :file
    config.enable_processing = false
  end
end

The relevant stack trace is below. We only started to notice this after upgrading to Rails 4.2 and setting config.active_record.raise_in_transactional_callbacks = true in application.rb. Since the remote call is made in an after_commit hook, the tests didn't see the problem.

Can you please update the cloudinary gem to skip the call is enabled_processing==false?

     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/cloudinary-1.0.75/lib/cloudinary/uploader.rb:284:in `call_api'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/cloudinary-1.0.75/lib/cloudinary/uploader.rb:133:in `destroy'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/cloudinary-1.0.75/lib/cloudinary/carrier_wave.rb:160:in `delete'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/carrierwave-0.10.0/lib/carrierwave/uploader/remove.rb:15:in `block in remove!'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/carrierwave-0.10.0/lib/carrierwave/uploader/callbacks.rb:17:in `with_callbacks'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/carrierwave-0.10.0/lib/carrierwave/uploader/remove.rb:14:in `remove!'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/carrierwave-0.10.0/lib/carrierwave/mount.rb:392:in `remove!'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/carrierwave-0.10.0/lib/carrierwave/mount.rb:195:in `remove_cover_image!'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/carrierwave-0.10.0/lib/carrierwave/orm/activerecord.rb:49:in `remove_cover_image!'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/activesupport-4.2.1/lib/active_support/callbacks.rb:432:in `block in make_lambda'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/activesupport-4.2.1/lib/active_support/callbacks.rb:253:in `call'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/activesupport-4.2.1/lib/active_support/callbacks.rb:253:in `block in conditional'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/activesupport-4.2.1/lib/active_support/callbacks.rb:506:in `call'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/activesupport-4.2.1/lib/active_support/callbacks.rb:506:in `block in call'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/activesupport-4.2.1/lib/active_support/callbacks.rb:506:in `each'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/activesupport-4.2.1/lib/active_support/callbacks.rb:506:in `call'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/activesupport-4.2.1/lib/active_support/callbacks.rb:92:in `_run_callbacks'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/activesupport-4.2.1/lib/active_support/callbacks.rb:776:in `_run_commit_callbacks'
     # /home/vagrant/.rvm/gems/ruby-2.1.6/gems/activerecord-4.2.1/lib/active_record/transactions.rb:314:in `committed!
taragano commented 9 years ago

When using Ruby on Rails together with CarrierWave, CarrierWave’s default behavior when destroying model records is to delete the associated uploaded images from Cloudinary as well. If you wish, you can modify this behavior by overriding the delete_remote? method in your CarrierWave uploader class and simply return false.

adambrod commented 9 years ago

That is a viable workaround, but it seems wrong and confusing. The wrong behavior is happening by default. If I've explicitly configured carrierwave to use the file store, I would never expect a call out to cloudinary's remote servers. I can make this change locally, but I'm still hoping you'll change the gem as you did with issue #23 to respect the enable_processing config parameter.

taragano commented 9 years ago

Thank you for your suggestion, our dev team will indeed consider to support this as a default behavior. In the meantime, can you please try returning self.enable_processing in delete_remote? and let me know if this works for you?

adambrod commented 9 years ago

This worked. Unfortunately we have three models that all have uploaders, so I had to modify all three classes, which seems like another smell to me, but it seems like our tests are okay now.

taragano commented 8 years ago

Hi @adambrod, I just wanted to check whether this issue can be closed or whether you still experience the same (or any other) issue?

adambrod commented 8 years ago

I assume you're just doing a sweep of old issues and didn't re-read this. I was able to hack around this by overriding a method in three different classes. I don't love it, but it's okay. It's fine if you want to close this, but I still think your gem shouldn't make remote calls if it's configured to use a local File store.