django tutorial part 2: clarification about INSTALLED APPS

[Asi Dimbez]

Hi,
I'm a newbie, there is thing not clear to me in the tutorial, part 2. 
I left part 1 with poll app working ok.
In the tutorial, part 2, I read about INSTALLED_APPS :" That holds the 
names of all Django applications that are activated in this Django 
instance.."
Now, poll app worked from part 1 even without being listed in 
INSTALLED_APPS hence a simple app doesn't need to lie there in order to 
work.
So I thought that INSTALLED_APPS holds all the apps which use a database, 
but I also read:
Some of these applications make use of at least one database table
So it seems that there can be even apps listed in INSTALLED_APPS which 
don't use any database.

So, my question is: what are axactly those apps that need to be listed in 
INSTALLED_APPS?
Thanks
Asi


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5578c62f-7b90-419b-acc7-dadbe592f7d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to flush/clear database for single app, i.e. NOT the Project?

[JoeCodeswell]

How can I flush/clear database for single app, i.e. NOT the Project?

I have a multi-app project. 
In a particular app I created my model with single class. 
I populated the db for that model with the Admin Interface.
Now i have changed the model to have 2 classes related by a ForeignKey.
I ran makemigrations on that app and it said, "you are trying to add a 
non-nullable field 'song' to part without a default; we can't do that (the 
database needs something to populate existing rows)."
I don't want to keep the existing populated tables for that app.
How can i start over for that app?
I can see this happening again and again for me.

Thanks in advance.
Love and peace,
Joe

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/a0536660-04f6-46aa-a12f-ace995d49d07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to flush/clear database for single app, i.e. NOT the Project?

[Erik Cederstrand]

> Den 16. maj 2016 kl. 19.16 skrev JoeCodeswell :
> 
> How can I flush/clear database for single app, i.e. NOT the Project?
> 
> I have a multi-app project. 
> In a particular app I created my model with single class. 
> I populated the db for that model with the Admin Interface.
> Now i have changed the model to have 2 classes related by a ForeignKey.
> I ran makemigrations on that app and it said, "you are trying to add a 
> non-nullable field 'song' to part without a default; we can't do that (the 
> database needs something to populate existing rows)."
> I don't want to keep the existing populated tables for that app.

I can do it manually before the migration, i.e.:

   YourModel.objects.all().delete()

If you want to do it as part of the migration, then create a data migration 
(https://docs.djangoproject.com/en/1.9/topics/migrations/#data-migrations) that 
deletes all relevant model instances, and place the migration before the 
migration that adds the ForeignKey.

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/136259B2-2BE4-4AD0-A49E-5F4D7C4CC9A0%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Proxy in front of django app

[Maks Materkov]

Hi everyone!

i' ve got an unusual question, that is probably not very specific to 
django. We have a large multi-tenant django app, and we want to split all 
traffic between two tenants (tenant 1 and tenant 2, for now). This tenant 
will be connected to different databases. Our django app is 100% API, with 
token authentication. Every request has auth_token parameter (as GET or 
POST parameter). The token looks like: tenant1., tenant-2., 
tenant-3.xxx.

So, we want to route all traffic with tokens tenant1.xxx to app1 and tokens 
tenant2. to app2. to do this, we need to setup something like "proxy 
router" in front of out existing django app. We already using nginx, and we 
can route to different backends only if token is GET parameter. There is no 
way to route based on POST params, as far as I know. 

We are discussing several alternatives:

1) Add LUA module to nginx (this module can read POST body data) and 
perform routing here
2) Write another app (for example, based on Tornado or python3 asyncio) 
that will be reading POST and GET params and route traffic to appropriate 
django app. (or another languages? NodeJS (oh, no :) )? Go lang?)

What is the best option here for us? Or some completely different approach?

Thank you!

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/dad35089-0e36-4819-99e9-7ee7d269f458%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Possible bug with transaction.on_commit

[barthelemy]

Hi,

I believe that I encountered a bug or at least a serious limitation with 
transaction.on_commit in Django 1.9.x. Essentially, the on_commit hooks 
seem to be tied to the database connection instead of the transaction. This 
means that unrelated transactions may trigger on_commit hooks, which 
results in undesired execution order. Here is an example:

