Re: GSOC Proposal: Adding Redis Cache Backend To Django Core.

[Girish Sontakke]

Hello,
If I am not wrong, you are talking about the cache incoherence 
 problem.  Currently, I 
don't have any concrete idea to tackle this problem but I will try to 
figure it out.
Thanks for bringing this to concern.

Kind Regards,
Girish

On Thursday, April 1, 2021 at 8:39:59 PM UTC+5:30 dans...@gmail.com wrote:

> Since REDIS is already usable as a cache for Django using 3rd party code, 
> I would rather see a circuit breaker pattern applied to the cache, across 
> all backends.  I'm not that active in maintaining Django right now, but a 
> cache may not be fully redundant, and it also can fail. If the cache is 
> truly used as a cache, then it should be possible to try the cache, and if 
> it fails for several tries, then Django could start to bypass it, and then 
> try to re-enable it later.
>
> This is perhaps a bigger effort than a GSOC project - the hard part is 
> doing this across multiple processes and threads.  What does it mean if the 
> cache is only available for some fraction of the instances/processes 
> hosting a project?
>
>
> On Thu, Apr 1, 2021 at 8:25 AM Girish Sontakke  
> wrote:
>
>> Hello Carlton,
>> As suggested by you I made some revisions to my proposal. Still, it is 
>> not a perfect one, I am trying to improve it. Thanks a lot for the help.
>>
>> Kind Regards,
>> Girish
>> On Thursday, April 1, 2021 at 12:15:53 AM UTC+5:30 carlton...@gmail.com 
>> wrote:
>>
>>>
>>>
>>> On 31 Mar 2021, at 11:00, Girish Sontakke  wrote:
>>>
>>> Now I have doubt that whether I should remove *Provides Many 
>>> Data-Structures *point from the "Why Redis" section or keep it there?.
>>>
>>>
>>> I don’t think it’s vital either way… but it seems a distraction. That 
>>> Redis has HyperLogLog isn’t something that will matter at all to the cache 
>>> backend. 
>>>
>>> I’d try to focus on the details of the implementation: Look at the 
>>> backend API, set(), get() &co. Look at the two existing third-party 
>>> backend, and see what they do there. 
>>>
>>> I’d also think about getting the documentation right — there are a few 
>>> options with installs and connections and … — you don’t have to solve all 
>>> of those in the proposal but showing that you’re aware of them would be 
>>> good.
>>>
>>> I hope that helps. 
>>>
>>> Kind Regards,
>>>
>>> Carlton
>>>
>>> -- 
>> 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-develop...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/97c757dd-b09f-49f4-9e3f-0ee4a8e4887cn%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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/399dbcd7-7127-4715-b2cd-3f5d349d605bn%40googlegroups.com.

Re: Django Benchmark query

[Carlton Gibson]

Hi Khushi. 

Did you see the "Writing new benchmarks" section of the README[0]?. 
It's suggests the query_delete benchmark[1] as a good one to follow.  

If you're following David's recent work using ASV, you'll need to read 
through the issue[2], 
and look at the repo for that[3], as well as exploring the linked material 
from there.  

[0]: https://github.com/django/djangobench#writing-new-benchmarks
[1]: 
https://github.com/django/djangobench/tree/master/djangobench/benchmarks/query_delete
[2]: https://github.com/django/djangobench/issues/38
[3]: https://github.com/smithdc1/django-asv/

Kind Regards,

Carlton


On Thursday, 1 April 2021 at 18:30:58 UTC+2 khushik...@gmail.com wrote:

> Hello Everyone!
> I just wanted to ask how to set up a new benchmark in the Django 
> benchmarking project.
> I am stuck at this point and wanted to ask how to move ahead. I would 
> appreciate some good advice.
> Yours Sincerely 
> Khushi
>

-- 
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/45b43ef2-37e4-4d2c-a2d3-2de0d309bf93n%40googlegroups.com.

Re: Request for Comment: settings growth configuring Email Backend.

[Tim Graham]

