que 1.0.0.beta → 1.0.0.beta5

data/lib/que/worker.rb

@@ -1,12 +1,16 @@
 # frozen_string_literal: true
 
-# Workers wrap threads which continuously pull job pks from JobCache objects,
+# Workers wrap threads which continuously pull job pks from JobBuffer objects,
 # fetch and work those jobs, and export relevant data to ResultQueues.
 
+require 'set'
+
 module Que
   class Worker
     attr_reader :thread, :priority
 
+    VALID_LOG_LEVELS = [:debug, :info, :warn, :error, :fatal, :unknown].to_set.freeze
+
     SQL[:check_job] =
       %{
         SELECT 1 AS one
@@ -15,20 +19,20 @@ module Que
       }
 
     def initialize(
-      job_cache:,
+      job_buffer:,
       result_queue:,
       priority: nil,
       start_callback: nil
     )
 
       @priority     = Que.assert([NilClass, Integer], priority)
-      @job_cache    = Que.assert(JobCache, job_cache)
+      @job_buffer   = Que.assert(JobBuffer, job_buffer)
       @result_queue = Que.assert(ResultQueue, result_queue)
 
       Que.internal_log(:worker_instantiate, self) do
         {
           priority:     priority,
-          job_cache:    job_cache.object_id,
+          job_buffer:   job_buffer.object_id,
           result_queue: result_queue.object_id,
         }
       end
@@ -50,10 +54,17 @@ module Que
     private
 
     def work_loop
-      # Blocks until a job of the appropriate priority is available. If the
-      # queue is shutting down this will return nil, which breaks the loop and
+      # Blocks until a job of the appropriate priority is available.
+      # `fetch_next_metajob` normally returns a job to be processed.
+      # If the queue is shutting down it will return false, which breaks the loop and
       # lets the thread finish.
-      while metajob = fetch_next_metajob
+      while (metajob = fetch_next_metajob) != false
+        # If metajob is nil instead of false, we've hit a rare race condition where
+        # there was a job in the buffer when the worker code checked, but the job was
+        # picked up by the time we got around to shifting it off the buffer.
+        # Letting this case go unhandled leads to worker threads exiting pre-maturely, so
+        # we check explicitly and continue the loop.
+        next if metajob.nil?
         id = metajob.id
 
         Que.internal_log(:worker_received_job, self) { {id: id} }
@@ -80,7 +91,7 @@ module Que
     end
 
     def fetch_next_metajob
-      @job_cache.shift(*priority)
+      @job_buffer.shift(*priority)
     end
 
     def work_job(metajob)
@@ -89,22 +100,33 @@ module Que
       klass    = Que.constantize(job.fetch(:job_class))
       instance = klass.new(job)
 
-      Que.run_middleware(instance) { instance.tap(&:_run) }
+      Que.run_job_middleware(instance) { instance.tap(&:_run) }
 
-      log_message = {
-        level: :debug,
-        job_id: metajob.id,
-        elapsed: (Time.now - start),
-      }
+      elapsed = Time.now - start
 
-      if error = instance.que_error
-        log_message[:event] = :job_errored
-        log_message[:error] = "#{error.class}: #{error.message}".slice(0, 500)
-      else
-        log_message[:event] = :job_worked
-      end
+      log_level =
+        if instance.que_error
+          :error
+        else
+          instance.log_level(elapsed)
+        end
+
+      if VALID_LOG_LEVELS.include?(log_level)
+        log_message = {
+          level: log_level,
+          job_id: metajob.id,
+          elapsed: elapsed,
+        }
 
-      Que.log(log_message)
+        if error = instance.que_error
+          log_message[:event] = :job_errored
+          log_message[:error] = "#{error.class}: #{error.message}".slice(0, 500)
+        else
+          log_message[:event] = :job_worked
+        end
+
+        Que.log(log_message)
+      end
 
       instance
     rescue => error

data/lib/que.rb

@@ -35,7 +35,7 @@ module Que
   require_relative 'que/connection_pool'
   require_relative 'que/job_methods'
   require_relative 'que/job'
-  require_relative 'que/job_cache'
+  require_relative 'que/job_buffer'
   require_relative 'que/locker'
   require_relative 'que/metajob'
   require_relative 'que/migrations'
@@ -44,6 +44,12 @@ module Que
   require_relative 'que/version'
   require_relative 'que/worker'
 