from django.db import transaction
from foobar.models import Model1, Model2


@transaction.atomic
def outer():
print("START - OUTER")
for i in range(4):
f1(i)
print("END - OUTER")


@transaction.atomic
def f1(i):
model = Model1(description="test {0}".format(i))
model.save()
transaction.on_commit(lambda: commit_hook(model, i))


def commit_hook(model, i):
print("START - on_commit hook")
f2(i)
print("STOP - on_commit hook")


@transaction.atomic
def f2(i):
print("CALLING F2")
model = Model2(description="test {0}".format(i))
model.save()


Some quick explanations: 

- outer is the outermost atomic block. f1 will only create a savepoint(). 
This works as expected, there is only one commit (trace erased for 
simplicity). 
- f2 is wrapped in an "outermost" atomic block and indeed, f2 will be 
called four times and there will be four commits (trace erased for 
simplicity).
- f1 register a commit_hook. I expect that at the end of outer(), all 
commit hooks will be called.


The expected trace is:
START - OUTER
END - OUTER
START - on_commit hook
CALLING F2
STOP - on_commit hook
START - on_commit hook
CALLING F2
STOP - on_commit hook
START - on_commit hook
CALLING F2
STOP - on_commit hook
START - on_commit hook
CALLING F2
STOP - on_commit hook

The actual trace (f2 is triggering the on_commit hooks registered in 
f1/outer):
START - OUTER
END - OUTER
START - on_commit hook
CALLING F2
START - on_commit hook
CALLING F2
START - on_commit hook
CALLING F2
START - on_commit hook
CALLING F2
STOP - on_commit hook
STOP - on_commit hook
STOP - on_commit hook
STOP - on_commit hook

I wanted to know if someone encountered this issue or if I am 
misunderstanding on_commit before opening a ticket.

Regards,
Bart

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5ddb1ee0-c27f-4cee-b28a-d8cca6d1cf5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proxy in front of django app

[Erik Cederstrand]

> Den 16. maj 2016 kl. 20.48 skrev Maks Materkov :
> 
> Hi everyone!
> 
> i' ve got an unusual question, that is probably not very specific to django. 
> We have a large multi-tenant django app, and we want to split all traffic 
> between two tenants (tenant 1 and tenant 2, for now). This tenant will be 
> connected to different databases. Our django app is 100% API, with token 
> authentication. Every request has auth_token parameter (as GET or POST 
> parameter). The token looks like: tenant1., tenant-2., tenant-3.xxx.
> 
> So, we want to route all traffic with tokens tenant1.xxx to app1 and tokens 
> tenant2. to app2. to do this, we need to setup something like "proxy 
> router" in front of out existing django app. We already using nginx, and we 
> can route to different backends only if token is GET parameter. There is no 
> way to route based on POST params, as far as I know. 
> 
> We are discussing several alternatives:
> 
> 1) Add LUA module to nginx (this module can read POST body data) and perform 
> routing here
> 2) Write another app (for example, based on Tornado or python3 asyncio) that 
> will be reading POST and GET params and route traffic to appropriate django 
> app. (or another languages? NodeJS (oh, no :) )? Go lang?)
> 
> What is the best option here for us? Or some completely different approach?

The answer to this depends in part on your performance requirements. Do you 
have *any* control of the client side? If so, you could simply send all API 
requests to tenant1.api.example.com, tenant2.api.example.com etc.

If you have no control over clients, the most simple solution would be to write 
a simple Django view that handles every request and passes it on to the correct 
backend. This keeps your code within Django. But this also requires two trips 
all the way down your stack and may not yield performance. I've had great 
success in the past with Nginx scripting, so that would be my next suggestion 
if the above are not viable. It may cost you a bit more in maintainability, 
though.

Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/F3BE4330-C320-4C0F-B04D-799747F12F48%40cederstrand.dk.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug with transaction.on_commit

[Stephen J. Butler]

I believe that's as designed. There's this part in the documentation of
"Database transactions":

Callbacks are not run until autocommit is restored on the connection
following the commit (because otherwise any queries done in a callback
would open an implicit transaction, preventing the connection from going
back into autocommit mode).
So on_commit is meant as a connection level hook, not a transaction level
one.

