Django Project idea query

[Khushi Kaushal]

Hello All!
I am participating in GSOC 2021. I was looking at some of the project lists 
and I am interested in the Django Benchmarking project idea. I would like 
to know more about the tasks and operations involved in this project idea. 
I am looking forward to contributing to the Django committee with my work.
Thank you

 

-- 
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/fd72ec40-4cca-447b-a991-03c9e705ecabn%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

[Joachim Jablon]

Just been bitten by that same bug (combination of Sentry, using a 
Queryset.as_manager() that creates an unfiltered queryset as a local 
variable in the stack, a create signal that errored provoking a stacktrace 
that contained the queryset, a table that is always filtered by a field, 
and sorted by another field and an index that behaves poorly without the 
aformentionned filter).

So would a contribution that would avoid evaluating the uncached queryset 
on repr when DEBUG is False likely to be accepted ? If so, I'm ready to get 
my hands dirty :)

Cheers !

Le dimanche 7 mars 2021 à 00:54:56 UTC+1, mic...@turbosys.com.br a écrit :

> I agree with Matt on that. Avoiding executing the queries on production 
> would be helpful!
>
> Let me share my case. I use django-rest-framework in a specific project 
> and DRF has a feature: a serializer has a fancier string representation 
> when printed. I was using a serializer with a queryset in a view that had 
> an exception further, which caused the serializer to be logged and thus, 
> the queryset to be executed.
>
> There are more details in this discussion: 
> https://github.com/encode/django-rest-framework/discussions/7782
>
> The short story is: I was logging this serializer passively and it was 
> causing the execution of a query to a whole table with millions of records, 
> without any sorting optimization, creating hard to debug performance 
> problems.
>
> I understand it is an unusual situation, but repeating Matt's words: 
> Django should be reliable in production for any combination of those 
> conditions. 
>
> Thanks!
>
> On Sunday, October 20, 2019 at 4:47:25 PM UTC-3 Matt wrote:
>
>> Perhaps we ought to just keep the current behavior when DEBUG is True (it 
>> seems so obvious now, I can't believe it wasn't the first thing I 
>> suggested)? Django does lots of helpful things in DEBUG mode at the expense 
>> of performance. I think this would be an innocuous change for most people. 
>>
>> It is not the most important thing to remove behavior that most of users 
>>> use because we want to fix an edge case that was reported twice in the last 
>>> six years.
>>>
>>
>> I don't consider any of those *individual *conditions to trigger the 
>> problem "off the beaten path" for a bigger production Django site. All of 
>> them *combined *is obviously extremely rare, but it will effect someone 
>> else eventually*. *It doesn't sit well with me to not fix the issue. 
>> Django should be reliable in production for any combination of those 
>> conditions.
>>
>> On Wednesday, October 16, 2019 at 12:14:37 AM UTC-7, Mariusz Felisiak 
>> wrote:
>>>
>>> W dniu środa, 16 października 2019 07:53:05 UTC+2 użytkownik Harro 
>>> napisał:

 Yes, it's a complicated issue, but isn't the SQL query the ultimate 
 representation of which methods are called or not?

 Having the query evaluated during debugging has been shown to be 
 harmful in certain situations, isn't that the most important thing to fix?

>>>
>>> Current behavior is extremely valuable IMO. It is not the most important 
>>> thing to remove behavior that most of users use because we want to fix an 
>>> edge case that was reported twice in the last six years. I agree that we 
>>> can clarify this in docs. SQL query is not a solutions because not all of 
>>> ORM users know SQL. Moreover the current `repr()` shows values from DB that 
>>> we'll miss showing only SQL. You can check in the Django documentation how 
>>> users use the current `repr()` e.g. in tutorials.
>>>
>>> Best,
>>> Mariusz
>>>
>>

-- 
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/050a8686-eaa5-47e7-a9ab-d8dd6fd14844n%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

['Adam Johnson' via Django developers (Contributions to Django itself)]

Would James' suggestion of reusing the result cache in __repr__ have solved
your issue? I would like to see that first.

