Skip to content
This repository has been archived by the owner on Mar 21, 2022. It is now read-only.

Django signal triggers. #1

Open
bryanhelmig opened this issue Oct 28, 2012 · 3 comments
Open

Django signal triggers. #1

bryanhelmig opened this issue Oct 28, 2012 · 3 comments

Comments

@bryanhelmig
Copy link
Member

Might be cool to trigger off of any registered Django signal like User created, updated, deleted, etc...

@kmtracey
Copy link
Contributor

I was curious if you had any pointers on how you were thinking of approaching this? I have a need to send users email on creation of "any specified model"...so not necessarily user User creation. For my needs (at least now), it is just model instance creation that would need to trigger email, so post_save is the only signal I'd need to support. I do need to have the admin interface allow the admin to choose the model that would trigger the drip. So one drip might be associated with the creation of new Articles while another might be associated with the creation of new BlogPosts.

For my current needs, adding a ForeignKey to a ContentType into the Drip model, a post_save signal handler connection, and the signal handler itself seem sufficient to accomplish what I'm looking for, but far less ambitious than what seems to be envisioned for this issue...so I was wondering what thoughts you might have already had on how to add general "trigger on signal" support? Essentially I'm wondering if I can fit my needs into the approach you may have been thinking of taking, and thus try to feed back work I do for my project into building out this feature.

@kmtracey
Copy link
Contributor

For reference, this: caktus@1d0c9e4 accomplishes what I need in terms of signal triggers. But it's seems more limited than what's envisioned here so I'm not sure how well it would fit in with the overall direction you were thinking of taking for this feature?

@bryanhelmig
Copy link
Member Author

Ideally drip would maintain a list of available signals (though it is likely post_save would be the most common). There would be a new model called Trigger that would represent both querysets (like we do already) but also let you register to signals (and the sender Model for post_save) as well. Drip would connect to that signal, and each time it receives the signal it would do a query to see if there are any drips to be sent.

The problem with this is it is done inline with the signal, meaning it is rather expensive. Much better would be a task that gets dumped into a queue. This is all a rather complicated process TBH, not sure if it is worth it...

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

No branches or pull requests

2 participants