Re: Worth raising a warning when `order_by('?')` is used with specific backends?
š ok, great. They're both good points. As to Adam's point about missing
warnings: it is true, they can be missed, but there are ways to enforce
them (python -W error, or PYTHONWARNINGS=error).
On Fri, Jan 10, 2020 at 12:41 PM Tim Graham wrote:
> I think issuing a warning would be rude to developers who want to use that
> feature and are aware of the limitation... they would have to do extra work
> to silence the warning.
>
> On Friday, January 10, 2020 at 10:14:23 AM UTC-5, Santiago Basulto wrote:
>>
>> Sadly I have to admit that I'm not involved with day to day development
>> of our app anymore (I miss it tremendously). Yesterday I felt nostalgic and
>> reviewed a few already-merged PRs, just "for fun" we could say. Great was
>> my surprise when I noticed that one of those PRs was merged with an
>> `order_by('?')`. We're (and we've always been) using Postgres, and I knew
>> already that `ORDER BY RANDOM()` is very slow. I just submitted a comment
>> and it's already been fixed, so it wasn't a big deal. But this got me
>> thinking:
>>
>> TLDR;
>> Some less-experienced developers might not know the issues with
>> `order_by('?')` (at least with Postgres, the only engine I'm familiar
>> enough) and it's worth raising a warning. I don't know what's the state of
>> other engines, it's maybe even worth raising the issue for ANY engine.
>>
>> It could help newcomers catch these issues early. The docs clearly state
>> it
>> <https://docs.djangoproject.com/en/3.0/ref/models/querysets/#django.db.models.query.QuerySet.order_by>,
>> but not everybody reads the docs with such level of detail:
>>
>> Note: order_by('?') queries may be expensive and slow, depending on the
>>> database backend youāre using
>>
>>
>> PS: Sorry for the personal touch of this message, but I think it's worth
>> the explanation.
>>
> --
> 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/WdkpBmN6XRc/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/d11f0f8c-a73f-4e95-9b69-25d3195effb8%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/d11f0f8c-a73f-4e95-9b69-25d3195effb8%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
Santiago Basulto.-
Up!
--
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/CAPmap1eMp8k%2B9nJvdr0bDz%2BwYeWCQFiNde-dgvMY7WBoS9P-xQ%40mail.gmail.com.
Worth raising a warning when `order_by('?')` is used with specific backends?
Sadly I have to admit that I'm not involved with day to day development of
our app anymore (I miss it tremendously). Yesterday I felt nostalgic and
reviewed a few already-merged PRs, just "for fun" we could say. Great was
my surprise when I noticed that one of those PRs was merged with an
`order_by('?')`. We're (and we've always been) using Postgres, and I knew
already that `ORDER BY RANDOM()` is very slow. I just submitted a comment
and it's already been fixed, so it wasn't a big deal. But this got me
thinking:
TLDR;
Some less-experienced developers might not know the issues with
`order_by('?')` (at least with Postgres, the only engine I'm familiar
enough) and it's worth raising a warning. I don't know what's the state of
other engines, it's maybe even worth raising the issue for ANY engine.
It could help newcomers catch these issues early. The docs clearly state it
,
but not everybody reads the docs with such level of detail:
Note: order_by('?') queries may be expensive and slow, depending on the
> database backend youāre using
PS: Sorry for the personal touch of this message, but I think it's worth
the explanation.
--
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/fe948733-7767-4688-b89a-43fa57153905%40googlegroups.com.
Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable
Haha, sorry, got overly excited. What's the usual process to make these sort of decisions in these cases? Should we ask the users list? The setting proposal is purely from my perspective as a user. For *my* (completely unilateral) point of view, this is very important and I'd love to have a place to just flip a switch and change them all; well, I'd even prefer for it to be the default behavior, but I know selects look cool too. Now, from a "development" perspective, I do understand that it might be a big change. On Saturday, January 19, 2019 at 4:57:21 AM UTC-3, Carlton Gibson wrote: > > > > On 18 Jan 2019, at 17:20, Santiago Basulto > wrote: > > Seems like everybody agrees that for large sites, it's necessary. > > > Hang on, slow down. š > > Personally, Iām not sure itās too onerous as-is. Iāve not yet seen exactly > why subclassing ModelAdmin in oneās project isnāt good enough. It really > depends on with the āitā is āitās necessaryā is taken to meanā¦ > > - Better examples in docs: Great, no problem. > - **More** API on ModelAdmin: OK, maybe, but what does that look like > exactly? > - A setting: Really? Do we have to? Can we explore other options first? > > Both the docs and adjustments to ModelAdmin options could be pushed > forward with a PR. āBetter handling of FK widgets for fields with large > countsā ā sounds great, but what does that involve? > > 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/e18c8811-35ae-4607-b9bb-7bb826e8389c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable
@Harro, it does work if the field is not part of the admin. It doesn't add
the way to link it directly, but it does resolve the problem of prefetching
a list and building the large select field. Here's an quick
example: https://i.imgur.com/uNRPCK6.png (the Country field is a FK and
doesn't have an admin class).
Seems like everybody agrees that for large sites, it's necessary. We've all
been bitten by it. I could post to the Users email list to receive some
feedback.
On Friday, January 18, 2019 at 7:25:43 AM UTC-5, Harro wrote:
>
> The problem is that you can't just use it everywhere, like mentioned
> earlier it only works if the other side of the relation is also available
> in the admin (which might not be the case, or only for some of the fields.)
>
> I would say add it to the good old djangosnippets
> <https://djangosnippets.org/> website.
>
> But that's just my 2 cents.
>
> On Friday, 18 January 2019 12:50:52 UTC+1, Josh Smeaton wrote:
>>
>> If we were happy with that particular implementation, then I'd prefer
>> adding it as an official subclass thats importable for users rather than
>> just dumping the code to the docs. But I guess the issue is a slippery
>> slope - how many subclasses do we add for various ModelAdmin use cases.
>> It's definitely an issue that bites many people, and I'd like to see some
>> way forward.
>>
>> On Friday, 18 January 2019 03:52:52 UTC+11, Santiago Basulto wrote:
>>>
>>> Ok, sorry for the Fake News, seems like it's not so complicated to make
>>> one ModelAdmin parent class that provides this behavior. Here's a working
>>> example:
>>>
>>>
>>> from django.contrib import admin
>>>
>>> from django.contrib.admin import widgets
>>>
>>>
>>> class RawFieldModelAdmin(admin.ModelAdmin):
>>> def formfield_for_foreignkey(self, db_field, request, **kwargs):
>>> db = kwargs.get('using')
>>> if 'widget' not in kwargs:
>>> if db_field.name not in (self.get_autocomplete_fields(
>>> request), self.radio_fields):
>>> kwargs['widget'] = widgets.ForeignKeyRawIdWidget(
>>> db_field.remote_field, self.admin_site, using=db)
>>>
>>>
>>> return super().formfield_for_foreignkey(db_field, request, **
>>> kwargs)
>>>
>>> Do you folks think we should add this to the docs? I still think that
>>> having a one-off setting for the "default foreign key" widget would be
>>> valuable, at least for me as a user.
>>>
>>> What do you think?
>>>
>>> On Thursday, January 17, 2019 at 11:27:12 AM UTC-5, Santiago Basulto
>>> wrote:
>>>>
>>>> I think the proposed solution of "you can just extend/subclass
>>>> ModelAdmin" doesn't work, because the fields on different models can have
>>>> different names. I can't just write one global ModelAdmin and then use it
>>>> for all my models, because they'll have different names for their fields.
>>>> Or if it works, it'll need A LOT of introspection (to dynamically check
>>>> which fields are FKs and making them part of raw_id_fields).
>>>>
>>>> Maybe I'm wrong and I'm missing the point, do you folks have an
>>>> implementation of that ModelAdmin superclass to show?
>>>>
>>>> On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>>>>>>
>>>>>> One problem with any of the alternatives (besides making it readonly
>>>>>> by default) is that it requires the other model to be registered in the
>>>>>> admin
>>>>>>
>>>>>
>>>>> Off-hand I don't follow you here. Can you explain.
>>>>>
>>>>>
>>>>>
>>>>>> I hope there's _something_ we can do to somehow improve the
>>>>>> situation. Maybe we could at least improve the examples in the
>>>>>> documentation? Maybe give an example in the docs of a ModelAdmin
>>>>>> subclass
>>>>>> that defaults to using raw_id?
>>>>>>
>>>>>
>>>>> An example definitely.
>>>>>
>>>>> Maybe we could add an attribute to ModelAdmin with a number: More than
>>>>> this use raw_id ā but what would that look like?
>>>>> (Easy subclass rather than a setting...)
>>>>>
>>>>
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/63293e84-aa00-41e3-87ee-8272a5c17478%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable
Ok, sorry for the Fake News, seems like it's not so complicated to make one
ModelAdmin parent class that provides this behavior. Here's a working
example:
from django.contrib import admin
from django.contrib.admin import widgets
class RawFieldModelAdmin(admin.ModelAdmin):
def formfield_for_foreignkey(self, db_field, request, **kwargs):
db = kwargs.get('using')
if 'widget' not in kwargs:
if db_field.name not in (self.get_autocomplete_fields(request),
self.radio_fields):
kwargs['widget'] = widgets.ForeignKeyRawIdWidget(db_field.
remote_field, self.admin_site, using=db)
return super().formfield_for_foreignkey(db_field, request, **kwargs)
Do you folks think we should add this to the docs? I still think that
having a one-off setting for the "default foreign key" widget would be
valuable, at least for me as a user.
What do you think?
On Thursday, January 17, 2019 at 11:27:12 AM UTC-5, Santiago Basulto wrote:
>
> I think the proposed solution of "you can just extend/subclass ModelAdmin"
> doesn't work, because the fields on different models can have different
> names. I can't just write one global ModelAdmin and then use it for all my
> models, because they'll have different names for their fields. Or if it
> works, it'll need A LOT of introspection (to dynamically check which fields
> are FKs and making them part of raw_id_fields).
>
> Maybe I'm wrong and I'm missing the point, do you folks have an
> implementation of that ModelAdmin superclass to show?
>
> On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson wrote:
>>
>>
>>
>> On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>>>
>>> One problem with any of the alternatives (besides making it readonly by
>>> default) is that it requires the other model to be registered in the admin
>>>
>>
>> Off-hand I don't follow you here. Can you explain.
>>
>>
>>
>>> I hope there's _something_ we can do to somehow improve the situation.
>>> Maybe we could at least improve the examples in the documentation? Maybe
>>> give an example in the docs of a ModelAdmin subclass that defaults to using
>>> raw_id?
>>>
>>
>> An example definitely.
>>
>> Maybe we could add an attribute to ModelAdmin with a number: More than
>> this use raw_id ā but what would that look like?
>> (Easy subclass rather than a setting...)
>>
>
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/4144aaca-34b8-4960-8f70-7a37f745c970%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable
I think the proposed solution of "you can just extend/subclass ModelAdmin" doesn't work, because the fields on different models can have different names. I can't just write one global ModelAdmin and then use it for all my models, because they'll have different names for their fields. Or if it works, it'll need A LOT of introspection (to dynamically check which fields are FKs and making them part of raw_id_fields). Maybe I'm wrong and I'm missing the point, do you folks have an implementation of that ModelAdmin superclass to show? On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson wrote: > > > > On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote: >> >> One problem with any of the alternatives (besides making it readonly by >> default) is that it requires the other model to be registered in the admin >> > > Off-hand I don't follow you here. Can you explain. > > > >> I hope there's _something_ we can do to somehow improve the situation. >> Maybe we could at least improve the examples in the documentation? Maybe >> give an example in the docs of a ModelAdmin subclass that defaults to using >> raw_id? >> > > An example definitely. > > Maybe we could add an attribute to ModelAdmin with a number: More than > this use raw_id ā but what would that look like? > (Easy subclass rather than a setting...) > -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c6df6501-dd30-4087-b344-129582bff824%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable
Btw, for reference, not the only one with this problem:
* https://twitter.com/mbrochh/status/1049209871583797248
* https://twitter.com/poswald/status/1072134086041300992
On Wednesday, January 16, 2019 at 5:02:57 PM UTC-5, Santiago Basulto wrote:
>
> Hey folks, I was about to submit a ticket but i thought it might be better
> to ask everybody for opinions on the matter first. I am running a couple of
> medium (not even large) Django websites (around +20K users) and we rely on
> the admin heavily. We have multiple models pointing to Users (or other
> derived models) and every time we create a new model, we MUST remember to
> include User in `raw_id_fields` for that model. If we forget to do so, the
> whole testing site crashes when the whole `SELECT * FROM User` query is run.
>
> To add to the problem, some derived models (for example Customer) include
> in their `__str__` both the User + something else. Think about the model
> Customer in this way:
>
> class Customer(models.Model):
> user = models.ForeignKey(User)
> plan = models.ForeignKey(Plan)
>
>
> def __str__(self):
> return f"{self.user} - {self.plan}"
>
>
> (Not a real example, but to make the point)
>
> Imagine any other model with an FK to Customer, an `Inquiry`, for example.
> If you open the `Inquiry` add/change page on the admin, the whole thing
> will blow up.
>
> I know the related select field is an amazing feature, and looks slick on
> the admin when starting a new Django projects (specially for beginners),
> but it just doesn't scale for large websites.
>
> *My proposal*
>
> I think just a project-wide setting `settings.ADMIN_DEFAULT_FK_WIDGET =
> [raw|select]` would work and help us (running a medium/large site) a lot.
>
> What do you think?
>
> Thanks for all the support, this community rocks š¤!
>
> PS: I can create a ticket if that's a better medium of discussion, just
> let me know?
>
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/007c1f0f-b5a2-493d-bfcf-6ea788870e68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable
Hey folks, I was about to submit a ticket but i thought it might be better
to ask everybody for opinions on the matter first. I am running a couple of
medium (not even large) Django websites (around +20K users) and we rely on
the admin heavily. We have multiple models pointing to Users (or other
derived models) and every time we create a new model, we MUST remember to
include User in `raw_id_fields` for that model. If we forget to do so, the
whole testing site crashes when the whole `SELECT * FROM User` query is run.
To add to the problem, some derived models (for example Customer) include
in their `__str__` both the User + something else. Think about the model
Customer in this way:
class Customer(models.Model):
user = models.ForeignKey(User)
plan = models.ForeignKey(Plan)
def __str__(self):
return f"{self.user} - {self.plan}"
(Not a real example, but to make the point)
Imagine any other model with an FK to Customer, an `Inquiry`, for example.
If you open the `Inquiry` add/change page on the admin, the whole thing
will blow up.
I know the related select field is an amazing feature, and looks slick on
the admin when starting a new Django projects (specially for beginners),
but it just doesn't scale for large websites.
*My proposal*
I think just a project-wide setting `settings.ADMIN_DEFAULT_FK_WIDGET =
[raw|select]` would work and help us (running a medium/large site) a lot.
What do you think?
Thanks for all the support, this community rocks š¤!
PS: I can create a ticket if that's a better medium of discussion, just let
me know?
--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/5dae8b31-356c-45f3-b707-83b5ef33f396%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Confusion with Unicode
Russell: Sorry, you're right. I won't do it again. Do you want me to delete this post? Ian. Thank you very much. I found what was causing my bug. I've got Ukranian users and for some reason the request.encoding value was not set, so I'll digg a little bit more. Thanks guys. You rock. On Saturday, November 24, 2012 8:58:00 PM UTC-3, Russell Keith-Magee wrote: > > > > On Sat, Nov 24, 2012 at 9:55 PM, Santiago Basulto > > > wrote: > >> Hey guys, i'm posting this here because I posted this on django-users >> yesterday and didn't get any help. >> >> I realise someone has now answered your question -- but *please* don't > use django-developers as "second tier" technical support. Django-dev is for > discussing the development of Django itself, not for general usage queries. > You should only be posting to django-dev if you want to get involved in the > development of Django itself. > > It's unfortunate that nobody answered your question on django-users, but > this is a volunteer community -- sometimes that means you're not going to > get a response. All I can suggest is that you wait, try rephrasing your > question, or try another forum -- e.g. IRC. > > Yours, > Russ Magee %-) > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/oQID8HsPre0J. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Confusion with Unicode
Hey guys, i'm posting this here because I posted this on django-users
yesterday and didn't get any help.
I'm kind of confused here...
If I get data from a request, say:
request.GET.get("something") or request.POST.get("something")
Is that data automatically being encoded based on the Encoding of the
request? Or I should take care of it explicitly?
Thank you.
--
Santiago Basulto.-
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/PEHu7nmzFwAJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
