jobba 1.0.1 → 1.1.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: f867ae880d3339b25e987267ac135429ee2fb80e
-  data.tar.gz: 3882b0e610200fe6b2c119dc46efe37261dea455
+  metadata.gz: be04439547ffdf5ad57d5ac3a3279ca10ed0ae5b
+  data.tar.gz: 13de0a5da8c25827bdef5a7dbb99143d3e12427b
 SHA512:
-  metadata.gz: 369cddf40dd02571641bd114043f8f70f74ba6b0803d191893a79f7375c40bfaa8114436fbabcbc95986d231491d4f86979af90564e8b284608f7cdad46b5553
-  data.tar.gz: 966e2fc051cd4d8c5f5c9a2abebb4286aa9960cfad46d77ca52bdbe06351bf92945963c1c3d7d0cf9694b3fe6b84ccfe7b0610cef169a125dbbfb1aaa251cbe4
+  metadata.gz: 1099b20ffe944620cf5d712eea9c64410da0fa877ac9695c27dfee3cf557f2c348eeeaf9ca44088fa4c42fe0f1e8b6f1d27541412e0211ad5f7d900a1625baaa
+  data.tar.gz: a041d7540f6518291bd659b881dd03fc74d942529786b7c70145c9c327b6261facb44d489c7fd33672fe23a29d446c799ce362494d4d018f1c9824c9d4c5c64a

data/README.md

@@ -19,6 +19,8 @@ or
 $> gem install jobba
 ```
 
+Semantic versioning will begin with version `2.0.0`.
+
 ## Configuration
 
 To configure Jobba, put the following code in your applications
@@ -54,7 +56,7 @@ call:
 Jobba::Status.find!(id)
 ```
 
-The results of `find!` will always start in an `unknown` state.
+The result of `find!` will start in an `unknown` state if the ID doesn't exist in Redis.
 
 ## Basic Use with ActiveJob
 
@@ -76,7 +78,7 @@ class MyJob < ::ActiveJob::Base
   def perform(*args, &block)
     # Pop the ID argument added by perform_later and get a Status
     status = Jobba::Status.find!(args.pop)
-    status.working!
+    status.started!
 
     # ... do stuff ...
 
@@ -91,7 +93,7 @@ One of the main functions of Jobba is to let a job advance its status through a
 
 * `unqueued`
 * `queued`
-* `working`
+* `started`
 * `succeeded`
 * `failed`
 * `killed`
@@ -100,7 +102,7 @@ One of the main functions of Jobba is to let a job advance its status through a
 Put a `Status` into one of these states by calling `that_state!`, e.g.
 
 ```ruby
-my_state.working!
+my_state.started!
 ```
 
 The `unqueued` state is entered when a `Status` is first created.  The `unknown` state is entered when `find!(id)` is called but the `id` is not known.  You can re-enter these states with the `!` methods, but note that the `recorded_at` timestamp will not be updated.
@@ -111,7 +113,7 @@ The **first time a state is entered**, a timestamp is recorded for that state.
 |-------|-----------|
 |unqueued  | recorded_at |
 |queued    | queued_at   |
-|working   | started_at  |
+|started   | started_at  |
 |succeeded | succeeded_at |
 |failed    | failed_at    |
 |killed    | killed_at    |
@@ -162,7 +164,7 @@ If you want to be able to query for all statuses that take a certain argument as
 my_status.add_job_arg(arg_name, arg)
 ```
 
-where `arg_name` is what the argument is called in your job (e.g. `"input_1"`) and `arg` is a way to identify the argument (e.g. `"gid://app/Person/72").
+where `arg_name` is what the argument is called in your job (e.g. `"input_1"`) and `arg` is a way to identify the argument (e.g. `"gid://app/Person/72"`).
 
 You probably will only want to track complex arguments, e.g. models in your application.  E.g. you could have a `Book` model and a `PublishBook` background job and you may want to see all of the `PublishBook` jobs that have status for the `Book` with ID `53`.
 
@@ -182,7 +184,7 @@ my_status.kill_requested?
 
 and if that returns `true`, it can attempt to gracefully terminate itself.
 
