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

Is there a way to abstract back the task selection code in our custom save override? #52

Closed
palewire opened this issue Jun 18, 2014 · 3 comments

Comments

@palewire
Copy link
Owner

It would be nice if we didn't have to do all this every time we implement a Celery based deployment.

@palewire palewire changed the title Is there a way to abstract back to the task selection code in our custom save override? Is there a way to abstract back the task selection code in our custom save override? Jun 18, 2014
@schwanksta
Copy link
Contributor

Agreed.

On Tuesday, June 17, 2014, Ben Welsh notifications@github.com wrote:

It would be nice if we didn't have to do all this
http://django-bakery.readthedocs.org/en/latest/buildablemodels.html#celery-task-queue-integration
every time we implement a Celery based deployment.


Reply to this email directly or view it on GitHub
#52.

-Ken Schwencke

@palewire
Copy link
Owner Author

Tell me what's wrong below.

  • Even if we abstract away the save override stuff we typically use, a user will need to specify the is_published boolean field that our system will use to test if an object has been published or unpublished.
  • My gut feeling is that you should have to opt in to the celery task system and it should not be on by default. That would mean we do not package celery with the setup.py and it would have to be installed with pip independently.
  • As for how you opt-in at the model level, I'm not sure but I think we have a couple options. There could be an optional boolean attribute you stick on the BuildableModel class we have now that would hook everything up. Or we could make child class on BuildableModel called AutomaticallyBuildableModel or BuildableModelWithTasks or something like that would have the extra attributes and tricks appended. Simply have your custom models inherit from that, specify your is_published field (and maybe we could have is_published as a sensible default) and it would hook in with the tasks right away.
  • We should make a new advanced usage section of the documentation that explains how to do this, once we've worked it out, as well as the JSON view stuff we ironed out recently
  • We should be able to come up with unit tests for the tasks by building some fake objects and verifying they exist (or don't) afterward.

@palewire
Copy link
Owner Author

I suppose the new model needs a delete() override as well? Something like:

    def delete(self, *args, **kwargs):
        # if obj.save(unpublish=False) has been passed, we skip the task.
        unpublish = kwargs.pop('unpublish', True)
        super(self.__class__, self).delete(*args, **kwargs)
        if not unpublish:
            pass
        else:
            tasks.unpublish.delay(self)

palewire added a commit that referenced this issue Jun 19, 2014
palewire added a commit that referenced this issue Jun 19, 2014
palewire added a commit that referenced this issue Jun 19, 2014
palewire added a commit that referenced this issue Jun 19, 2014
palewire added a commit that referenced this issue Jun 19, 2014
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

2 participants