On Mon, May 16, 2016 at 3:10 PM,  wrote:

> Hi,
>
> I believe that I encountered a bug or at least a serious limitation with
> transaction.on_commit in Django 1.9.x. Essentially, the on_commit hooks
> seem to be tied to the database connection instead of the transaction. This
> means that unrelated transactions may trigger on_commit hooks, which
> results in undesired execution order. Here is an example:
>
> from django.db import transaction
> from foobar.models import Model1, Model2
>
>
> @transaction.atomic
> def outer():
> print("START - OUTER")
> for i in range(4):
> f1(i)
> print("END - OUTER")
>
>
> @transaction.atomic
> def f1(i):
> model = Model1(description="test {0}".format(i))
> model.save()
> transaction.on_commit(lambda: commit_hook(model, i))
>
>
> def commit_hook(model, i):
> print("START - on_commit hook")
> f2(i)
> print("STOP - on_commit hook")
>
>
> @transaction.atomic
> def f2(i):
> print("CALLING F2")
> model = Model2(description="test {0}".format(i))
> model.save()
>
>
> Some quick explanations:
>
> - outer is the outermost atomic block. f1 will only create a savepoint().
> This works as expected, there is only one commit (trace erased for
> simplicity).
> - f2 is wrapped in an "outermost" atomic block and indeed, f2 will be
> called four times and there will be four commits (trace erased for
> simplicity).
> - f1 register a commit_hook. I expect that at the end of outer(), all
> commit hooks will be called.
>
>
> The expected trace is:
> START - OUTER
> END - OUTER
> START - on_commit hook
> CALLING F2
> STOP - on_commit hook
> START - on_commit hook
> CALLING F2
> STOP - on_commit hook
> START - on_commit hook
> CALLING F2
> STOP - on_commit hook
> START - on_commit hook
> CALLING F2
> STOP - on_commit hook
>
> The actual trace (f2 is triggering the on_commit hooks registered in
> f1/outer):
> START - OUTER
> END - OUTER
> START - on_commit hook
> CALLING F2
> START - on_commit hook
> CALLING F2
> START - on_commit hook
> CALLING F2
> START - on_commit hook
> CALLING F2
> STOP - on_commit hook
> STOP - on_commit hook
> STOP - on_commit hook
> STOP - on_commit hook
>
> I wanted to know if someone encountered this issue or if I am
> misunderstanding on_commit before opening a ticket.
>
> Regards,
> Bart
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/5ddb1ee0-c27f-4cee-b28a-d8cca6d1cf5f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAD4ANxVxO8xLVfn48-vu6RnGhDSaAX_aMFXYbHAE%3DaSfugjXLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug with transaction.on_commit

[barthelemy]

The callbacks are indeed run when autocommit is restored, but they are not 
executed one after the other, i.e., they are not **all** executed when 
autocommit is restored. The relevant code in Django:

# Called by set_autocommit(...)
def run_and_clear_commit_hooks(self):
self.validate_no_atomic_block()
try:
while self.run_on_commit:
sids, func = self.run_on_commit.pop(0)
func()
finally:
self.run_on_commit = []

Although this looks like all callbacks are executed in this loop, if a new 
transaction occurs in a callback, the next transaction will in turn call 
set_autocommit and the remaining callbacks will be executed from the latter 
transaction creating a stack of calls instead of a sequence of calls.

As a degenerate example, if both f1/outer() and f2() register commit hooks, 
hooks registered by f1/outer() will be executed by f2() and hooks 
registered by f2() will be executed by f1/outer(). That seems quite 
counter-intuitive.

Another example: if I replace the commit_hook function in the previous code 
example by the following code, a deadlock will occur (this is the reason we 
discovered this unintuitive behavior):

def commit_hook(model, i):
lock.acquire()
f2(i) # will call commit_hook even if it was registered by f1()
lock.release()

I understand the implementation of commit hooks is not straightforward, but 
if this is really the intended behavior, the documentation should come with 
a more severe warning.

Bart