I'm not against the DEBUG-only fetching but there hasn't been any
suggestion what to show instead that could be of use.

One can also mitigate against bad queries particularly well by setting a
statement timeout at the database level (at least MySQL and PostgreSQL
support this), which most users will generally want at a scale where repr()
becomes a problem.

On Tue, 23 Mar 2021 at 12:40, Joachim Jablon  wrote:

> Just been bitten by that same bug (combination of Sentry, using a
> Queryset.as_manager() that creates an unfiltered queryset as a local
> variable in the stack, a create signal that errored provoking a stacktrace
> that contained the queryset, a table that is always filtered by a field,
> and sorted by another field and an index that behaves poorly without the
> aformentionned filter).
>
> So would a contribution that would avoid evaluating the uncached queryset
> on repr when DEBUG is False likely to be accepted ? If so, I'm ready to get
> my hands dirty :)
>
> Cheers !
>
> Le dimanche 7 mars 2021 à 00:54:56 UTC+1, mic...@turbosys.com.br a écrit :
>
>> I agree with Matt on that. Avoiding executing the queries on production
>> would be helpful!
>>
>> Let me share my case. I use django-rest-framework in a specific project
>> and DRF has a feature: a serializer has a fancier string representation
>> when printed. I was using a serializer with a queryset in a view that had
>> an exception further, which caused the serializer to be logged and thus,
>> the queryset to be executed.
>>
>> There are more details in this discussion:
>> https://github.com/encode/django-rest-framework/discussions/7782
>>
>> The short story is: I was logging this serializer passively and it was
>> causing the execution of a query to a whole table with millions of records,
>> without any sorting optimization, creating hard to debug performance
>> problems.
>>
>> I understand it is an unusual situation, but repeating Matt's words:
>> Django should be reliable in production for any combination of those
>> conditions.
>>
>> Thanks!
>>
>> On Sunday, October 20, 2019 at 4:47:25 PM UTC-3 Matt wrote:
>>
>>> Perhaps we ought to just keep the current behavior when DEBUG is True
>>> (it seems so obvious now, I can't believe it wasn't the first thing I
>>> suggested)? Django does lots of helpful things in DEBUG mode at the expense
>>> of performance. I think this would be an innocuous change for most people.
>>>
>>> It is not the most important thing to remove behavior that most of users
 use because we want to fix an edge case that was reported twice in the last
 six years.

>>>
>>> I don't consider any of those *individual *conditions to trigger the
>>> problem "off the beaten path" for a bigger production Django site. All of
>>> them *combined *is obviously extremely rare, but it will effect someone
>>> else eventually*. *It doesn't sit well with me to not fix the issue.
>>> Django should be reliable in production for any combination of those
>>> conditions.
>>>
>>> On Wednesday, October 16, 2019 at 12:14:37 AM UTC-7, Mariusz Felisiak
>>> wrote:

 W dniu środa, 16 października 2019 07:53:05 UTC+2 użytkownik Harro
 napisał:
>
> Yes, it's a complicated issue, but isn't the SQL query the ultimate
> representation of which methods are called or not?
>
> Having the query evaluated during debugging has been shown to be
> harmful in certain situations, isn't that the most important thing to fix?
>

 Current behavior is extremely valuable IMO. It is not the most
 important thing to remove behavior that most of users use because we want
 to fix an edge case that was reported twice in the last six years. I agree
 that we can clarify this in docs. SQL query is not a solutions because not
 all of ORM users know SQL. Moreover the current `repr()` shows values from
 DB that we'll miss showing only SQL. You can check in the Django
 documentation how users use the current `repr()` e.g. in tutorials.

 Best,
 Mariusz

>>> --
> 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/050a8686-eaa5-47e7-a9ab-d8dd6fd14844n%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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-

Moving rest_framework.status into core?

[Carlton Gibson]

Hiya. 

Maybe my search-foo is down but, surprisingly, I couldn't find a discussion 
on this. 

Should we maybe bring the HTTP status code constants that we find in 
rest_framework.status into core, as django.http.status? 

