Re: select_for_update and transactions (bad dev UX in a feature)
On Sat, 20 Nov 2021 at 14:21, Florian Apolloner wrote: > I even have a possible fix for that, but it requires us to rewrite > middlewares again :/ > This is the third time this has come up (the middleware rewrite I mean) Rule of Threes. We need a DjangoCon, so we can draft a DEP. :) > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJwKpyTvkZ5NYLZq8H6kJRVGEtjpqs8u%2BnWqQV97ZG%2Bme8aqmg%40mail.gmail.com.
How to get started with contribution
Respected Sir/madam, I am Asma Butt, a computer science undergrad,I have just entered my third year at BSCS (UET).I am new to open source contributions but I am well aware of python and currently learning django framework.I would love to contribute to your organization but could you please tell me how to get started? Hoping to hear from you soon. Regards Asma -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3d738bcf-81ca-4e44-9ef4-e5b1a37e02b0n%40googlegroups.com.
How to get started with contribution.
Respected Sir/Madam, My name is Vinayak Ravi Saxena, a computer science undergraduate, I have just entered my final year at Lovely Professional University. I am a newbie at open source and looking forward to starting my open-source journey with your organization. I am proficient in C++, Python, HTML, CSS, Bootstrap, JavaScript, React, Django, Flask, and Flutter and have good knowledge about MongoDB, SQL, Node.js. Could you please help me in getting started? Hoping to hear from you soon. Regards, Vinayak -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7be328e3-7632-489f-b25a-bad026ebb951n%40googlegroups.com.
Question: Regarding Page class
Hi, While working with pagination I have observed that after splitting a queryset into pages. Each page that is initially of type queryset is converted to list before returning. Is there any reason why it's converted to list? I see that we can still get a queryset by slicing it which we could do so in Page class. If it is a queryset and not a list, we can add more columns or do some more computation on the queryset of a page even before evaluating. Right now as it is a list the queryset is already evaluated and we need to do one more query to add some columns to the page. Let me know if I am wrong or there are any reasons to use list instead of a queryset for a page. Thanks, Revanth -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b0eb3ad8-4303-4517-aebc-05a9385d295dn%40googlegroups.com.
Re: select_for_update and transactions (bad dev UX in a feature)
Hi Aymeric, On Saturday, November 20, 2021 at 12:39:17 PM UTC+1 Aymeric Augustin wrote: > I'm not trying to disagree for the sake of disagreement; I'm just trying > to bring some contextual awareness and avoid the "core devs say > ATOMIC_REQUESTS is bad" effect. I hope we can agree on this? > Absolutely, my comment was mostly there to show that not all core devs agree that ATOMIC_REQUESTS is something that should be always enabled. As usual it depends on your project, database etc… I should have added more context to that, thanks for pointing it out. > Finally — yes, I know that my implementation of this feature is a wormhole > across layers. I won't even try to justify it. I wish we had something > better but we haven't found that yet. > I still think it is good (in the sense that we worked with what we had available). Sure the layering isn't exactly nice, but we have worse things in Django's codebase :) I even have a possible fix for that, but it requires us to rewrite middlewares again :/ Cheers, Florian -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/6d65a33b-32ad-46a0-9b75-9c7f96c1fe03n%40googlegroups.com.
Re: select_for_update and transactions (bad dev UX in a feature)
Hello, > On 18 Nov 2021, at 11:11, Florian Apolloner wrote: > > FWIWI I always recommend disabling ATOMIC_REQUESTS and using transactions as > needed :) Investing engineers' time into evaluating the exact transactional integrity requirements of every view may be appropriate in some contexts. Getting a blanket safeguard from ATOMIC_REQUESTS can be a fair tradeoff in other contexts. Engineer time is expensive. PostgreSQL horsepower can be pretty cheap on low or even medium traffic websites, which are a substantial part of Django's target audience. On these websites, it can be entirely reasonable to pay a limited cost for ATOMIC_REQUESTS and to get the benefit that every view succeeds completely or fails completely. Also you don't depend on engineers getting the analysis right every time, including when they make a change — the situation that triggered this discussion in the first place. > Honestly long transactions are imo bad, one should evaluate what the view > needs and then act accordingly. Since most views on most websites are short, it isn't completely bonkers to use a blacklist approach, that is, to review the situation closely on long views and apply non_atomic_requests appropriately. I'm not trying to disagree for the sake of disagreement; I'm just trying to bring some contextual awareness and avoid the "core devs say ATOMIC_REQUESTS is bad" effect. I hope we can agree on this? Finally — yes, I know that my implementation of this feature is a wormhole across layers. I won't even try to justify it. I wish we had something better but we haven't found that yet. -- Aymeric. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/16779272-37F9-4BB6-A5F7-4CE5B226E2A9%40polytechnique.org.
