README.md in clockwork-1.3.1 vs README.md in clockwork-2.0.0
- old
+ new
@@ -140,13 +140,13 @@
[other events if you have]
end
```
-This tells clockwork to fetch all `ClockworkDatabaseEvent` instances from the database, creating an internal clockwork event for each one, configured based on the instance's `frequency`, `at` and optionally `name` and `tz` methods. It also says to reload the events from the database every `1.minute`; we need pick up any changes in the database frequently (choose a sensible reload frequency by changing the `every:` option).
+This tells clockwork to fetch all `ClockworkDatabaseEvent` instances from the database, and create an internal clockwork event for each one. Each clockwork event will be configured based on the instance's `frequency` and, optionally, its `at`, `name`, `if?` and `tz` methods. The code above also says to reload the events from the database every `1.minute`; we need pick up any changes in the database frequently (choose a sensible reload frequency by changing the `every:` option).
-When one of the events is ready to be run (based on it's `frequency`, `at` and possible `tz` methods), clockwork arranges for the block passed to `sync_database_events` to be run. The above example shows how you could use either DelayedJob or Sidekiq to simply kick off a worker job. This approach is good because the ideal is to use clockwork as a simple scheduler, and avoid making it carry out any long-running tasks.
+When one of the events is ready to be run (based on it's `frequency`, and possible `at`, `if?` and `tz` methods), clockwork arranges for the block passed to `sync_database_events` to be run. The above example shows how you could use either DelayedJob or Sidekiq to kick off a worker job. This approach is good because the ideal is to use clockwork as a simple scheduler, and avoid making it carry out any long-running tasks.
### Your Model Classes
`ActiveRecord` models are a perfect candidate for the model class. Having said that, the only requirements are:
@@ -156,14 +156,18 @@
- `id` returning a unique identifier (this is needed to track changes to event settings)
- `frequency` returning the how frequently (in seconds) the database event should be run
- - `at` return nil or `''` if not using `:at`, or otherwise any acceptable clockwork `:at` string
+ - `attributes` returning a hash of [attribute name] => [attribute value] values (or really anything that we can use store on registering the event, and then compare again to see if the state has changed later)
+ - (optionally) `at` return any acceptable clockwork `:at` string
+
- (optionally) `name` returning the name for the event (used to identify it in the Clcockwork output)
+ - (optionally) `if?` returning either true or false, depending on whether the database event should run at the given time (this method will be passed the time as a parameter, much like the standard clockwork `:if`)
+
- (optionally) `tz` returning the timezone to use (default is the local timezone)
#### Example Setup
Here's an example of one way of setting up your ActiveRecord models:
@@ -217,9 +221,31 @@
[:second, :minute, :hour, :day, :week, :month].each do |period|
FrequencyPeriod.create(name: period)
end
...
```
+
+#### Example use of `if?`
+
+Database events support the ability to run events if certain conditions are met. This can be used to only run events on a given day, week, or month, or really any criteria you could conceive. Best of all, these criteria e.g. which day to
+run it on can be attributes on your Model, and therefore change dynamically as you change the Model in the database.
+
+So for example, if you had a Model that had a `day` and `month` integer attribute, you could specify that the Database event should only run on a particular day of a particular month as follows:
+
+```ruby
+# app/models/clockwork_database_event.rb
+class ClockworkDatabaseEvent < ActiveRecord::Base
+
+ ...
+
+ def if?(time)
+ time.day == day && time.month == month
+ end
+
+ ...
+end
+```
+
Event Parameters
----------
### :at