Shai, Thanks for the note.
I thought about what you wrote a bit. I find your points compelling. I don't like the consequences of my proposed changes in terms of: 1. Error handling. The exceptions would be raised at the end of the transaction block and there's no simple way to handle them except to wrap the whole block in another large try-except block, or have some means of registering an on_error callback (which I'd be pretty much against introducing into signals). 2. The semantics around the respective behaviors of `send` and `send_robust` get more complicated, as exit state of the handlers couldn't be ensured to be returned in the tuples synchronously. I think this is also what you are implying by this point. This is a big change in the API guarantees there. 3. The semantics of `on_commit` have similar complications around raising exceptions. But that may be worth solving, and I think we might as well have new API semantics for that that aren't mixed into signals API. So unless anyone has objections, I'm going to put my branch on hold for now. If anyone still wants me to see if there's a way it can work I'm willing to give it a bit more work, however I think it should probably be passed over for the time being. Glad my post may have kicked off the conversation to get a eventual solution in. Next steps: is everyone agreed that attempting to merge Carl's django-transaction-hooks is the way forward? Happy to help on that if you guys need help. Pretty excited to get a post-commit hook into core in 1.9, no matter how that ends up happening. Best, Chris On Saturday, May 2, 2015 at 9:18:42 AM UTC-4, Shai Berger wrote: > > Hi, > > On Saturday 02 May 2015 07:20:00 Christopher Adams wrote: > > Hey guys, > > > > Thanks for the great feedback and replies. > > > > Generally agree with everyone that post-commit hooks shouldn't be > strictly > > coupled to the signals framework philosophically speaking. > > > > I disagree with Carl's premise that using `connection.on_commit` in your > > signal handler is simpler than adding `after_commit=True` as a kwarg. > > I think you're confusing "simple" with "easy", see > http://www.infoq.com/presentations/Simple-Made-Easy > > In particular, you are proposing to make one use-case easier, while making > the > semantics of the API much more complex (the most glaring point: With your > proposal, adding a keyword argument changes the signal handler invocation > from > synchronous to asynchronous, with everything that entails about error > handling). I am -1 on that API, regardless of the "one way to do it" > argument. > > > [using `connection.on_commit`] involves not only an extra import, but > also > > familiarity by developers with the notion of closure and callbacks. > Despite > > being a powerful feature of Python, this is not really as familiar a > usage > > pattern among developers > > It is quite easy to hide the use of connection.on_commit, including the > concepts of callback and closure, behind a small wrapper for handler > registration. I'd hesitate before putting it in core, but you can prove me > wrong by releasing it as a utility (or even a Django Snippet) and making > it > popular. > > HTH, > Shai. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b78c7f59-824e-4398-bcb2-117c04f783de%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
