Hi!

In my opinion, "the default case are solved with atomic block" seems to be
a workaround instead of a solution. I understand that signals in general
are evil and register global callbacks is not a very good solution, but I
think, that a orm should give some generic facility to attach code to
execute when a transaction is successfully committed or rolled back.

For example, one possible use case can be this:

import threading

from django.dispatch import receiver
from django.core.signals import request_started

from .signals import post_commit

_local = threading.local()
_local.post_commit_tasks = []

@receiver(post_commit, dispatch_uid="_run_defered_tasks")
def _run_defered_tasks(sender, **kwargs):
    while _local.post_commit_tasks:
        task = _local.post_commit_tasks.pop(0)
        task[0](*task[1], **task[2])

@receiver(request_started, dispatch_uid="_clean_tasks")
def _clean_tasks(sender, **kwargs):
    _local.post_commit_tasks = []

def delay_until_transaction(func, *args, **kwargs):
    _local.post_commit_tasks.append((func, args, kwargs))

This is one of much other examples that try to solve this (problem/use
case) out of django, and I think that django/django-orm should provide some
facility to defer execution some code after a transaction is commited or
rolled back.

In the last aaugustin comment, he suggest one approach without using global
signals, and it seems  very interesting approach. Can these  approach to be
generalized and included in django?

As Jesus said, it not seems a isolated problem, and would be awesome if
django provides some generic and good way to do this.

Greetings.
Andrey.




2014/1/10 Andreas Pelme <andr...@pelme.se>

>
> On 10 jan 2014, at 09:19, Jesús Espino <jespi...@gmail.com> wrote:
>
> > Hi folks!
> >
> > The propose is add post and pre signals for commit and rollback actions
> (as sqlalchemy orm events). This allows attach some code when a transaction
> is committed or rolled back.
> >
> > I have some problem, such as send email only when a transaction is
> committed successfully, and it's can be done with simple monkey patching
> the db backend. But it not appear to be an isolated problem, and would be
> awesome if these signals are included in core.
> >
> > If a purpose is accepted, I can take care of making the issue +
> pull-request.
> >
> > Greetings.
> > Jesus.
>
>
> Hi,
>
> This is a tricky issue that has been discussed earlier, you will probably
> want to check out ticket #14051:
>
> https://code.djangoproject.com/ticket/14051
>
> —
> Andreas Pelme
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/948D5F1E-F86D-44A0-9EEA-F1E9A6A4A382%40pelme.se
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be
>
http://www.niwi.be <http://www.niwi.be/page/about/>
https://github.com/niwibe

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAKn%3DmOOq-dE8Nc9b604DnUkriRp2mhW90nx5nfc9PUuNyHn4dA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to