Re: Stop QuerySet repr from executing queries

[Mariusz Felisiak]

Hi y'all,

I closed the original ticket because two responses is not enough to 
reopen it. I'm -1 to this change. IMO your issue is really niche and it's 
caused by multiple reasons, i.e. huge table, Meta.ordering by non-indexed 
column, uncaught exception, error reporting layer that calls `repr()` etc. 
and to be honest even with all of this fetching the first 20 rows should 
not crash your production database (I worked with tables that had hundreds 
of millions of records). I'm against this change because it will have a 
negative impact for most of users (like pointed by Luke[1]). It will also 
have a big impact on our documentation ~ 200 examples to change.

Best,
Mariusz

[1] https://code.djangoproject.com/ticket/20393#comment:5

-- 
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/c459aec4-23f1-475f-9b9f-0acb2c83b54c%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

[Carlton Gibson]

I'd be -1 on the change here too. 

That QuerySet shows you its value in the shell is beyond valuable. 

Look at the Django Tutorial 
, 
or the Django Girl Tutorial 
, or any of the other 
learning examples, and imagine making it so that these *playing with the 
API* examples required grasping *at which point QuerySets are evaluated*. 
Users don't get that quickly. (These exact issues come up all the time on 
DRF — Why isn't my QuerySet updating? Because you evaluated it in your 
class definition...) 

If you must have a different behaviour here, use a subclass.

Kind Regards,

Carlton


On Tuesday, 15 October 2019 10:21:14 UTC+2, Mariusz Felisiak wrote:
>
> I'm -1 to this change. ... to be honest even with all of this fetching the 
> first 20 rows should not crash your production database... I'm against this 
> change because it will have a negative impact for most of users ...It will 
> also have a big impact on our documentation ~ 200 examples to change.
>

-- 
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/e6c631ea-d0b0-4d39-a784-2169f1445952%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

['Alexandr Aktsipetrov' via Django developers (Contributions to Django itself)]

Current behavior is indeed usually useful but I actually remember being 
annoyed by it during interactive debugging - as watches affect sql log.  

What about reusing DEBUG instead of introducing brand new setting? I 
imagine all tutorials are in the context of scaffolded project with 
DEBUG=True as a default?

-- 
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/c59553a3-74f0-430a-8924-7ae0d238b73d%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

[James Bennett]

This request is a bit more complicated than I think people
realize. There's no practical way I can see to have the __repr__() of
a QuerySet supply information sufficient to reconstruct it, at least
not in a manner recognizable to most users of the ORM (there's no
internal record of which query methods were called, or with which
arguments -- only the manipulations of the nodes of the underlying
Query object).

And even if we decided to go to the trouble of having QuerySet store a
record of query method calls, it's likely to be a considerable amount
of trouble, since arguments to query methods may be objects that are
difficult or impossible to safely store (such as iterators which would
be consumed in creating a string representation).

So having QuerySet.__repr__() produce the sort of "information to
reconstruct the object" typical of the __repr__() of Python's builtins
is not going to work.

Which leaves the question of what to put in the __repr__(), if it's
not going to be a way to reconstruct the QuerySet and it's not going
to be the results of the query. We would also need to ensure QuerySet
implements __str__() in a way that *does* provide the visual debugging
aid of showing the results, since currently it doesn't, and relies on
Python falling back to __repr__() to get the string representation.

And... I don't have a good answer to this. Anything that isn't either
the method chain to reconstruct the query, or the results of the
query, is not going to be a sufficient debugging aid.

Which brings us back around to the current behavior; it seems to me
that this is the most useful thing we can do. It's already documented
that a string representation of a QuerySet shows the results, which
requires evaluating it and performing the query. There are some small
optimizations we could do -- such as checking for a populated result
cache and using it, rather than re-performing the query as __repr__()
currently does -- and we could be more explicit about the fact that
performing the query is a requirement for generating a string
representation, but I think that's about the best we can do for this
issue.

-- 
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/CAL13Cg8H0ja0J72vCkP7MFpoN5DsxefLiUu%3D%3DkHaV1FhgBaM5Q%40mail.gmail.com.

