1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00

Merge pull request #25378 from nikhilthombare/patch-1

Changed ActiveJob::Base to ApplicationJob in the Active Job guide [ci…
This commit is contained in:
प्रथमेश Sonpatki 2016-06-12 21:19:21 -07:00 committed by Rafael Mendonça França
parent 9b02e14a00
commit 8b77387379
No known key found for this signature in database
GPG key ID: FC23B6D0F1EEE948

View file

@ -62,12 +62,12 @@ $ bin/rails generate job guests_cleanup --queue urgent
```
If you don't want to use a generator, you could create your own file inside of
`app/jobs`, just make sure that it inherits from `ActiveJob::Base`.
`app/jobs`, just make sure that it inherits from `ApplicationJob`.
Here's what a job looks like:
```ruby
class GuestsCleanupJob < ActiveJob::Base
class GuestsCleanupJob < ApplicationJob
queue_as :default
def perform(*guests)
@ -141,7 +141,7 @@ end
You can also configure your backend on a per job basis.
```ruby
class GuestsCleanupJob < ActiveJob::Base
class GuestsCleanupJob < ApplicationJob
self.queue_adapter = :resque
#....
end
@ -171,7 +171,7 @@ Most of the adapters support multiple queues. With Active Job you can schedule
the job to run on a specific queue:
```ruby
class GuestsCleanupJob < ActiveJob::Base
class GuestsCleanupJob < ApplicationJob
queue_as :low_priority
#....
end
@ -189,7 +189,7 @@ module YourApp
end
# app/jobs/guests_cleanup_job.rb
class GuestsCleanupJob < ActiveJob::Base
class GuestsCleanupJob < ApplicationJob
queue_as :low_priority
#....
end
@ -212,7 +212,7 @@ module YourApp
end
# app/jobs/guests_cleanup_job.rb
class GuestsCleanupJob < ActiveJob::Base
class GuestsCleanupJob < ApplicationJob
queue_as :low_priority
#....
end
@ -234,7 +234,7 @@ block will be executed in the job context (so you can access `self.arguments`)
and you must return the queue name:
```ruby
class ProcessVideoJob < ActiveJob::Base
class ProcessVideoJob < ApplicationJob
queue_as do
video = self.arguments.first
if video.owner.premium?
@ -274,7 +274,7 @@ trigger logic during the life cycle of a job.
### Usage
```ruby
class GuestsCleanupJob < ActiveJob::Base
class GuestsCleanupJob < ApplicationJob
queue_as :default
before_enqueue do |job|
@ -331,7 +331,7 @@ Active Record objects to your job instead of class/id pairs, which you then have
to manually deserialize. Before, jobs would look like this:
```ruby
class TrashableCleanupJob < ActiveJob::Base
class TrashableCleanupJob < ApplicationJob
def perform(trashable_class, trashable_id, depth)
trashable = trashable_class.constantize.find(trashable_id)
trashable.cleanup(depth)
@ -342,7 +342,7 @@ end
Now you can simply do:
```ruby
class TrashableCleanupJob < ActiveJob::Base
class TrashableCleanupJob < ApplicationJob
def perform(trashable, depth)
trashable.cleanup(depth)
end
@ -360,7 +360,7 @@ Active Job provides a way to catch exceptions raised during the execution of the
job:
```ruby
class GuestsCleanupJob < ActiveJob::Base
class GuestsCleanupJob < ApplicationJob
queue_as :default
rescue_from(ActiveRecord::RecordNotFound) do |exception|