Racing condition with pre_delete
I often run into a bug when the client triggers multiple http requests resulting each in a delete. My objects have a „sibling index“ field, where I use pre_delete to update all siblings „above“ to lower their index by 1 (using update with an F-expression). Any idea why this would not work reliably? I use Postgres as db-backend. Thx, Sebastian. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-users/fb39c2d8-a89d-4e4e-986a-081805b96d1fn%40googlegroups.com.
Re: Fix docs for model.save() with update_fields specified and auto_now field in model
Please advise if this is the right place to report such a doc enhancement request - anyone? BTW - in addition I also noticed that - using deserialization - object.save() gives unexpected different results for auto_now field: - if the object-pk aleady existed , the field is saved as given - but if it did not exist, the given value is ignored, and the current time is used instead ... very strange if you ask me... Cheers, Sebastian On Mon, Mar 25, 2019 at 4:34 PM Sebastian Haase wrote: > There are of course stackoverflow postings -e.g. > https://stackoverflow.com/questions/17474057/enforce-auto-now-when-using-saveupdate-fields > - > is almost 6 years old. > > On Monday, March 25, 2019 at 4:30:57 PM UTC+1, Sebastian Haase wrote: >> >> Hi, >> in section "Specifying which fields to save" ( >> https://docs.djangoproject.com/en/dev/ref/models/instances/#specifying-which-fields-to-save) >> it reads that `update_fields` can be specified mostly for performance >> benefits... >> However, I found that regarding a field with "auto_now=True" there is a >> different outcome. >> IOW, specifying `update_fields` can be used to keep the old date in >> respective "auto_now=True"-field UNLESS that field is also explicitly >> given un `update_fields` >> >> I hope I got this correct - at least that was the impression from my own >> tests with Django 2.1. Than this should be more prominently stated in the >> documentation. >> >> Thanks for Django. >> Sebastian >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Django users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-users/sqMrUlZP2-8/unsubscribe. > To unsubscribe from this group and all its topics, 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/0eabc3b1-ac4b-491b-a44b-0db1e611e85e%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/0eabc3b1-ac4b-491b-a44b-0db1e611e85e%40googlegroups.com?utm_medium=email_source=footer> > . > 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/CAN06oV-R7SJuW77OXdV5u9M8SrJEkVnYa6k46kk3Y%3DEnJ-2SpA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Fix docs for model.save() with update_fields specified and auto_now field in model
There are of course stackoverflow postings -e.g. https://stackoverflow.com/questions/17474057/enforce-auto-now-when-using-saveupdate-fields - is almost 6 years old. On Monday, March 25, 2019 at 4:30:57 PM UTC+1, Sebastian Haase wrote: > > Hi, > in section "Specifying which fields to save" ( > https://docs.djangoproject.com/en/dev/ref/models/instances/#specifying-which-fields-to-save) > > it reads that `update_fields` can be specified mostly for performance > benefits... > However, I found that regarding a field with "auto_now=True" there is a > different outcome. > IOW, specifying `update_fields` can be used to keep the old date in > respective "auto_now=True"-field UNLESS that field is also explicitly > given un `update_fields` > > I hope I got this correct - at least that was the impression from my own > tests with Django 2.1. Than this should be more prominently stated in the > documentation. > > Thanks for Django. > Sebastian > > -- 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/0eabc3b1-ac4b-491b-a44b-0db1e611e85e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Fix docs for model.save() with update_fields specified and auto_now field in model
Hi, in section "Specifying which fields to save" (https://docs.djangoproject.com/en/dev/ref/models/instances/#specifying-which-fields-to-save) it reads that `update_fields` can be specified mostly for performance benefits... However, I found that regarding a field with "auto_now=True" there is a different outcome. IOW, specifying `update_fields` can be used to keep the old date in respective "auto_now=True"-field UNLESS that field is also explicitly given un `update_fields` I hope I got this correct - at least that was the impression from my own tests with Django 2.1. Than this should be more prominently stated in the documentation. Thanks for Django. Sebastian -- 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/e2eb3a04-9c61-4a54-889f-32a5525b34a7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Django Channels: long running async function and where to save ORM object
Thanks for the reply. Should I still use async code inside that worker process ? While developing I simply do arun_serveron the command line -- then I would always have to do arun_worker in addition -- right ? -Sebastian On Mon, Jul 16, 2018 at 7:05 PM, Andrew Godwin wrote: > You are correct in that you could store the model instance on "self" but > this would result in caching issues, as that instance would not be updated > after the initial socket connection. > > If you want to run "background routines", I would discourage you from > doing these as random orphaned tasks launched from web processes - there's > no provision in the server to track that task and clean up after it. > Instead, I'd recommend running those kinds of tasks in a separate process. > > Andrew > > On Sun, Jul 15, 2018 at 2:03 AM Sebastian Haase > wrote: > >> Hi, >> I'm still in the process of migration from channels 1 to channels 2... >> >> One thing I'm interested in is related to [ http://channels.readthedocs. >> io/en/latest/one-to-two.html#application-instances ] >> """ASGI applications are now instantiated once per socket and can use >> local variables on self to store information""" >> >> So, we have an `AsyncJsonWebsocketConsumer` where websocket clients want >> to operate on a django model instance - each websocket mostly on the same >> object. >> With channels 1 we would always send with each message the `objID` - >> doing `obj=model.objects.get(pk=objID)` and read/write on `obj`. >> In channels 2 I could save the `objID` server side in the consumer class >> - like `self.objID` with one initial message like `set-obj-id`. >> For the ORM access I now have to do `obj = await database_sync_to_async( >> model.objects.get )(pk=self.objID)` >> >> QUESTION: Is is legitimate to store the "model instance itself" like >> `self.obj = await database_sync_to_async( model.objects.get )(pk=objID)` >> and keep that instance around for the lifetime of that socket -- doing some >> `await database_sync_to_async( self.obj.save )()` on some respective >> messages ? >> Note: multiple websockets might operate on the same obj/objID ! So my >> feeling is that would work as long as I keep testing with the `runserver` >> or in production as long as I know that I have only ONE PROCESS -- but in >> general the django caching mechanism might cause inconsistencies ... !? >> >> >> Another, somewhat related question is regarding a kind of "background >> routine" that I started to implement as an asyncio Task. >> Note: It was kind of tricky to realize that I needed >> `asyncio.ensure_future` to get it run asynchronously -- ref. >> https://stackoverflow.com/questions/48871831/django- >> channels-async-consumer-does-not-appear-to-execute-asynchronously >> Maybe that could be worked into the channels docs maybe here: >> http://channels.readthedocs.io/en/latest/topics/worker.html >> Since that "routine" should be able to be canceled and pauses (I'm using >> an asyncio.event) from any websocket consumer: >> QUESTION: What is the best place to store that Task object ? Again with >> `runserver` I can just use a global module-level `dict` to keep those Task >> objects. >> >> The whole async experience is really twisting my mind and interesting at >> the same time ;-) >> Regards, >> Sebastian >> >> -- 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/CAN06oV-ySRN%3D-9BEKd8SfvgB52F3QagNMh_rZqQQ6wCS3HFEkg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Django Channels: long running async function and where to save ORM object
Hi, I'm still in the process of migration from channels 1 to channels 2... One thing I'm interested in is related to [ http://channels.readthedocs.io/en/latest/one-to-two.html#application-instances ] """ASGI applications are now instantiated once per socket and can use local variables on self to store information""" So, we have an `AsyncJsonWebsocketConsumer` where websocket clients want to operate on a django model instance - each websocket mostly on the same object. With channels 1 we would always send with each message the `objID` - doing `obj=model.objects.get(pk=objID)` and read/write on `obj`. In channels 2 I could save the `objID` server side in the consumer class - like `self.objID` with one initial message like `set-obj-id`. For the ORM access I now have to do `obj = await database_sync_to_async( model.objects.get )(pk=self.objID)` QUESTION: Is is legitimate to store the "model instance itself" like `self.obj = await database_sync_to_async( model.objects.get )(pk=objID)` and keep that instance around for the lifetime of that socket -- doing some `await database_sync_to_async( self.obj.save )()` on some respective messages ? Note: multiple websockets might operate on the same obj/objID ! So my feeling is that would work as long as I keep testing with the `runserver` or in production as long as I know that I have only ONE PROCESS -- but in general the django caching mechanism might cause inconsistencies ... !? Another, somewhat related question is regarding a kind of "background routine" that I started to implement as an asyncio Task. Note: It was kind of tricky to realize that I needed `asyncio.ensure_future` to get it run asynchronously -- ref. https://stackoverflow.com/questions/48871831/django-channels-async-consumer-does-not-appear-to-execute-asynchronously Maybe that could be worked into the channels docs maybe here: http://channels.readthedocs.io/en/latest/topics/worker.html Since that "routine" should be able to be canceled and pauses (I'm using an asyncio.event) from any websocket consumer: QUESTION: What is the best place to store that Task object ? Again with `runserver` I can just use a global module-level `dict` to keep those Task objects. The whole async experience is really twisting my mind and interesting at the same time ;-) Regards, Sebastian -- 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/123c14e2-65c6-499e-9a27-b3a256aab099%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Will asgi become a PEP like wsgi is ?
Hi, wsgi is specified by PEP 333 -- Python Web Server Gateway Interface v1.0 https://www.python.org/dev/peps/pep-0333/ Django channels rely on asgi instead. So far ASGI specs appear only here: http://channels.readthedocs.io/en/stable/asgi.html How do these two concepts compare in regards to their respect "importance" to the python community? Especially under the consideration that real-time web applications (i.e. HTML5 websockets) is getting more and more important. Regards, Sebastian -- 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/66c259a2-2dc2-4398-8e7e-daf2cbd551a5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
CsrfViewMiddleware removes other cookies
Hi, I'm working with cutyCapt, and have the problem that referenced images don't get the sessionid cookie. So I fixed CutyCapt, but I also need to remove the CsrfViewMiddleware otherwise my (manually) set sessionid cookie is removed and only the 'csrftoken' is left. If I comment out request.META["CSRF_COOKIE_USED"] = True in csrf.py -> get_token(request) it also works for me. Any help or comments appreciated, Thanks, Sebastian Haase -- 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 http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
ForeignKey field access appears to be lazy evaluated
Hello, I've implemented a tree-like structure in my model. My items have foreign key fields to the respective left and right neighbor. If I'm now trying to move an item one position forward it appears that the assigning of neighbors gets messed up. In my example I have an initial item order like 1 2 3 4 and now i'm trying to move 3 one to the left to get 1 3 2 4 I'm doing this (all inside a commit_on_success transaction) by first removing the moved item, getting 1 2 4 and then (in the same transaction) inserting the moved item to its new position. 1 3 2 4. But it appears that afterwards item 2 thinks that both its left and right neighbors are item 3. I have code like this: item.prevSibling.nextSibling = item.nextSibling # !! (==4) items old prev's next, should be items old next item.nextSibling.prevSibling = item.prevSibling item.prevSibling = newPrevSibling item.nextSibling = newNextSibling # !! (==2) items new next After staring at this for many hours I have to admit that I'm at a loss! - I can only speculate that the involved attribute accesses are delays and assignments of old and new values are gettings mixed up. I tried as first line: item.prevSibling.nextSibling = ItemModel.objects.get(pk=item.nextSibling.pk) But that did not make any difference Any enlightenment would be very welcome. Thanks, Sebastian -- 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 http://groups.google.com/group/django-users. For more options, visit https://groups.google.com/groups/opt_out.