I find myself wanting them (not for the first time) in a project that 
doesn't really depend on DRF, and thinking (surely) these fit comfortably 
in Django's "I'm a web framework" remit. 🤔

Can I solicit opinions on that please? It's just a list of constants so... 
It seems to fit the "bring some of the more reusable bits of DRF into core" 
theme. 

Thanks. 

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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/541cf57b-f369-4dc9-a06e-e3ff8bf4485cn%40googlegroups.com.

Re: Moving rest_framework.status into core?

['Adam Johnson' via Django developers (Contributions to Django itself)]

Python 3.5 added http.HTTPStatus:
https://docs.python.org/3.9/library/http.html#http.HTTPStatus , so I don't
see a need for such constants in Django, unless they add something extra.
Perhaps you could deprecate from DRF.

On Tue, 23 Mar 2021 at 15:18, Carlton Gibson 
wrote:

> Hiya.
>
> Maybe my search-foo is down but, surprisingly, I couldn't find a
> discussion on this.
>
> Should we maybe bring the HTTP status code constants that we find in
> rest_framework.status into core, as django.http.status?
>
> I find myself wanting them (not for the first time) in a project that
> doesn't really depend on DRF, and thinking (surely) these fit comfortably
> in Django's "I'm a web framework" remit. 🤔
>
> Can I solicit opinions on that please? It's just a list of constants so...
> It seems to fit the "bring some of the more reusable bits of DRF into
> core" theme.
>
> Thanks.
>
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/541cf57b-f369-4dc9-a06e-e3ff8bf4485cn%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM0F9Ly_SMLnSvZRsO4%2BY_Zum9r%2BpvM1H4ZAAgF3mb%2BV3Q%40mail.gmail.com.

Re: Moving rest_framework.status into core?

[Arthur Rio]

The one thing that I really prefer from DRF's statuses is their name,
containing the status_code. I used python's `http.HTTPStatus` in a flask
project and I had to have the python docs open
all the time to map between the status code and the name of the status. For
example:
- http.HTTPStatus.BAD_GATEWAY
- rest_framework.status.HTTP_502_BAD_GATEWAY

I don't know if it's enough of an argument to justify maintaining extra
code in Django, but as Carlton said, it's just a file with constants. If
you look at the file in DRF, there haven been very little changes to it
https://github.com/encode/django-rest-framework/commits/master/rest_framework/status.py
and
in my opinion, it does make the developer experience nicer.

Best,

Arthur


On March 23, 2021 at 9:24:32 AM, 'Adam Johnson' via Django developers
(Contributions to Django itself) (django-developers@googlegroups.com) wrote:

Python 3.5 added http.HTTPStatus:
https://docs.python.org/3.9/library/http.html#http.HTTPStatus , so I don't
see a need for such constants in Django, unless they add something extra.
Perhaps you could deprecate from DRF.

On Tue, 23 Mar 2021 at 15:18, Carlton Gibson 
wrote:

> Hiya.
>
> Maybe my search-foo is down but, surprisingly, I couldn't find a
> discussion on this.
>
> Should we maybe bring the HTTP status code constants that we find in
> rest_framework.status into core, as django.http.status?
>
> I find myself wanting them (not for the first time) in a project that
> doesn't really depend on DRF, and thinking (surely) these fit comfortably
> in Django's "I'm a web framework" remit. 🤔
>
> Can I solicit opinions on that please? It's just a list of constants so...
> It seems to fit the "bring some of the more reusable bits of DRF into
> core" theme.
>
> Thanks.
>
> 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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/541cf57b-f369-4dc9-a06e-e3ff8bf4485cn%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM0F9Ly_SMLnSvZRsO4%2BY_Zum9r%2BpvM1H4ZAAgF3mb%2BV3Q%40mail.gmail.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/CADOBPEEfe_5bhizzaE74fmvcwpmYC5NOb5NA2yVqt_n%2BrDE5mA%40mail.gmail.com.

testcases

[sangeerth sathiskumar]

Hi guys im struggling with testcases. 
Can you help me with testcase to this implementation ? 


