All Versions
46
Latest Version
Avg Release Cycle
57 days
Latest Release
-

Changelog History
Page 2

  • v2.1.2 Changes

    September 04, 2019
    • Allow AsyncResult object used in MiniHuey to support the __call__() method to block and resolve the task result.
    • When running the django run_huey management command, the huey loggers will not be configured if another logging handler is already registered to the huey namespace.
    • โž• Added experimental contrib storage engine using kyoto tycoon <http://fallabs.com/kyototycoon>_ which supports task priority and the option to do automatic result expiration. Requires the ukt <https://github.com/coleifer/ukt>_ python package and a custom kyototycoon lua script.
    • ๐Ÿ‘ Allow the Sqlite storage engine busy timeout to be configured when instantiating SqliteHuey.

    View commits

  • v2.1.1 Changes

    August 07, 2019
    • ๐Ÿ“„ Ensure that task()-decorated functions retain their docstrings.
    • ๐Ÿ›  Fix logger setup so that the consumer log configuration is only applied to the huey namespace, rather than the root logger.
    • ๐Ÿ”ฆ Expose result, signal and disconnect_signal in the Django huey extension.
    • โž• Add SignedSerializer, which signs and validates task messages.
    • ๐Ÿ”จ Refactor the SqliteStorage so that it can be more easily extended to support other databases.

    View commits

  • v2.1.0 Changes

    June 06, 2019
    • Added new contrib module sql_huey, which uses peewee <https://github.com/coleifer/peewee>_ to provide storage layer using any of the supported databases (sqlite, mysql or postgresql).
    • โž• Added RedisExpireHuey, which modifies the usual Redis result storage logic to use an expire time for task result values. A consequence of this is that this storage implementation must keep all result keys at the top-level Redis keyspace. There are some small changes to the storage APIs as well, but will only possibly affect maintainers of alternative storage layers.
    • Also added a PriorityRedisExpireHuey which combines the priority-queue support from PriorityRedisHuey with the result-store expiration mechanism of RedisExpireHuey.
    • ๐Ÿ›  Fix gzip compatibility issue when using Python 2.x.
    • โž• Add option to Huey to use zlib as the compression method instead of gzip.
    • โž• Added FileStorageMethods storage mixin, which uses the filesystem for task result-store APIs (put, peek, pop).
    • The storage-specific Huey implementations (e.g. RedisHuey) are no longer subclasses, but instead are partial applications of the Huey constructor.

    View commits

  • v2.0.1 Changes

    April 03, 2019
    • โฑ Small fixes, fixed typo in Exception class being caught by scheduler.

    View commits

  • v2.0.0 Changes

    April 02, 2019

    View commits

    ๐Ÿš€ This section describes the changes in the 2.0.0 release. A detailed list of
    ๐Ÿ”„ changes can be found here: https://huey.readthedocs.io/en/latest/changes.html

    Overview of changes:

    • always_eager mode has been renamed to immediate mode. Unlike previous
      ๐Ÿ”– versions, immediate mode involves the same code paths used by the consumer
      โœ… process. This makes it easier to test features like task revocation and task
      โฑ scheduling without needing to run a dedicated consumer process. Immediate
      ๐Ÿ”ง mode uses an in-memory storage layer by default, but can be configured to use
      "live" storage like Redis or Sqlite.
    • ๐Ÿšš The events stream API has been removed in favor of simpler callback-driven
      ๐Ÿšฆ signals APIs. These
      ๐Ÿ”€ callbacks are executed synchronously within the huey consumer process.
    • A new serialization format is used in 2.0.0, however consumers running 2.0
      will continue to be able to read and deserialize messages enqueued by Huey
      ๐Ÿ”– version 1.11.0 for backwards compatibility.
    • ๐Ÿ‘Œ Support for task priorities.
    • ๐Ÿ†• New Serializer abstraction allows users to customize the serialization
      format used when reading and writing tasks.
    • โฑ Huey consumer and scheduler can be more easily run within the application
      ๐Ÿ–จ process, if you prefer not to run a separate consumer process.
    • Tasks can now specify an on_error handler, in addition to the
      ๐Ÿ‘ previously-supported on_complete handler.
    • Task pipelines return a special ResultGroup object which simplifies reading
      the results of a sequence of task executions.
    • SqliteHuey has been promoted out of contrib, onto an equal footing with
      ๐Ÿš€ RedisHuey. To simplify deployment, the dependency on
      ๐Ÿšš peewee was removed and the Sqlite
      storage engine uses the Python sqlite3 driver directly.
  • v1.11.0 Changes

    February 16, 2019

    View commits

    Backwards-incompatible changes

    Previously, it was possible for certain tasks to be silently ignored if a task with that name already existed in the registry. To fix this, I have made two changes:

    1. The task-name, when serialized, now consists of the task module and the name of the decorated function. So, "queue_task_foo" becomes "myapp.tasks.foo". ๐Ÿ‘ป 2. An exception will be raised when attempting to register a task function with the same module + name.

    Together, these changes are intended to fix problems described in #386.

    โฌ†๏ธ Because these changes will impact the serialization (and deserialization) of messages, it is important that you consume all tasks (including scheduled tasks) before upgrading.

    Always-eager mode changes

    In order to provide a more consistent API, tasks enqueued using always_eager mode will now return a dummy TaskResultWrapper implementation that wraps the return value of the task. This change is designed to provide the same API for reading task result values, regardless of whether you are using always-eager mode or not.

    Previously, tasks executed with always_eager would return the Python value directly from the task. When using Huey with the consumer, though, task results are not available immediately, so a special wrapper TaskResultWrapper is returned, which provides helper methods for retrieving the return value of the task. Going forward, always_eager tasks will return EagerTaskResultWrapper, which implements the same get() API that is typically used to retrieve task return values.

  • v1.10.5 Changes

    December 19, 2018

    View commits

    • โšก๏ธ Compatibility with redis-py 3.0, updated requirements / dependencies.
    • โž• Add pre-/post- hooks into the djhuey namespace.
  • v1.10.4 Changes

    November 14, 2018
    • 0๏ธโƒฃ Log time taken to execute tasks at default log level.
    • ๐Ÿ›  Fix missing import in SQLite storage backend.
    • ๐Ÿ”จ Small refactoring in Redis storage backend to make it easier to override the driver / client implementation.
    • ๐Ÿ›  Fix failing tests for simpledb storage backend.

    View commits

  • v1.10.3 Changes

    October 10, 2018
    • Fixed regression where in always eager mode exceptions within tasks were being swallowed instead of raised.
    • โž• Added an API for registering hooks to run when each worker process starts-up. This simplifies creating global/process-wide shared resources, such as a connection pool or database client. Documentation.

    View commits

  • v1.10.2 Changes

    October 10, 2018

    View commits

    • More granular "extras" installation options.