I've been working on the Kolo debugging tool and as part of that I've also
run into this issue. Generating unexpected queries when monitoring a django
project was a nasty surprise.
In Kolo's case I was also able to work around it with a monkeypatch, but
not needing this would be a nice performance
I want to add that I think either proposed change here would be an
improvement and that I'd prefer not to see this idea die because of
bikeshedding over the best option.
Regards,
Ian
On Thu, 21 Apr 2022 at 19:21, ome chukwuemeka
wrote:
> I think this is a good suggestion!
>
> On Thu, Apr 21, 20
I think deprecating it is a good idea. I think it's actually a small
footgun - I've seen it used to restrict access to non-admin functionality,
when `user_passes_test` would be appropriate. In the case I found it, it
made adding tests trickier than it should have been.
Ian
On Tue, 9 Mar 2021 at 2
Hi Barry,
Based on this I'm cautiously in favour. You set out a good case, it's much
easier to understand the "why" here than in the original ticket.
I'd avoid the extra optimisation of accessing __dict__ directly though - if
__set__ gains extra functionality, I'd prefer not to accidentally miss
Hi Tim,
This feels like a good idea to me.
Regards,
Ian
On Mon, 18 Apr 2022 at 18:17, Tim Allen wrote:
> Greetings, friends!
>
> I've issued a PR that makes two changes to the `startproject` template:
>
>- instead of putting configuration files such
>as `settings.py`, `wsgi.py`, and th
Hi all,
I've been working on https://code.djangoproject.com/ticket/11964 to add
support for Check Constraints to the Django ORM and migrations
framework. My work can be found at
https://github.com/django/django/pull/7615.
I think the functionality is basically there, so what it really needs
s would be a
> possibility as a future extension of your pull request?
>
> Cheers,
> David
>
>
> On Friday, August 11, 2017 at 4:15:26 AM UTC+10, Ian Foote wrote:
>
> Hi all,
>
> I've been working on https://code.djangoproject.com/ticket/11964
&g
Hi Brylie, Laurence,
I think it should be possible to do this using my Check Constraints work
(https://github.com/django/django/pull/7615) or something built on top
of it.
I plan to get this work into shape so it can land in Django 2.1.
I hope this helps,
Ian
On 03/10/17 10:40, Laurence Sonnenb
On 02/09/18 17:58, Shivam Jindal wrote:
> I have the following model
>
> class Member(models.Model):
> user = models.OneToOneField(User, null=True, blank=True)
>
> *Operation sequence*
>
> m = Member.objects.get(id=4) # This objects has attached user
> m.user # Print user objects successfull
On 02/09/18 19:59, Shivam Jindal wrote:
> Hi Lan,
>
> *m.user.refresh_from_db()* is sam as
>
> *u = m.user*
> *u.refresh_from_db()*
>
> So If I am refreshing u, it should update all relationship and property
> of *u*(including reverse relation). Should It not?
>
Hi Shivam,
As far as I can te
Hi all,
On my pull request (https://github.com/django/django/pull/10406)
refactoring how Django creates database constraints I introduced a
dependency on sqlparse in the sqlite introspection code. This allows Django
to correctly read information about constraints on sqlite, particularly the
name.
Hi Carlton,
I've had similar thoughts sitting in the back of my mind for at least a
couple of months, so thank you for sharing this. I agree that finding
tickets is one of the big problems here, both for new contributors and for
sprint leaders. At Pycon UK I took on the role of sprint leader along
I'm not in favour of this, it's too implicit for my liking and I don't
think any gains outweigh the increased complexity of implementation.
Ian
On Wed, 31 Oct 2018 at 19:04, charettes wrote:
> My main concern with allowing extra args and kwargs to be mixed with the
> proposed
> pk arg notation
I think {} formatting has some minor readability benefits. The symmetry of
the braces makes it easier (imo) to see at a glance what is going to be
interpolated. With % formatting the alphabetical characters can be obscured
by other text in the string, especially if there's not a space after it.
I'v
I don't think a new setting is the way to go. I'd prefer to add an
attribute (validate_m2m = False?) to the CreateView and UpdateView classes
that allows a developer to opt-in to the new behaviour when they need it.
This is more flexible and still maintains backwards compatibility.
Regards,
Ian
O
I'm in favour. Not needing to think much about code style when writing code
or when reviewing is very nice.
Ian
On Sat, 13 Apr 2019 at 13:52, Herman S wrote:
> Hi.
>
> I propose that Django starts using 'black' [0] to auto-format all Python
> code.
> For those unfamiliar with 'black' I recommen
Hi Emil,
This is a very interesting idea and I find your use-case compelling. Adding
support for custom triggers to Django itself would resolve your main use
case this time but I also see value in a general solution that enables
Django's third-party ecosystem.
I think the next step is to open a n
I think the consensus here is to not add the extra commit, so I've
closed the ticket as wontfix.
(https://code.djangoproject.com/ticket/16735#comment:26)
Ian
On 20/08/16 15:24, Josh Smeaton wrote:
Just as an additional data point - most expressions that accept
strings internally convert them
Hi Tom,
I really like the look of Count('emails').filter(unread=False) in the
annotate call.
Ian
On 12/04/17 21:35, Tom Forbes wrote:
> Hello,
> At the Djangocon sprints I wanted to add support for a postgres specific
> syntax for filtering aggregations, which is quite simple: MAX(something)
> F
Hi Dmitriv,
I think you're running into https://code.djangoproject.com/ticket/27332.
Unfortunately this isn't fixed yet, but there's a pull request, so it
might land in 2.0: https://github.com/django/django/pull/7560
Ian
On 21/04/17 19:41, Dmitriy Sintsov wrote:
> If I understand correctly, LEFT
20 matches
Mail list logo