from django.db import models
from django.contrib.auth.models import AbstractBaseUser, BaseUserManager

# Create your models here.
class AccountManager(BaseUserManager):
def create_user(self, email, first_name, last_name, password=None):
if not email:
raise ValueError('Email address is required')
if not first_name:
raise ValueError('First name is required')
if not last_name:
raise ValueError('Last name is required')

user = self.model(first_name=first_name, last_name=last_name, email=self
.normalize_email(email))
user.set_password(password)
user.save(using=self._db)
return user

def create_superuser(self, email, first_name, last_name, password):
user = self.create_user(
email=self.normalize_email(email),
first_name=first_name,
last_name=last_name,
password=password
)
user.is_admin = True
user.is_staff = True
user.is_superuser = True
user.save(using=self._db)
return user


class Account(AbstractBaseUser):
first_name = models.CharField(max_length=30)
last_name = models.CharField(max_length=30)
email = models.EmailField(verbose_name='email', max_length=60, unique=True)
date_joined = models.DateTimeField(verbose_name='date joined', auto_now_add=
True)
last_login = models.DateTimeField(verbose_name='last login', auto_now=True)
is_admin = models.BooleanField(default=False)
is_active = models.BooleanField(default=True)
is_staff = models.BooleanField(default=False)
is_superuser = models.BooleanField(default=False)

USERNAME_FIELD = 'email'
REQUIRED_FIELDS = ['first_name', 'last_name']

objects = AccountManager()

def __str__(self):
return self.email

def has_perm(self, perm, obj=None):
return self.is_admin

def has_module_perms(self, app_label):
return True

-- 
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/118d29b7-2585-45f0-8ce2-6d2b0f30130en%40googlegroups.com.

Re: testcases

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/3.1/faq/help/ . This will help you find
people who are willing to support you, and to ask your question in a way
that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Tue, 23 Mar 2021 at 17:01, sangeerth sathiskumar 
wrote:

>
> Hi guys im struggling with testcases.
> Can you help me with testcase to this implementation ?
>
>
> from django.db import models
> from django.contrib.auth.models import AbstractBaseUser, BaseUserManager
>
> # Create your models here.
> class AccountManager(BaseUserManager):
> def create_user(self, email, first_name, last_name, password=None):
> if not email:
> raise ValueError('Email address is required')
> if not first_name:
> raise ValueError('First name is required')
> if not last_name:
> raise ValueError('Last name is required')
>
> user = self.model(first_name=first_name, last_name=last_name, email=self
> .normalize_email(email))
> user.set_password(password)
> user.save(using=self._db)
> return user
>
> def create_superuser(self, email, first_name, last_name, password):
> user = self.create_user(
> email=self.normalize_email(email),
> first_name=first_name,
> last_name=last_name,
> password=password
> )
> user.is_admin = True
> user.is_staff = True
> user.is_superuser = True
> user.save(using=self._db)
> return user
>
>
> class Account(AbstractBaseUser):
> first_name = models.CharField(max_length=30)
> last_name = models.CharField(max_length=30)
> email = models.EmailField(verbose_name='email', max_length=60, unique=True
> )
> date_joined = models.DateTimeField(verbose_name='date joined',
> auto_now_add=True)
> last_login = models.DateTimeField(verbose_name='last login', auto_now=True
> )
> is_admin = models.BooleanField(default=False)
> is_active = models.BooleanField(default=True)
> is_staff = models.BooleanField(default=False)
> is_superuser = models.BooleanField(default=False)
>
> USERNAME_FIELD = 'email'
> REQUIRED_FIELDS = ['first_name', 'last_name']
>
> objects = AccountManager()
>
> def __str__(self):
> return self.email
>
> def has_perm(self, perm, obj=None):
> return self.is_admin
>
> def has_module_perms(self, app_label):
> return True
>
> --
> 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/118d29b7-2585-45f0-8ce2-6d2b0f30130en%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM2pB6D8f7KmL8QW0V%2BuwSx0bGP0Q-Ho%3DKtUW%3D%2B291WPNQ%40mail.gmail.com.