rails carrierwave backgrounder with delayed jobs t

2019-07-20 00:23发布

问题:

I am using carrierwave and carrierwave backgrounder(https://github.com/lardawge/carrierwave_backgrounder) with delayed job for uploading file in a background.whernver i try to upload my file, it uploads successfully and i can see that jobs are executed in the background , but i cant see any difference with using delayed job and without using delayed job.it takes same time to execute without delayed job as it takes with delayed job.dont know what went wrong plz help.Thanks in advance.

here is my Uploader

             # encoding: utf-8

        class AvatarUploader < CarrierWave::Uploader::Base

          # Include RMagick or MiniMagick support:
          # include CarrierWave::RMagick
          # include CarrierWave::MiniMagick

          include ::CarrierWave::Backgrounder::Delay
          include Sprockets::Helpers::RailsHelper

          include Sprockets::Helpers::IsolatedHelper
         # Choose what kind of storage to use for this uploader:
           storage :file
           # storage :fog

        # Override the directory where uploaded files will be stored.
        # This is a sensible default for uploaders that are meant to be mounted:
        def store_dir
          "uploads/#{model.class.to_s.underscore}/#{mounted_as}/#{model.id}"
        end

       def cache_dir
           ""
       end


        # Provide a default URL as a default if there hasn't been a file uploaded:
       def default_url
         "rails.png"
       end


    end

carrierwave backgrounder file inside config/initializers/carrierwave_backgrounder.rb

            CarrierWave::Backgrounder.configure do |c|
             c.backend :delayed_job, queue: :carrierwave 
            end

Post model

        class Post < ActiveRecord::Base
          attr_accessible :description , :avatar, :remote_avatar_url
          mount_uploader :avatar,   AvatarUploader
          process_in_background :avatar
          validates_presence_of :description
        end

Post controller action

        def create
          @post = Post.new(params[:post])
          respond_to do |format|
         if @post.save
           format.html { redirect_to @post, notice: 'Post was successfully created.' }
           format.json { render json: @post, status: :created, location: @post }
         else
           format.html { render action: "new" }
           format.json { render json: @post.errors, status: :unprocessable_entity }
         end
      end
    end

and here is my view

        <%= form_for(@post) do |f| %>
          <% if @post.errors.any? %>
          <div id="error_explanation">
          <h2><%= pluralize(@post.errors.count, "error") %> prohibited this post from      being saved:</h2>

         <ul>
         <% @post.errors.full_messages.each do |msg| %>
         <li><%= msg %></li>
         <% end %>
         </ul>
        </div>
       <% end %>

      <div class="field">
       <%= f.label :description %><br />
       <%= f.text_area :description %>
      </div>
      <div class="field">
       <%= f.file_field :avatar %>
      </div>
        <div class="actions">
        <%= f.submit %>
      </div>
     <% end %>

回答1:

CarrierWave Backgrounder doesn't do the initial file transfer in the background. It can do exactly two things:

process_in_background lets a background task handle "processing," which is what carrierwave calls the step where it resizes your image, changes the format, generates thumbnails, and does other custom manipulations. The original image is still "stored" (described below) as usual.

store_in_background lets a background task handle "storage," which is what carrierwave calls the step where it moves the uploaded image to its final location on the local disk, or on a remote server such as S3 if you're using fog.

You've configured your model to process_in_background, but your uploader isn't configured to do any processing, so you're observing no change, as expected. If you wanted, you could configure your model to also store_in_background, but because you're using local file storage (where file copies are generally quite fast), this, also, would have basically no effect on your application.

For more on processing and storage, see the Carrierwave Readme.



回答2:

I recommend you to use Carrierwave Direct instead.