How can I join to django translations on transifex

[Soyuzbek orozbek uulu]

Hi all,
I want to translate Django to Kyrghyz language using transifex. I already 
sent a request but I didn't get any response. Can you help me with it?

-- 
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/80fed540-5a77-4216-9364-4dd722c15eec%40googlegroups.com.

Re: Stop QuerySet repr from executing queries

[charettes]

I agree with what James eloquently said, the issue is more complicated it 
appears.

Simon

Le mardi 15 octobre 2019 05:59:27 UTC-4, James Bennett a écrit :
>
> This request is a bit more complicated than I think people
> realize. There's no practical way I can see to have the __repr__() of
> a QuerySet supply information sufficient to reconstruct it, at least
> not in a manner recognizable to most users of the ORM (there's no
> internal record of which query methods were called, or with which
> arguments -- only the manipulations of the nodes of the underlying
> Query object).
>
> And even if we decided to go to the trouble of having QuerySet store a
> record of query method calls, it's likely to be a considerable amount
> of trouble, since arguments to query methods may be objects that are
> difficult or impossible to safely store (such as iterators which would
> be consumed in creating a string representation).
>
> So having QuerySet.__repr__() produce the sort of "information to
> reconstruct the object" typical of the __repr__() of Python's builtins
> is not going to work.
>
> Which leaves the question of what to put in the __repr__(), if it's
> not going to be a way to reconstruct the QuerySet and it's not going
> to be the results of the query. We would also need to ensure QuerySet
> implements __str__() in a way that *does* provide the visual debugging
> aid of showing the results, since currently it doesn't, and relies on
> Python falling back to __repr__() to get the string representation.
>
> And... I don't have a good answer to this. Anything that isn't either
> the method chain to reconstruct the query, or the results of the
> query, is not going to be a sufficient debugging aid.
>
> Which brings us back around to the current behavior; it seems to me
> that this is the most useful thing we can do. It's already documented
> that a string representation of a QuerySet shows the results, which
> requires evaluating it and performing the query. There are some small
> optimizations we could do -- such as checking for a populated result
> cache and using it, rather than re-performing the query as __repr__()
> currently does -- and we could be more explicit about the fact that
> performing the query is a requirement for generating a string
> representation, but I think that's about the best we can do for this
> issue.
>

-- 
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/f0e3d894-1f00-45b0-8615-ffd211f51bcd%40googlegroups.com.

Re: How can I join to django translations on transifex

[Claude Paroz]

Hi,

There is a specific group dedicated to translation issues: 
django-i...@googlegroups.com
Please write to that group.

Claude

Le mardi 15 octobre 2019 13:40:38 UTC+2, Soyuzbek orozbek uulu a écrit :
>
> Hi all,
> I want to translate Django to Kyrghyz language using transifex. I already 
> sent a request but I didn't get any response. Can you help me with it?
>

-- 
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/9591f216-df5a-4646-9453-58fb53824cdf%40googlegroups.com.

Re: How can I join to django translations on transifex

[Soyuzbek orozbek uulu]

Thank you for your response Claude. I just wrote to that group and I am
waiting for their response,
Soyuzbek

On Tue, Oct 15, 2019 at 9:09 PM Claude Paroz  wrote:

> Hi,
>
> There is a specific group dedicated to translation issues:
> django-i...@googlegroups.com
> Please write to that group.
>
> Claude
>
> Le mardi 15 octobre 2019 13:40:38 UTC+2, Soyuzbek orozbek uulu a écrit :
>>
>> Hi all,
>> I want to translate Django to Kyrghyz language using transifex. I already
>> sent a request but I didn't get any response. Can you help me with it?
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/b0nPtJ9GM5M/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/9591f216-df5a-4646-9453-58fb53824cdf%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/CAEv2oQX_h1eBBOskBCdTybXyqjsysixNYNEA%3DNPz1v-5UYAcow%40mail.gmail.com.

Re: Stop QuerySet repr from executing queries

[Harro]

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?

-- 
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/282c78ce-bcbe-4b74-ad8a-5d49cd2662e9%40googlegroups.com.