Skip to content
Commits on Apr 8, 2016
  1. @robisenberg

    Version 2.0.0

    robisenberg committed Apr 8, 2016
    Change of implementation for how we determine if database-backed events have changed during sync (as part of #180), meant that subtle changes could be introduced affecting existing users. So, although no public API changes, it seemed safer to bump the major version, to avoid backwards compatibility issues.
  2. @robisenberg

    Merge pull request #180 from robisenberg/database_event_ifs

    robisenberg committed Apr 8, 2016
    Database-backed events can now set clockwork event :if
  3. @robisenberg

    Database-backed events can now set clockwork event :if

    robisenberg committed Apr 8, 2016
    Resolves #153, resolves #147 and resolves #113.
    
    An oft-requested feature is to make Database-backed events make use somehow of clockwork's :if option.
    For a long time, this seemed impossible to me because the only approach I could envisage was to store Ruby
    code in a text field in the database model, and eval it (clearly a bad idea!) However, @adrianpcastro
    in #153 suggested an infinitely better approach, that for some reason eluded me: simply having a "if" method
    in the database model.
    
    This commit implements that approach, and finally allows Database-backed events to use :if's in the same
    way as the standard clockwork events. See the updated README for usage details.
    
    As part of this work:
    
     * updated README to clarify, and explain usage
    
     * refactored how we determine whether a model has changed when we sync the models. Previously we checked
       if the name, frequency or at values had changed, and needed some complicated code to compare the model#at
       with those stored in each event created by clockwork, corresponding to a different at time.
    
       The new approach simply expects models to have an #attributes method (which ActiveRecord models already do)
       which outputs the attribute state as a hash. Now we simply store this, and then check to see if the state
       has changed when we sync.
    
       Although the public API is the same, this change could potentially cause a subtle change in behaviour in
       terms of syncing events, and for that reason we'll need to bump the major version
    
     * made the `at` method options for database event models (previously we required it to be defined, and to
       return either nil or '')
  4. @robisenberg

    Version 1.3.1

    robisenberg committed Apr 8, 2016
    Bugfix: file load error
  5. @robisenberg

    Merge pull request #178 from robisenberg/bugfix_unrequired_event_coll…

    robisenberg committed Apr 8, 2016
    …ection
    
    Bufix: file load error prevents clockwork from running
  6. @robisenberg

    Bufix: file load error prevents clockwork from running

    robisenberg committed Apr 8, 2016
    We were getting "`require': cannot load such file -- event_collection (LoadError)" due to the
    EventCollection not being required from EventSore.
Commits on Apr 1, 2016
  1. @robisenberg

    Version 1.3.0

    robisenberg committed Apr 1, 2016
    Major refactor of DatabaseEvents code
  2. @robisenberg

    Merge pull request #177 from robisenberg/refactor_database_events

    robisenberg committed Apr 1, 2016
    Refactor database events
  3. @robisenberg

    Major refactor of DatabaseEvents code

    robisenberg committed Mar 25, 2016
    Clarifying core concepts
    ------------------------
    
    The refactor started with clarifying core concepts, and giving them better names, e.g.
     * SyncPerformer -> Synchronizer
     * Registry -> EventStore
    
    Single Responsibility
    ---------------------
    
    Next, I tried to focus on the Single Responsibility Principle and identify the correct
    place the code should live. For example, if you look at the old SyncPerformer it knew
    a lot about At strings and arrays, which really wasn't it's concern. Compare this to
    the new, slimmed down Synchronizer - what it does should be much clearer.
    
    New EventCollection for grouping EventStore#related_events
    ----------------------------------------------------------
    
    An instance of your Model class can have an #at method specifying a comma-separated At
    string. A Clockwork DatabaseEvent::Event is created for each of these separate `At`s.
    This means, for a single Model instance, there could be several related events.
    
    Previously, we stored Model events in a Hash keyed by the Model id. If there were multiple
    events needed for a Model instance (because it had multiple `At`s) they were stored in an
    array inside that hash.
    
    Often we'd need to operate on that array of related events for a particular model instance
    (e.g. unregister all of them), but the EventStore (formerly Register) would need to handle
    managing that array of related events.
    
    Instead, we've created the concept of an EventCollection, which allows us to perform
    group operations in a single go, and provides somewhere to collect methods which act on a
    related set of Events.
    
    Miscellaenous Improvements
    --------------------------
    
    There were various other small tweaks and improvements along the way.
    
    Conclusion
    ----------
    
    Again, the code is still far from perfect, but I believe this is a big step in the
    right direction, and should be significantly more maintainable.
    
    Squashed Commits
    ----------------
    
      * Rename SyncPerformer -> Synchronizer
      * Remove unused DatabaseEvents::Synchronizer SYNCHRONIZERS
      * Refactor DatabaseEvents::Synchronizer#at_strings_for
      * Refactor DatabaseEvents::Synchronizer#create_or_recreate_event
      * Further refactoring of DatabaseEvents::Synchronizer#create_or_recreate_event
      * Extract building the options hash into separate methods.
      * WIP: Beginning to extract EventModelComparer object
      * Refactor DatabaseEvents::Synchronizer#sync
      * WIP: continuing refactor to separate responsibilities
      * Refactor DatabaseEvents::Synchronizer to simplify
      * Rename Registry -> EventStore, and minor refactor
      * Store related Events in EventGroup in EventStore (rather than array)
      * Rename EventGroup -> EventCollection
      * Remove unused DatabaseEvents::EventModelComparer
      * Rename EventStore's @event_groups -> @related_events
      * Use dependency injection to inject manager into EventCollection
      * Change public/private API for EventStore
      * Reorder methods in EventStore
      * Refactor EventCollection #model_ats and #at_strings_for
      * Refactor EventStore#options
      * Include some helpful comments explaining EventStore quirks
      * Fix missing newlines at end of several files
Commits on Mar 25, 2016
  1. @robisenberg

    Version 1.2.1

    robisenberg committed Mar 25, 2016
    Test suite refactor to remove test unit dependency and refactor tests for Minitest
  2. @robisenberg

    Merge pull request #176 from robisenberg/master

    robisenberg committed Mar 25, 2016
    Fix Mocha deprecation warnings when running tests
  3. @robisenberg
  4. @robisenberg

    Merge pull request #174 from summera/refactor-test-suite

    robisenberg committed Mar 25, 2016
    Remove test unit dependency and refactor tests for Minitest
Commits on Feb 15, 2016
  1. @summera
Commits on Feb 14, 2016
  1. @summera
Commits on Apr 14, 2015
  1. Version 1.2.0

    committed Apr 15, 2015
    Job name becomes optional, and options hash can take in place of job name.
    Kind contributors revised README.
  2. Merge branch 'ankane_fix'

    committed Apr 15, 2015
  3. Apply default job name

    committed Apr 15, 2015
  4. @ankane
  5. Merge pull request #146 from pmukerji/patch-1

    committed Apr 15, 2015
    Clarify README note about tasks being skipped
Commits on Apr 2, 2015
  1. @pmukerji
Commits on Jan 28, 2015
  1. Merge pull request #139 from dlackty/patch-1

    committed Jan 29, 2015
    Test against Ruby 2.2 and use bundler cache
  2. @dlackty

    Fix test failure for Ruby 2.2

    dlackty committed Jan 28, 2015
Commits on Jan 25, 2015
  1. @dlackty
Commits on Jan 18, 2015
Commits on Nov 24, 2014
  1. Merge pull request #137 from recursive-madman/patch-1

    committed Nov 24, 2014
    Update README.md
  2. @recursive-madman

    Update README.md

    recursive-madman committed Nov 24, 2014
    Being placed in bin/ doesn't make something a binary.
Commits on Nov 19, 2014
  1. Version 1.1.0

    committed Nov 19, 2014
    Accept #135 to fix drifting start time.
    As a side effect, sleep_timeout < 1 is disallowed.
  2. Remove .ruby-version

    committed Nov 19, 2014
    There are no need to restrict developer's ruby version.
    CI will detect problems.
  3. Warn if sleep_timeout < 1

    committed Nov 19, 2014
  4. Wait until the next second

    committed Nov 19, 2014
Commits on Nov 14, 2014
  1. @brianhempel

    Default sleep_timeout to 0.5 seconds to not skip any seconds

    brianhempel committed Nov 14, 2014
    Because sleep means “sleep at least this amount”, and because there is some processing between sleep calls (even though it’s trivial), with a sleep_timeout of 1 second it is possible for the manager to pass over a second without ticking. (E.g. tick at 10:00:00.999 and tick at 10:00:02.001, but nothing during 10:00:01).
    
    The previous commit ensures that Clockwork won’t let job start times drift later and later *as long as* the manager ticks once during every second.
    
    Changing the sleep_timeout to 0.5 seconds make sure the manager ticks at least once during every second.
    
    With this change and the previous commit, Clockwork *by default* will not allow jobs to start running later and later.
  2. @brianhempel

    Don’t let job start time drift later and later

    brianhempel committed Nov 14, 2014
    Because jobs were supposed to wait at least their period length before running again, their actual start time would slip further and further from their expected start time. (With the default sleep_timeout of 1 second, we observed a drift of about 0.6 seconds per period. On average, each hourly job ran 1 hour + 0.6 seconds later than the last.)
    
    For an hourly job, if the last job ran at 10:00:00.5 it should be safe to run again at 11:00:00.1. By pretending the last job actually ran at the beginning of the second (10:00:00.0) we are able to trigger the new job on time.
Something went wrong with that request. Please try again.