Skip to content

Releases: Koed00/django-q

v0.4.0

19 Jul 15:34
Compare
Choose a tag to compare

Please run python manage.py migrate after this update to add the new database columns

  • adds result groups
  • adds optional name to schedules
  • async() now has an optional group keyword
  • tasks created by a schedule will assume the schedule name as a group label, allowing for a schedule history
  • admin now has a sortable and searchable group column

New functions:

  • result_group(group_id) returns a list of results from a group
  • fetch_group(group_id) returns a list of task objects from a group
  • count_group(group_id) counts the number of results in a group
  • delete_group(group_id) deletes a group label or optionally the associated tasks

All these can be instructed to ignore or included failed tasks.

For more information check the Groups documentation.

v0.3.6

17 Jul 12:40
Compare
Choose a tag to compare
  • adds timeout option to tasks
  • expanded some tests

You can now override the global cluster timeout setting per task by adding the keyword `timeout=x' to the async command.

v0.3.5

15 Jul 22:01
Compare
Choose a tag to compare
  • Adds cpu affinity capability to the cluster.

You can now set the cpu affinity for the cluster workers, thanks to the optional psutil module. For example:

4 processors, 4 workers, cpu_affinity: 2

worker 1 cpu [0, 1]
worker 2 cpu [2, 3]
worker 3 cpu [0, 1]
worker 4 cpu [2, 3]

Cpu affinity can be tricky and is most helpful when dealing with very high traffic clusters and is therefor optional. Nonetheless it can in some cases help improve your clusters performance.
Read more about it at the cpu_affinity documentation.

Even though the psutil module is optional, I am working on using it for more feautures like cpu & memory reporting and remote cluster control.

v0.3.4

12 Jul 19:50
Compare
Choose a tag to compare
  • schedules of type ONCE will now auto delete after they've created a task
  • tested with arrow 0.6.0

Single run schedules now delete themselves after having created a task,if their repeats are negative (the default). If you want to retain the schedule and its result (the old behavior), set the repeats to any positive number.

This is useful if you want to have many delayed actions, but don't necessarily want to clutter the schedule list, like follow up emails. Schedules have a minimum delay of 1 minute with a resolution of 1 minute.

A higher resolution delay alternative is being worked on.

v0.3.3

10 Jul 10:41
Compare
Choose a tag to compare
  • Fixed save pruning regression caused by uuid as primary key.
  • Adds standard model sort on stopped and associated admin columns.

v0.3.2

09 Jul 19:27
Compare
Choose a tag to compare
  • adds a sync=True option to the async command
  • now tested with Django 1.7.9 & 1.8.3

Note: The sync option will bypass the Redis server and inject the task straight into a worker. This makes the execution blocking, but the result will be available immediately for debugging and testing. More info in the docs

Thanks to ambivalentno for the suggestion.

v0.3.1

08 Jul 20:50
Compare
Choose a tag to compare
  • fixes regression in schedule admin task link
  • fixes several problems with the tests in Django 1.7

v0.3.0

08 Jul 19:17
Compare
Choose a tag to compare
  • The primary key for tasks is now a uuid4.
  • All task lookup functions now prefer the uuid , but most will lookup with a name if needed.

Rationale: Django Q was using a LUID (locally unique id) combined with a standard Django pk to identify saved tasks . Even though problems associated with this design were minor and probably non-existent on a small scale, the ambitions of the project warrant an UUID (universally unique id). In that light it was best to do that sooner rather than later and deal with the inconvenience now.

Upgrading: if you upgrade from v0.2 or earlier, don't forget to migrate your database with python manage.py migrate django_q

Note: A side effect of upgrading will be that schedule links to the last run before the upgrade break in the admin. Those tasks will still be accessible in the model admin though. Everything will be fine after the next scheduled run.

UUIDField: Django 1.8 offers a dedicated UUIDField for models. Unfortunately this is not compatible with Django 1.7 and only offers improvements with PostgreSQL backends. All other backends get a CharField, so that was selected for now. This will be probably be upgraded once Django 1.7 extended support is deprecated at the end of the year.

v0.2.2

07 Jul 18:48
Compare
Choose a tag to compare
  • Improved stop procedure
  • Safer recycles and timeouts
  • Safer pusher and monitor respawns

v0.2.1.1

06 Jul 19:01
Compare
Choose a tag to compare

Bugfix release