On Monday, May 16, 2016 at 4:27:45 PM UTC-4, Stephen Butler wrote:
>
> I believe that's as designed. There's this part in the documentation of 
> "Database transactions":
>
> Callbacks are not run until autocommit is restored on the connection 
> following the commit (because otherwise any queries done in a callback 
> would open an implicit transaction, preventing the connection from going 
> back into autocommit mode).
> So on_commit is meant as a connection level hook, not a transaction level 
> one.
>
> On Mon, May 16, 2016 at 3:10 PM, > 
> wrote:
>
>> Hi,
>>
>> I believe that I encountered a bug or at least a serious limitation with 
>> transaction.on_commit in Django 1.9.x. Essentially, the on_commit hooks 
>> seem to be tied to the database connection instead of the transaction. This 
>> means that unrelated transactions may trigger on_commit hooks, which 
>> results in undesired execution order. Here is an example:
>>
>> from django.db import transaction
>> from foobar.models import Model1, Model2
>>
>>
>> @transaction.atomic
>> def outer():
>> print("START - OUTER")
>> for i in range(4):
>> f1(i)
>> print("END - OUTER")
>>
>>
>> @transaction.atomic
>> def f1(i):
>> model = Model1(description="test {0}".format(i))
>> model.save()
>> transaction.on_commit(lambda: commit_hook(model, i))
>>
>>
>> def commit_hook(model, i):
>> print("START - on_commit hook")
>> f2(i)
>> print("STOP - on_commit hook")
>>
>>
>> @transaction.atomic
>> def f2(i):
>> print("CALLING F2")
>> model = Model2(description="test {0}".format(i))
>> model.save()
>>
>>
>> Some quick explanations: 
>>
>> - outer is the outermost atomic block. f1 will only create a savepoint(). 
>> This works as expected, there is only one commit (trace erased for 
>> simplicity). 
>> - f2 is wrapped in an "outermost" atomic block and indeed, f2 will be 
>> called four times and there will be four commits (trace erased for 
>> simplicity).
>> - f1 register a commit_hook. I expect that at the end of outer(), all 
>> commit hooks will be called.
>>
>>
>> The expected trace is:
>> START - OUTER
>> END - OUTER
>> START - on_commit hook
>> CALLING F2
>> STOP - on_commit hook
>> START - on_commit hook
>> CALLING F2
>> STOP - on_commit hook
>> START - on_commit hook
>> CALLING F2
>> STOP - on_commit hook
>> START - on_commit hook
>> CALLING F2
>> STOP - on_commit hook
>>
>> The actual trace (f2 is triggering the on_commit hooks registered in 
>> f1/outer):
>> START - OUTER
>> END - OUTER
>> START - on_commit hook
>> CALLING F2
>> START - on_commit hook
>> CALLING F2
>> START - on_commit hook
>> CALLING F2
>> START - on_commit hook
>> CALLING F2
>> STOP - on_commit hook
>> STOP - on_commit hook
>> STOP - on_commit hook
>> STOP - on_commit hook
>>
>> I wanted to know if someone encountered this issue or if I am 
>> misunderstanding on_commit before opening a ticket.
>>
>> Regards,
>> Bart
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-users...@googlegroups.com .
>> To post to this group, send email to django...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-users/5ddb1ee0-c27f-4cee-b28a-d8cca6d1cf5f

Re: django tutorial part 2: clarification about INSTALLED APPS

[Mike Dewhirst]

On 17/05/2016 1:42 AM, Asi Dimbez wrote:

Hi,
I'm a newbie, there is thing not clear to me in the tutorial, part 2.Â
I left part 1 with poll app working ok.
In the tutorial, part 2, I read about INSTALLED_APPS :"Â That holds the
names of all Django applications that are activated in this Django
instance.."
Now, poll app worked from part 1 even without being listed in
INSTALLED_APPS hence a simple app doesn't need to lie there in order to
work.


I can't remember the polls app clearly but I don't think you were using 
the web framework part of Django to get it working. If I recall, it was 
all in the console because the focus was only object/relational mapping 
and database.



So I thought that INSTALLED_APPS holds all the apps which use a
database, but I also read:
Some of these applications make use of at least one database table
So it seems that there can be even apps listed in INSTALLED_APPS which
don't use any database.


True.



So, my question is: what are axactly those apps that need to be listed
in INSTALLED_APPS?


Apps which Django needs to know about in the web framework. In other 
words, apps with models, urls, views and templates or which have 
utilities called from such apps using the app_name as a namespace.





