What is the purpose of adding `nowrap` class to all ForeignKey fields in django admin objects list?
Django adds `nowrap` class to your `td` if you specify list_display to show any ForeignKey. I can't see the purpose to do it. Any considerably long title breaks table layout hard. Do I miss smth or may be it would be better to just remove 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4b200614-2f40-4421-a925-581b695a71b8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: What is the purpose of adding `nowrap` class to all ForeignKey fields in django admin objects list?
Didn't think about that way to investigate, thanks for the tip. That commit says that it was added because list_editable FK widget would break into several line otherwise (same with date widgets). Well, seems legit. But it's added even if the field is not in list_editable. And now I start thinking that it's a bug rather than random issue. понедельник, 7 декабря 2015 г., 18:14:19 UTC+3 пользователь Tim Graham написал: > > Did you try looking through git blame to find the commit that added it? > > https://github.com/django/django/commit/0b53d318 might be what you're > looking for. > > On Monday, December 7, 2015 at 8:33:34 AM UTC-5, alTus wrote: >> >> Django adds `nowrap` class to your `td` if you specify list_display to >> show any ForeignKey. >> I can't see the purpose to do it. Any considerably long title breaks >> table layout hard. >> Do I miss smth or may be it would be better to just remove 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4474c94b-2891-4287-ade2-10789f238235%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Django explicit `order_by` by ForeignKey field
I've already started this topic in django-users (
https://groups.google.com/forum/#!topic/django-users/k9K7VsPe6aA) and got
an advice there to ask here.
It's not a big issue and it can be solved quite easily as I can see from
django sources. Also there're some workarounds to deal with it but I write
here coz I thinks that it makes django behaviour inconsistent.
So we have 2 models:
class Group(models.Model):
name = models.CharField()
class Meta:
ordering = ('name',)
class Entity(models.Model):
group = models.ForeignKey(Group, null=True)
Now I want to perform a really simple query like this (to order by group_id
field itself):
SELECT * FROM `app_entity` ORDER_BY `app_entity`.`group_id` ASC;
So we use smth like that:
Entity.objects.order_by('group')
and get (not a big surprise, it's well documented behaviour):
SELECT * FROM `app_entity`
LEFT OUTER JOIN `app_group` ON ( `app_entity`.`group_id` = `app_group`.`id`
)
ORDER BY `app_group`.`name` ASC
The only way to get rid of JOIN is to remove ordering attribute from Group
Meta class. But it's not a solution coz it's used in many other places.
So the inconsistency is that we have 2 different behaviours with and
without ordering attribute in related model.
When we don't have ordering defined we can easily order by the field itself
as well as order by any field in related model if we need to.
While when it's defined we loose the way to order by the field itself
(still can use extra or even explicitly specify table name but it's all
quite ugly).
Quite obvious solution is to use `order_by('group_id')` for explicit field
ordering.
But in django<1.7 trying to order by `order_id` raises FieldError. In 1.7
order_by('group_id') became identical to order_by('group').
So if 1.7 is released with that new behaviour it will become
backwards-incompatible to use `order_by('group_id')` for this purpose.
Related topic: #19195
--
You received this message because you are subscribed to the Google Groups
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/59fa8a5e-7dc0-49f1-a123-6d654efb7d00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Django explicit `order_by` by ForeignKey field
Wow, that's cool, thanks! As I see it was quite a long running issue.
понедельник, 28 апреля 2014 г., 23:39:53 UTC+4 пользователь charettes
написал:
>
> After discussion this was escalated to a release blocker in order to make
> sure we don't miss the opportunity of fixing it correctly.
>
> I attached a patch to the ticket that makes sure that explicitly ordering
> by a relation source field (group_id in your case) produces the expected
> result.
>
> Simon
>
> Le lundi 28 avril 2014 07:53:02 UTC-4, alTus a écrit :
>>
>> I've already started this topic in django-users (
>> https://groups.google.com/forum/#!topic/django-users/k9K7VsPe6aA) and
>> got an advice there to ask here.
>> It's not a big issue and it can be solved quite easily as I can see from
>> django sources. Also there're some workarounds to deal with it but I write
>> here coz I thinks that it makes django behaviour inconsistent.
>>
>> So we have 2 models:
>>
>> class Group(models.Model):
>> name = models.CharField()
>>
>> class Meta:
>> ordering = ('name',)
>>
>> class Entity(models.Model):
>> group = models.ForeignKey(Group, null=True)
>>
>> Now I want to perform a really simple query like this (to order by
>> group_id field itself):
>> SELECT * FROM `app_entity` ORDER_BY `app_entity`.`group_id` ASC;
>>
>> So we use smth like that:
>> Entity.objects.order_by('group')
>>
>> and get (not a big surprise, it's well documented behaviour):
>> SELECT * FROM `app_entity`
>> LEFT OUTER JOIN `app_group` ON ( `app_entity`.`group_id` =
>> `app_group`.`id` )
>> ORDER BY `app_group`.`name` ASC
>>
>> The only way to get rid of JOIN is to remove ordering attribute from
>> Group Meta class. But it's not a solution coz it's used in many other
>> places.
>> So the inconsistency is that we have 2 different behaviours with and
>> without ordering attribute in related model.
>> When we don't have ordering defined we can easily order by the field
>> itself as well as order by any field in related model if we need to.
>> While when it's defined we loose the way to order by the field itself
>> (still can use extra or even explicitly specify table name but it's all
>> quite ugly).
>>
>> Quite obvious solution is to use `order_by('group_id')` for explicit
>> field ordering.
>> But in django<1.7 trying to order by `order_id` raises FieldError. In 1.7
>> order_by('group_id') became identical to order_by('group').
>> So if 1.7 is released with that new behaviour it will become
>> backwards-incompatible to use `order_by('group_id')` for this purpose.
>>
>> Related topic: #19195 <https://code.djangoproject.com/ticket/19195>
>>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/c82c7b21-81e4-4c89-84f4-0b75a3ece714%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Master/slave trolling pull request accepted to django master branch
It took 7 minutes and 23 seconds to merge this troll PR without any discussion and now Meira is suggested to wait 6 months? But what can happen? вторник, 27 мая 2014 г., 16:14:43 UTC+4 пользователь Meira написал: > > As some of you may have notice, a hot discussion is happening in the > comments of this pull request: https://github.com/django/django/pull/2692 > Essentially, this pull request suggests that all occurences of > master/slave be replaced with leader/follower. While this is clearly > insane, a less jaw-dropping, but still weird change was made in commit > https://github.com/django/django/commit/beec05686ccc3bee8461f9a5a02c607a02352ae1 > > Many users in comments to the original pull request agreed that > primary/replica is not a good word choice, is vague and misleading. Current > django docs compensate for the confusion by referring to "master/slave" in > parentheses after mentioning "primary/replica". Of course, this change is > nothing more than cosmetical, but it still carries more downsides than > upsides. > Master/slave is* immediately obvious* for the experienced users, and *easily > googleable* for the newbies. > > I reverted the change and sent a pull request > https://github.com/django/django/pull/2720. In the corresponding ticket, > I was told to "wait 6 months" and then resubmit the ticket. ( > https://code.djangoproject.com/ticket/22707), and the pull request was > closed immediately with an advice to start a discussion on mailing list. So > that's what I'm doing here :) > > I sum up my personal point of view in this comment: > https://github.com/django/django/pull/2692#issuecomment-44265422 > > Of course, it'll be hard for the django maintainers to admit their mistake > and revert the change. It's always hard to admit mistakes, but it's better > than leaving it how it is. > -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/66d7cc89-4e34-4227-ad1d-540bd90c2978%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Add to QuerySet method `one` that acts as `first` but without ordering
Hello.
Please consider if that proposal can be useful not only for me :)
`QuerySet.first` is quite useful shortcut but its drawback is that it
involves ordering so some DB queries become expensive.
But quite often (and very often while debugging) there's a need just to get
one object that satisfy some filters.
Current `first` implementation to compare with:
def first(self):
"""Return the first object of a query or None if no match is
found."""
for obj in (self if self.ordered else self.order_by('pk'))[:1]:
return obj
Proposal (as an example of implementation):
def one(self):
"""Return one random object of a query or None if no match is
found."""
for obj in self.order_by()[:1]:
return obj
That would be short, simple and wouldn't require any imports in client code.
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 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/c4337df6-c0f3-44fe-bbc0-01fe01cdf621%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Add to QuerySet method `one` that acts as `first` but without ordering
No, because qs[0] will raise exception if nothing found (and still it will
have ordering).
суббота, 13 апреля 2019 г., 21:24:30 UTC+3 пользователь Adam Johnson
написал:
>
> Doesn’t it work to do qs[0] ?
>
> On Sat, 13 Apr 2019 at 17:48, alTus >
> wrote:
>
>> Hello.
>>
>> Please consider if that proposal can be useful not only for me :)
>>
>> `QuerySet.first` is quite useful shortcut but its drawback is that it
>> involves ordering so some DB queries become expensive.
>> But quite often (and very often while debugging) there's a need just to
>> get one object that satisfy some filters.
>>
>> Current `first` implementation to compare with:
>>
>> def first(self):
>> """Return the first object of a query or None if no match is
>> found."""
>> for obj in (self if self.ordered else self.order_by('pk'))[:1]:
>> return obj
>>
>> Proposal (as an example of implementation):
>>
>> def one(self):
>> """Return one random object of a query or None if no match is
>> found."""
>> for obj in self.order_by()[:1]:
>> return obj
>>
>> That would be short, simple and wouldn't require any imports in client
>> code.
>>
>> 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-d...@googlegroups.com .
>> To post to this group, send email to django-d...@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/c4337df6-c0f3-44fe-bbc0-01fe01cdf621%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/django-developers/c4337df6-c0f3-44fe-bbc0-01fe01cdf621%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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 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/c4fbb785-6857-44f5-b0ef-2c5107e0d6b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Add to QuerySet method `one` that acts as `first` but without ordering
I've posted the source code if `first`. You can see there that if qs is not
ordered then ordering by pk is added.
It's the main point of this issue btw.
суббота, 13 апреля 2019 г., 22:53:52 UTC+3 пользователь Florian Apolloner
написал:
>
> qs.order_by().first() should do what you want and is not worth adding
> .one()
>
> Cheers,
> Florian
>
> On Saturday, April 13, 2019 at 5:48:29 PM UTC+2, alTus wrote:
>>
>> Hello.
>>
>> Please consider if that proposal can be useful not only for me :)
>>
>> `QuerySet.first` is quite useful shortcut but its drawback is that it
>> involves ordering so some DB queries become expensive.
>> But quite often (and very often while debugging) there's a need just to
>> get one object that satisfy some filters.
>>
>> Current `first` implementation to compare with:
>>
>> def first(self):
>> """Return the first object of a query or None if no match is
>> found."""
>> for obj in (self if self.ordered else self.order_by('pk'))[:1]:
>> return obj
>>
>> Proposal (as an example of implementation):
>>
>> def one(self):
>> """Return one random object of a query or None if no match is
>> found."""
>> for obj in self.order_by()[:1]:
>> return obj
>>
>> That would be short, simple and wouldn't require any imports in client
>> code.
>>
>> 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 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/fc6e71e5-a9b5-4cb5-9283-de1130ff0b2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Add to QuerySet method `one` that acts as `first` but without ordering
Hi. Thank you for that detail response. It needs to be clarified that I'm not that worried about exception as it could seem :) It was just an answer to those 2 comments to show that their workarounds result in different behaviour than proposed `one`. `get_or_none` would be useful in my opinion too but still it does not exactly the same thing because it would still raise MultipleObjectsReturned. On the other hand, `one` is: 1) totally safe: None for nothing, same as `get` for 1 object, some random row if multiple found 2) have the same DB perfomance as `get` 3) has no overhead for exception (can affect performance in long cycles) воскресенье, 14 апреля 2019 г., 11:23:17 UTC+3 пользователь Shai Berger написал: > > Hi, > > I agree that first() should imply ordering, and bemoan the decision, > made several years ago, that first() should be the answer to all the > people asking for get_or_none(). > > That said, get_or_none()'s definition is trivial: > > def get_or_none(qs. *args, **kw): > try: > return qs.get(*args, **kw) > except ObjectDoesNotExist: > return None > > and it's not hard to add it as a method on your own querysets or even > monkeypatch it into Django's using a descriptor: > > class MonkeyPatcher: > def __init__(self, method): > self.method = method > def __get__(self, instance, cls): > return functools.partial(self.method, instance) > > QuerySet.get_or_none = MonkeyPatcher(get_or_none) > > (all above untested, Caveat Lector). > > On a side note, you seem to be very worried about the possibility that > an exception will be raised. It may be an issue in terms of flow > control, but not in terms of overhead, so including code to handle an > exception does solve that issue. > > HTH, > Shai. > -- 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/96a8bb7f-f46f-4124-bf73-b811eb65eaef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