-Note that when a kill is requested, the job will continue to be in some other state (e.g. `working`) until it is in fact killed, at which point the job should call:
+Note that when a kill is requested, the job will continue to be in some other state (e.g. `started`) until it is in fact killed, at which point the job should call:
 
 ```ruby
 my_status.killed!
@@ -217,7 +219,7 @@ A `Status` object also methods to check if it is in certain states:
 * `reload!`
 * `unqueued?`
 * `queued?`
-* `working?`
+* `started?`
 * `succeeded?`
 * `failed?`
 * `killed?`
@@ -228,11 +230,11 @@ And two conveience methods for checking groups of states:
 * `completed?`
 * `incomplete?`
 
-You can also call `reload!` on a `Status` to have it reset its state to what is stored in redis.
+You can also call `reload!` on a `Status` to have it reset its state to what is stored in Redis.
 
 ## Deleting Job Statuses
 
-Once jobs are completed or otherwise no longer interesting, it'd be nice to clear them out of redis.  You can do this with:
+Once jobs are completed or otherwise no longer interesting, it'd be nice to clear them out of Redis.  You can do this with:
 
 ```ruby
 my_status.delete    # freaks out if `my_status` isn't complete
@@ -250,7 +252,7 @@ Jobba has an activerecord-like query interface for finding Status objects.
 ```ruby
 Jobba.where(state: :unqueued)
 Jobba.where(state: :queued)
-Jobba.where(state: :working)
+Jobba.where(state: :started)
 Jobba.where(state: :succeeded)
 Jobba.where(state: :failed)
 Jobba.where(state: :killed)
@@ -261,13 +263,13 @@ Two convenience "state" queries have been added:
 
 ```ruby
 Jobba.where(state: :completed)   # includes succeeded, failed
-Jobba.where(state: :incomplete)  # includes unqueued, queued, working, killed
+Jobba.where(state: :incomplete)  # includes unqueued, queued, started, killed
 ```
 
 You can query combinations of states too:
 
 ```ruby
-Jobba.where(state: [:queued, :working])
+Jobba.where(state: [:queued, :started])
 ```
 
 **State Timestamp**
@@ -328,7 +330,7 @@ When you have a query you can run the following methods on it.  These act like w
 * `empty?`
 * `count`
 
-`empty?` and `count` are performed in redis without bringing back all query results to Ruby.
+`empty?` and `count` are performed in Redis without bringing back all query results to Ruby.
 
 You can also call two special methods directly on `Jobba`:
 
@@ -363,7 +365,7 @@ Note that, in operations having to do with time, this gem ignores anything beyon
 
 ### Efficiency
 
-Jobba strives to do all of its operations as efficiently as possible using built-in redis operations.  If you find a place where the efficiency can be improved, please submit an issue or a pull request.
+Jobba strives to do all of its operations as efficiently as possible using built-in Redis operations.  If you find a place where the efficiency can be improved, please submit an issue or a pull request.
 
 ## TODO
 

data/lib/jobba/state.rb

@@ -13,7 +13,7 @@ class Jobba::State
 
   UNQUEUED        = new('unqueued', 'recorded_at')
   QUEUED          = new('queued', 'queued_at')
-  WORKING         = new('working', 'started_at')
+  STARTED         = new('started', 'started_at')
   SUCCEEDED       = new('succeeded', 'succeeded_at')
   FAILED          = new('failed', 'failed_at')
   KILLED          = new('killed', 'killed_at')
@@ -22,7 +22,7 @@ class Jobba::State
   ALL = [
     UNQUEUED,
     QUEUED,
-    WORKING,
+    STARTED,
     SUCCEEDED,
     FAILED,
     KILLED,
@@ -37,14 +37,14 @@ class Jobba::State
   INCOMPLETE = [
     UNQUEUED,
     QUEUED,
-    WORKING,
+    STARTED,
     KILLED
   ].freeze
 
   ENTERABLE = [
     UNQUEUED,
     QUEUED,
-    WORKING,
+    STARTED,
     SUCCEEDED,
     FAILED,
     KILLED,

data/lib/jobba/version.rb

@@ -1,3 +1,3 @@
 module Jobba
-  VERSION = "1.0.1"
+  VERSION = "1.1.0"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: jobba
 version: !ruby/object:Gem::Version
-  version: 1.0.1
+  version: 1.1.0
 platform: ruby
 authors:
 - JP Slavinsky
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2016-01-01 00:00:00.000000000 Z
+date: 2016-01-02 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: redis