I don't think there's a big cost to additional entries in 
docs/ref/setttings.txt. I think it's far more common to browse that 
document for needed functionality rather than to read the entire thing. 
There are 23 DATABASES 'TEST' settings that probably aren't used very 
frequently, yet I don't think it would be an improvement to remove all 
those and instead instruct users to subclass the database backend instead. 
In any case, the documentation has to be somewhere. If it's not a setting, 
then readers have to discover that functionality elsewhere. If we introduce 
some distinction between "commonly used options" and "less commonly used 
options", that creates extra work to figure out whether the option is 
considered "common" (setting) or "uncommon" (subclass). And further, some 
users may look no further than the settings page and never even discover 
the uncommon options.

If some functionality is so obscure that it doesn't merit a setting, 
perhaps it doesn't need to be in Django. If it's merely the number of 
settings that irk you, perhaps something like EMAIL_SSL_CONTEXT = 
{'cafile': ..., 'capath': ..., 'cadata': ...} would ameliorate your 
concerns in this case.
On Thursday, April 1, 2021 at 4:40:00 AM UTC-4 carlton...@gmail.com wrote:

> Hey Tim, 
>
> Thanks for following up here. 
>
> Thanks also for the link to the previous discussion, very interesting. 
>
> So, looking at that, this was first discussed 7 years ago, when there were 
> (just) 
> 6 email related settings. 
>
> I liked Jannis' initial reaction at the time: "Oh god, YES!!"
>
> It didn't get accepted in the end for arguments along the lines of 
> "Just for purity" and "No cost to adding an additional setting". 
>
> All this time later though, I would argue that those judgements, whilst 
> reasonable at the time, underplayed the costs. 
>
> We currently have 11 `EMAIL_` settings in `global_settings.py`[0]. 
>
> The suggested PR here[1] would add three more. And there's another PR[1] 
> open 
> suggesting adding yet another.  
>
> That would make 15 `EMAIL_` prefixed settings. 
>
> I would suggest that's too much. That it's time we changed tack. 
>
>
>
> The issue for me is that we're failing to insulate our users from a whole 
> swathe of unnecessary complexity that they shouldn't have to deal with. 
>
> As it is every reader of `settings.txt` has to go through each of these
> `EMAIL_` settings, parse them, and answer the questions _Does this apply 
> to me?
> And how?_. Instead of encapsulating the details of the SMTP, and now 
> SSLContext
> modules, we've added a set of pass-through parameters which force users to
> address them. 
>
> Particularly for the proposed SSLContext parameters, most user will never 
> need
> them — they'll just want the default `None` to use the default system CA 
> certs.
> So, we're adding to the cognitive load of all users, to address a use case
> affecting only a small subgroup. 
>
> I don't see/accept/agree with the "boilerplate" point. I need to create a 
> subclass yes: 
>
>
> ```
> from django.core.mail.backends.smtp import EmailBackend as SMTPBackend
>
>
> class EmailBackend(SMTPBackend):
> def __init__(self, *args, **kwargs):
> # Set Environment kwargs here.
> ```
>
> So it's an import and two lines for the class and init definitions. 
>
> The trade-off for that is insulating the plurality of users for whom these 
> advanced configuration options just simply aren't relevant. 
>
> The pay-off is that, by moving some of the more esoteric options out of 
> settings, we make Django's settings easier to navigate and comprehend for 
> every 
> body.
>
> It's like a form or the Sorites Paradox[3]: it turns out that in project 
> with the
> lifespan of Django, the seemingly harmless, "There's little cost to adding 
> one
> more setting" fails the induction rule. 
>
> FWIW: I think this same issue applies to the HTTP security headers thread,
> which we're still thinking about. We should encapsulate these with sane
> defaults, in a module that users can go and investigate, customise and 
> apply,
> with a single setting, rather than added an every longer list, which forces
> every user to face decisions that we should have made for them, for 
> ourselves.
>
> So that's my concern. 
>
> To address yours, I certainly don't think configuration details should be 
> "scattered". 
>
> I'd recommend a `project.conf.email` module (or package if needs be) 
> containing
> all the email related details. Keeping it all together makes it easier to
> maintain. (It's locality of behaviour: Where's email stuff? It's all in 
> there.)
>
> I'd then have a `EmailBackend` subclass per environment and set it with 
> the 
> `EMAIL_BACKEND` setting. (Folks can use environment variables and all the 
> rest 
> of it as they see fit here, much as they do now.)
>
> I think most users are using SMTP, and they **all** need to set
> host/username/password, so those settings should likely remain.
>
> The email section in `s