Thanks
Asi


--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to django-users+unsubscr...@googlegroups.com
.
To post to this group, send email to django-users@googlegroups.com
.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/5578c62f-7b90-419b-acc7-dadbe592f7d6%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3a6a6ea2-06eb-cf2f-e87d-16f48ff1bfdc%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

Re: Proxy in front of django app

[Maks Materkov]

Thank you for answer.
Unfortunately, I don't have any control on the client side. All requests 
are coming to something like "api.example.com" and I need route requests on 
the server side.

Recently I've found another option. Some "api managment tools" like
http://www.openrepose.org
https://tyk.io
and others.

But I think this is an overkill for out task. For now, I think the best 
option would be to write some lua scripts at the Nginx level.

вторник, 17 мая 2016 г., 1:16:55 UTC+5 пользователь Erik Cederstrand 
написал:
>
>
> > Den 16. maj 2016 kl. 20.48 skrev Maks Materkov  >: 
> > 
> > Hi everyone! 
> > 
> > i' ve got an unusual question, that is probably not very specific to 
> django. We have a large multi-tenant django app, and we want to split all 
> traffic between two tenants (tenant 1 and tenant 2, for now). This tenant 
> will be connected to different databases. Our django app is 100% API, with 
> token authentication. Every request has auth_token parameter (as GET or 
> POST parameter). The token looks like: tenant1., tenant-2., 
> tenant-3.xxx. 
> > 
> > So, we want to route all traffic with tokens tenant1.xxx to app1 and 
> tokens tenant2. to app2. to do this, we need to setup something like 
> "proxy router" in front of out existing django app. We already using nginx, 
> and we can route to different backends only if token is GET parameter. 
> There is no way to route based on POST params, as far as I know. 
> > 
> > We are discussing several alternatives: 
> > 
> > 1) Add LUA module to nginx (this module can read POST body data) and 
> perform routing here 
> > 2) Write another app (for example, based on Tornado or python3 asyncio) 
> that will be reading POST and GET params and route traffic to appropriate 
> django app. (or another languages? NodeJS (oh, no :) )? Go lang?) 
> > 
> > What is the best option here for us? Or some completely different 
> approach? 
>
> The answer to this depends in part on your performance requirements. Do 
> you have *any* control of the client side? If so, you could simply send all 
> API requests to tenant1.api.example.com, tenant2.api.example.com etc. 
>
> If you have no control over clients, the most simple solution would be to 
> write a simple Django view that handles every request and passes it on to 
> the correct backend. This keeps your code within Django. But this also 
> requires two trips all the way down your stack and may not yield 
> performance. I've had great success in the past with Nginx scripting, so 
> that would be my next suggestion if the above are not viable. It may cost 
> you a bit more in maintainability, though. 
>
> Erik

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/646a516b-db5a-4cc4-a963-5b3c204d5c5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Possible bug with transaction.on_commit

[Carl Meyer]

Hi Bart,

On 05/16/2016 02:10 PM, barthel...@infobart.com wrote:
> I believe that I encountered a bug or at least a serious limitation with
> transaction.on_commit in Django 1.9.x. Essentially, the on_commit hooks
> seem to be tied to the database connection instead of the transaction.
> This means that unrelated transactions may trigger on_commit hooks,
> which results in undesired execution order.
[...]
> I wanted to know if someone encountered this issue or if I am
> misunderstanding on_commit before opening a ticket.

I am the author of on_commit, and I think the behavior you have
encountered is a bug that should be fixed. Doing additional database
work in `on_commit` callbacks wasn't really a use case I had in mind in
the design; I made sure it basically worked, but clearly didn't explore
it sufficiently in cases of multiple registered hooks.

Storing the on_commit state on the connection is not really optional,
since that's where _all_ transaction-related state is stored, but I
think it should still be possible to fix this. Perhaps by having
`run_and_clear_commit_hooks` copy the list of hooks into a local
variable and immediately clear the state on the connection before it
calls any of the hooks? Not entirely sure, need to add a failing test
and play with it a bit.

Thanks for catching and reporting this. If you'd be willing to file a
ticket in Trac, that'd be great.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/573AB193.5020807%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature