Releases: Koed00/django-q
v0.4.0
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 optionalgroup
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 groupfetch_group(group_id)
returns a list of task objects from a groupcount_group(group_id)
counts the number of results in a groupdelete_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
v0.3.5
- 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
- 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
v0.3.2
- adds a
sync=True
option to theasync
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
v0.3.0
- 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.