+  class << self
+    attr_writer :default_queue
+  end
+
+  self.default_queue = nil
+
   class << self
     include Utils::Assertions
     include Utils::Constantization
@@ -65,7 +71,6 @@ module Que
 
     # Global configuration logic.
     attr_accessor :use_prepared_statements
-    attr_writer :default_queue
 
     def default_queue
       @default_queue || DEFAULT_QUEUE
@@ -77,8 +82,8 @@ module Que
         if conn.to_s == 'ActiveRecord'
           # Load and setup AR compatibility.
           require_relative 'que/active_record/connection'
-          m = Que::ActiveRecord::Connection::Middleware
-          middleware << m unless middleware.include?(m)
+          m = Que::ActiveRecord::Connection::JobMiddleware
+          job_middleware << m unless job_middleware.include?(m)
           Que::ActiveRecord::Connection.method(:checkout)
         else
           case conn.class.to_s

data/que.gemspec

@@ -10,7 +10,7 @@ Gem::Specification.new do |spec|
   spec.email         = ['christopher.m.hanks@gmail.com']
   spec.description   = %q{A job queue that uses PostgreSQL's advisory locks for speed and reliability.}
   spec.summary       = %q{A PostgreSQL-based Job Queue}
-  spec.homepage      = 'https://github.com/chanks/que'
+  spec.homepage      = 'https://github.com/que-rb/que'
   spec.license       = 'MIT'
 
   files_to_exclude = [
@@ -29,5 +29,5 @@ Gem::Specification.new do |spec|
   spec.test_files    = spec.files.grep(%r{^(test|spec|features)/})
   spec.require_paths = ['lib']
 
-  spec.add_development_dependency 'bundler', '~> 1.3'
+  spec.add_development_dependency 'bundler'
 end

metadata

@@ -1,29 +1,29 @@
 --- !ruby/object:Gem::Specification
 name: que
 version: !ruby/object:Gem::Version
-  version: 1.0.0.beta
+  version: 1.0.0.beta5
 platform: ruby
 authors:
 - Chris Hanks
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2017-10-25 00:00:00.000000000 Z
+date: 2021-12-23 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bundler
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '1.3'
+        version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '1.3'
+        version: '0'
 description: A job queue that uses PostgreSQL's advisory locks for speed and reliability.
 email:
 - christopher.m.hanks@gmail.com
@@ -32,7 +32,9 @@ executables:
 extensions: []
 extra_rdoc_files: []
 files:
+- ".github/workflows/tests.yml"
 - ".gitignore"
+- CHANGELOG.1.0.beta.md
 - CHANGELOG.md
 - LICENSE.txt
 - README.md
@@ -40,21 +42,6 @@ files:
 - bin/command_line_interface.rb
 - bin/que
 - docs/README.md
-- docs/active_job.md
-- docs/advanced_setup.md
-- docs/command_line_interface.md
-- docs/error_handling.md
-- docs/inspecting_the_queue.md
-- docs/job_helper_methods.md
-- docs/logging.md
-- docs/managing_workers.md
-- docs/middleware.md
-- docs/migrating.md
-- docs/multiple_queues.md
-- docs/shutting_down_safely.md
-- docs/using_plain_connections.md
-- docs/using_sequel.md
-- docs/writing_reliable_jobs.md
 - lib/que.rb
 - lib/que/active_job/extensions.rb
 - lib/que/active_record/connection.rb
@@ -62,7 +49,7 @@ files:
 - lib/que/connection.rb
 - lib/que/connection_pool.rb
 - lib/que/job.rb
-- lib/que/job_cache.rb
+- lib/que/job_buffer.rb
 - lib/que/job_methods.rb
 - lib/que/listener.rb
 - lib/que/locker.rb
@@ -93,7 +80,7 @@ files:
 - lib/que/version.rb
 - lib/que/worker.rb
 - que.gemspec
-homepage: https://github.com/chanks/que
+homepage: https://github.com/que-rb/que
 licenses:
 - MIT
 metadata: {}
@@ -112,8 +99,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: 1.3.1
 requirements: []
-rubyforge_project: 
-rubygems_version: 2.6.14
+rubygems_version: 3.1.6
 signing_key: 
 specification_version: 4
 summary: A PostgreSQL-based Job Queue

data/docs/active_job.md

@@ -1,6 +0,0 @@
-## Using Que With ActiveJob
-
-You can include `Que::ActiveJob::JobExtensions` into your `ApplicationJob` subclass to get support for all of Que's 
-[helper methods](/job_helper_methods.md). These methods will become no-ops if you use a queue adapter that isn't Que, so if you like to use a different adapter in development they shouldn't interfere.
-
-Additionally, including `Que::ActiveJob::JobExtensions` lets you define a run() method that supports keyword arguments.

data/docs/advanced_setup.md

@@ -1,49 +0,0 @@
-## Advanced Setup
-
-### Using ActiveRecord Without Rails
-
-If you're using both Rails and ActiveRecord, the README describes how to get started with Que (which is pretty straightforward, since it includes a Railtie that handles a lot of setup for you). Otherwise, you'll need to do some manual setup.
-
-If you're using ActiveRecord outside of Rails, you'll need to tell Que to piggyback on its connection pool after you've connected to the database:
-
-```ruby
-ActiveRecord::Base.establish_connection(ENV['DATABASE_URL'])
-
-require 'que'
-Que.connection = ActiveRecord
-```
-
-Then you can queue jobs just as you would in Rails:
-
-```ruby
-ActiveRecord::Base.transaction do
-  @user = User.create(params[:user])
-  SendRegistrationEmail.enqueue user_id: @user.id
-end
-```
-
-There are other docs to read if you're using [Sequel](https://github.com/chanks/que/blob/master/docs/using_sequel.md) or [plain Postgres connections](https://github.com/chanks/que/blob/master/docs/using_plain_connections.md) (with no ORM at all) instead of ActiveRecord.
-
-### Managing the Jobs Table
-
-After you've connected Que to the database, you can manage the jobs table. You'll want to migrate to a specific version in a migration file, to ensure that they work the same way even when you upgrade Que in the future:
-
-```ruby
-# Update the schema to version #4.
-Que.migrate! version: 4
-
-# Remove Que's jobs table entirely.
-Que.migrate! version: 0
-```
-
-There's also a helper method to clear all jobs from the jobs table:
-
-```ruby
-Que.clear!
-```
-
-### Other Setup
-
-Be sure to read the docs on [managing workers](https://github.com/chanks/que/blob/master/docs/managing_workers.md) for more information on using the worker pool.
-
-You'll also want to set up [logging](https://github.com/chanks/que/blob/master/docs/logging.md) and an [error handler](https://github.com/chanks/que/blob/master/docs/error_handling.md) to track errors raised by jobs.

data/docs/command_line_interface.md

@@ -1,45 +0,0 @@
-## Command Line Interface
-
-```
-usage: que [options] [file/to/require] ...
-    -h, --help                       Show this help text.
-    -i, --poll-interval [INTERVAL]   Set maximum interval between polls for available jobs, in seconds (default: 5)
-    -l, --log-level [LEVEL]          Set level at which to log to STDOUT (debug, info, warn, error, fatal) (default: info)
-    -q, --queue-name [NAME]          Set a queue name to work jobs from. Can be passed multiple times. (default: the default queue only)
-    -v, --version                    Print Que version and exit.
-    -w, --worker-count [COUNT]       Set number of workers in process (default: 6)
-        --connection-url [URL]       Set a custom database url to connect to for locking purposes.
-        --log-internals              Log verbosely about Que's internal state. Only recommended for debugging issues
-        --maximum-buffer-size [SIZE] Set maximum number of jobs to be cached in this process awaiting a worker (default: 8)
-        --minimum-buffer-size [SIZE] Set minimum number of jobs to be cached in this process awaiting a worker (default: 2)
-        --wait-period [PERIOD]       Set maximum interval between checks of the in-memory job queue, in milliseconds (default: 50)
-        --worker-priorities [LIST]   List of priorities to assign to workers, unspecified workers take jobs of any priority (default: 10,30,50)
-```
-
-Some explanation of the more unusual options:
-
-### worker-count and worker-priorities
-
-These options dictate the size and priority distribution of the worker pool. The default worker-count is 6 and the default worker-priorities is 10,30,50. This means that the default worker pool will have one worker that only works jobs with priorities under 10, one for priorities under 30, and one for priorities under 50. The leftover workers will work any job.
-
-For example, with these defaults, you could have a large backlog of jobs of priority 100. When a more important job (priority 40) comes in, there's guaranteed to be a free worker. If the process then becomes saturated with jobs of priority 40, and then a priority 20 job comes in, there's guaranteed to be a free worker for it, and so on.
-
-### poll-interval
-
-This option sets the number of seconds the process will wait between polls of the job queue. Jobs that are ready to be worked immediately will be broadcast via the LISTEN/NOTIFY system, so polling is unnecessary for them - polling is only necessary for jobs that are scheduled in the future or which are being delayed due to errors. The default is 5 seconds.
-
-### minimum-buffer-size and maximum-buffer-size
-
-These options set the size of the internal buffer that Que uses to cache job information until it's ready for workers. The default minimum is 2 and the maximum is 8, meaning that the process won't buffer more than 8 jobs that aren't yet ready to be worked, and will only resort to polling if the buffer dips below 2. If you don't want jobs to be buffered at all, you can set both of these values to zero.
-
-### connection-url
-
-This option sets the URL to be used to open a connection to the database for locking purposes. By default, Que will simply use a connection from the connection pool for locking - this option is only useful if your application connections can't use advisory locks - for example, if they're passed through an external connection pool like PgBouncer. In that case, you'll need to use this option to specify your actual database URL so that Que can establish a direct connection.
-
-### wait-period
-
-This option specifies (in milliseconds) how often the locking thread wakes up to check whether the workers have finished jobs, whether it's time to poll, etc. You shouldn't generally need to tweak this, but it may come in handy for some workloads. The default is 50 milliseconds.
-
-### log-internals
-
-This option instructs Que to output a lot of information about its internal state to the logger. It should only be used if it becomes necessary to debug issues.

data/docs/error_handling.md

@@ -1,94 +0,0 @@
-## Error Handling
-
-If an error is raised and left uncaught by your job, Que will save the error message and backtrace to the database and schedule the job to be retried later.
-
-If a given job fails repeatedly, Que will retry it at exponentially-increasing intervals equal to (failure_count^4 + 3) seconds. This means that a job will be retried 4 seconds after its first failure, 19 seconds after its second, 84 seconds after its third, 259 seconds after its fourth, and so on until it succeeds. This pattern is very similar to DelayedJob's. Alternately, you can define your own retry logic by setting an interval to delay each time, or a callable that accepts the number of failures and returns an interval:
-
-```ruby
-class MyJob < Que::Job
-  # Just retry a failed job every 5 seconds:
-  self.retry_interval = 5
-
-  # Always retry this job immediately (not recommended, or transient
-  # errors will spam your error reporting):
-  self.retry_interval = 0
-
-  # Increase the delay by 30 seconds every time this job fails:
-  self.retry_interval = proc { |count| count * 30 }
-end
-```
-
-There is a maximum_retry_count option for jobs. It defaults to 15 retries, which with the default retry interval means that a job will stop retrying after a little more than two days.
-
-## Error Notifications
-
-If you're using an error notification system (highly recommended, of course), you can hook Que into it by setting a callable as the error notifier:
-
-```ruby
-Que.error_notifier = proc do |error, job|
-  # Do whatever you want with the error object or job row here. Note that the
-  # job passed is not the actual job object, but the hash representing the job
-  # row in the database, which looks like:
-
-  # {
-  #   :priority => 100,
-  #   :run_at => "2017-09-15T20:18:52.018101Z",
-  #   :id => 172340879,
-  #   :job_class => "TestJob",
-  #   :error_count => 0,
-  #   :last_error_message => nil,
-  #   :queue => "default",
-  #   :last_error_backtrace => nil,
-  #   :finished_at => nil,
-  #   :expired_at => nil,
-  #   :args => [],
-  #   :data => {}
-  # }
-
-  # This is done because the job may not have been able to be deserialized
-  # properly, if the name of the job class was changed or the job class isn't
-  # loaded for some reason. The job argument may also be nil, if there was a
-  # connection failure or something similar.
-end
-```
-
-## Error-Specific Handling
-
-You can also define a handle_error method in your job, like so:
-
-```ruby
-class MyJob < Que::Job
-  def run(*args)
-    # Your code goes here.
-  end
-
-  def handle_error(error)
-    case error
-    when TemporaryError then retry_in 10.seconds
-    when PermanentError then expire
-    else super # Default (exponential backoff) behavior.
-    end
-  end
-end
-```
-
-The return value of handle_error determines whether the error object is passed to the error notifier. The helper methods like expire and retry_in return true, so these errors will be notified. You can explicitly return false to skip notification.
-
-```ruby
-class MyJob < Que::Job
-  def handle_error(error)
-    case error
-    when AnnoyingError
-      retry_in 10.seconds
-      false
-    when TransientError
-      super
-      error_count > 3
-    else
-      super # Default (exponential backoff) behavior.
-    end
-  end
-end
-```
-
-In this example, AnnoyingError will never be notified, while TransientError will only be notified once it has affected a given job at least three times.

data/docs/inspecting_the_queue.md

@@ -1,64 +0,0 @@
-## Inspecting the Queue
-
-In order to remain simple and compatible with any ORM (or no ORM at all), Que is really just a very thin wrapper around some raw SQL. There are two methods available that query the jobs table and Postgres' system catalogs to retrieve information on the current state of the queue:
-
-### Job Stats
-
-You can call `Que.job_stats` to return some aggregate data on the types of jobs currently in the queue. Example output:
-
-```ruby
-[
-  {
-    :job_class=>"ChargeCreditCard",
-    :count=>10,
-    :count_working=>4,
-    :count_errored=>2,
-    :highest_error_count=>5,
-    :oldest_run_at=>2017-09-08 16:13:18 -0400
-  },
-  {
-    :job_class=>"SendRegistrationEmail",
-    :count=>1,
-    :count_working=>0,
-    :count_errored=>0,
-    :highest_error_count=>0,
-    :oldest_run_at=>2017-09-08 17:13:18 -0400
-  }
-]
-```
-
-This tells you that, for instance, there are ten ChargeCreditCard jobs in the queue, four of which are currently being worked, and two of which have experienced errors. One of them has started to process but experienced an error five times. The oldest_run_at is helpful for determining how long jobs have been sitting around, if you have a large backlog.
-
-### Custom Queries
-
-If you're using ActiveRecord or Sequel, Que ships with models that wrap the job queue so you can write your own logic to inspect it. They include some helpful scopes to write your queries - see the gem source for a complete accounting.
-
-#### ActiveRecord Example
-
-``` ruby
-# app/models/que_job.rb
-
-require 'que/active_record/model'
-
-class QueJob < Que::ActiveRecord::Model
-end
-
-QueJob.finished.to_sql # => "SELECT \"que_jobs\".* FROM \"que_jobs\" WHERE (\"que_jobs\".\"finished_at\" IS NOT NULL)"
-
-# You could also name the model whatever you like, or just query from
-# Que::ActiveRecord::Model directly if you don't need to write your own model
-# logic.
-```
-
-#### Sequel Example
-
-``` ruby
-# app/models/que_job.rb
-
-require 'que/sequel/model'
-
-class QueJob < Que::Sequel::Model
-end
-
-QueJob.finished # => #<Sequel::Postgres::Dataset: "SELECT * FROM \"public\".\"que_jobs\" WHERE (\"public\".\"que_jobs\".\"finished_at\" IS NOT NULL)">
-```

data/docs/job_helper_methods.md

@@ -1,27 +0,0 @@
-## Job Helper Methods
-
-There are a number of instance methods on Que::Job that you can use in your jobs, preferably in transactions. See [Writing Reliable Jobs](/writing_reliable_jobs.md) for more information on where to use these methods.
-
-### destroy
-
-This method deletes the job from the queue table, ensuring that it won't be worked a second time.
-
-### finish
-
-This method marks the current job as finished, ensuring that it won't be worked a second time. This is like destroy, in that it finalizes a job, but this method leaves the job in the table, in case you want to query it later.
-
-### expire
-
-This method marks the current job as expired. It will be left in the table and won't be retried, but it will be easy to query for expired jobs. This method is called if the job exceeds its maximum_retry_count.
-
-### retry_in
-
-This method marks the current job to be retried later. You can pass a numeric to this method, in which case that is the number of seconds after which it can be retried (`retry_in(10)`, `retry_in(0.5)`), or, if you're using ActiveSupport, you can pass in a duration object (`retry_in(10.minutes)`). This automatically happens, with an exponentially-increasing interval, when the job encounters an error.
-
-### error_count
-
-This method returns the total number of times the job has errored, in case you want to modify the job's behavior after it has failed a given number of times.
-
-### default_resolve_action
-
-If you don't perform a resolve action (destroy, finish, expire, retry_in) while the job is worked, Que will call this method for you. By default it simply calls `destroy`, but you can override it in your Job subclasses if you wish - for example, to call `finish`, or to invoke some more complicated logic.

data/docs/logging.md

@@ -1,31 +0,0 @@
-## Logging
-
-By default, Que logs important information in JSON to either Rails' logger (when running in a Rails web process) or STDOUT (when running via the `que` executable). So, your logs will look something like:
-
-```
-I, [2017-08-12T05:07:31.094201 #4687]  INFO -- : {"lib":"que","hostname":"lovelace","pid":21626,"thread":21471100,"event":"job_worked","job_id":6157665,"elapsed":0.531411}
-```
-
-Of course you can have it log wherever you like:
-
-```ruby
-Que.logger = Logger.new(...)
-```
-
-If you don't like logging in JSON, you can also customize the format of the logging output by passing a callable object (such as a proc) to Que.log_formatter=. The proc should take a hash (the keys are symbols) and return a string. The keys and values are just as you would expect from the JSON output:
-
-```ruby
-Que.log_formatter = proc do |data|
-  "Thread number #{data[:thread]} experienced a #{data[:event]}"
-end
-```
-
-If the log formatter returns nil or false, nothing will be logged at all. You could use this to narrow down what you want to emit, for example:
-
-```ruby
-Que.log_formatter = proc do |data|
-  if [:job_worked, :job_unavailable].include?(data[:event])
-    JSON.dump(data)
-  end
-end
-```

data/docs/managing_workers.md

@@ -1,25 +0,0 @@
-## Managing Workers
-
-Que uses a multithreaded pool of workers to run jobs in parallel - this allows you to save memory by working many jobs simultaneously in the same process. The `que` executable starts up a pool of 6 workers by default. This is fine for most use cases, but the ideal number for your app will depend on your interpreter and what types of jobs you're running.
-
-Ruby MRI has a global interpreter lock (GIL), which prevents it from using more than one CPU core at a time. Having multiple workers running makes sense if your jobs tend to spend a lot of time in I/O (waiting on complex database queries, sending emails, making HTTP requests, etc.), as most jobs do. However, if your jobs are doing a lot of work in Ruby, they'll be spending a lot of time blocking each other, and having too many workers running will cause you to lose efficiency to context-switching. So, you'll want to choose the appropriate number of workers for your use case.
-
-### Working Jobs Via Executable
-
-```shell
-# Run a pool of 6 workers:
-que
-
-# Or configure the number of workers:
-que --worker-count 10
-```
-
-See `que -h` for a complete list of command-line options.
-
-### Thread-Unsafe Application Code
-
-If your application code is not thread-safe, you won't want any workers to be processing jobs while anything else is happening in the Ruby process. So, you'll want to run a single worker at a time, like so:
-
-```shell
-que --worker-count 1
-```

data/docs/middleware.md

@@ -1,15 +0,0 @@
-## Defining Middleware For Jobs
-
-You can define middleware to wrap jobs. For example:
-
-``` ruby
-Que.middleware.push(
-  -> (job, &block) {
-    # Do stuff with the job object - report on it, count time elapsed, etc.
-    block.call
-    nil # Doesn't matter what's returned.
-  }
-)
-```
-
-This API is experimental for the 1.0 beta and may change.

data/docs/migrating.md

@@ -1,27 +0,0 @@
-## Migrating
-
-Some new releases of Que may require updates to the database schema. It's recommended that you integrate these updates alongside your other database migrations. For example, when Que released version 0.6.0, the schema version was updated from 2 to 3. If you're running ActiveRecord, you could make a migration to perform this upgrade like so:
-
-```ruby
-class UpdateQue < ActiveRecord::Migration[5.0]
-  def self.up
-    Que.migrate! version: 3
-  end
-
-  def self.down
-    Que.migrate! version: 2
-  end
-end
-```
-
-This will make sure that your database schema stays consistent with your codebase. If you're looking for something quicker and dirtier, you can always manually migrate in a console session:
-
-```ruby
-# Change schema to version 3.
-Que.migrate! version: 3
-
-# Check your current schema version.
-Que.db_version #=> 3
-```
-
-Note that you can remove Que from your database completely by migrating to version 0.