Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key collisions #19

Closed
chripede opened this issue Mar 3, 2015 · 3 comments
Closed

Key collisions #19

chripede opened this issue Mar 3, 2015 · 3 comments

Comments

@chripede
Copy link

chripede commented Mar 3, 2015

When sending Django models as args to tasks, part of the key is generated by converting the model to a string. This causes key collisions for us since we have multiple objects that outputs the same from __unicode__

I propose something like this https://github.com/chripede/celery-once/commit/a2b465ce8fd1aa6593cfb5bfe7712320e792bf5f to allow objects to create unique keys.

The code in my django model would look something like this

    def __unicode__(self):
        return self.domain

    def celery_once_key(self):
        return "{}-{}".format(self.pk, self.domain)
@cameronmaske
Copy link
Owner

@chripede Hey, thanks for the feature suggestion!
One way to achieve this with the current version of celery once is too pass UUID as an argument of the task, and limit celery once to look at that key, e.g. like...

e.g.

@tasks(base=QueueOnce, once={'key': ['pk']})
def example(model, pk):
  pass

I'm not sure how I feel about a custom method on objects. Celery tends to err away from passing around models.
For that reason, I'm hesitate to support this, unless others out there would really find it useful? I'm gonna close this out for now, but happy to revisit it, if it has others support.

@chripede
Copy link
Author

@cameronmaske while they tend to err away from it, they still allow it. Everyone has a different use case.

Anyways, I'll add a bogus parameter to my task to keep the keys unique.

@Skyross
Copy link

Skyross commented Nov 29, 2016

Why not to use self.request.id for that purpose?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants