Re: Add verbosity option to manage.py checks that outputs which checks are ran

and as > you've discovered it's not always easy to ensure your module gets imported. > > On Wed, 10 Jun 2020 at 21:16, Gordon > > wrote: > >> Particular case that spurred this - reusable app had checks to make sure >> urls were reversible. Checks wer

Re: Add verbosity option to manage.py checks that outputs which checks are ran

tion about which checks are run makes sense. They are a great way for checking runtime conditions against production settings but not being able to confirm they actually ran somewhat negates the peace of mind that all is well. Thanks, Gordon On Wednesday, June 10, 2020 at 11:59:39 AM UTC-4, Ad

Add verbosity option to manage.py checks that outputs which checks are ran

This is a discussion for https://code.djangoproject.com/ticket/31681 - the feature would be useful to me and seems like something generally useful as well since it is implemented in the testing framework. The closing comment mentions that copying a documentation page into command output isn't

Re: handle_uncaught_exception error logging

a3e3284e6. > > That change was made in Django 2.1. You didn't say what version of Django > you're using. > > You'll have to give more details about your case and what's behaving > differently. > > On Sunday, April 12, 2020 at 8:57:12 AM UTC-4, Gordon wrote: >>

handle_uncaught_exception error logging

Why was the error log removed from handle_uncaught_exception? I didn't find mention about it but I've recently encountered a middleware causing a 500 error and not getting a traceback log was unexpected. https://github.com/django/django/blob/stable/2.0.x/django/core/handlers/exception.py#L115

Re: Management command that fails when there are created migrations waiting to be applied to the database

command. > > > > On Thu, 26 Mar 2020 at 07:29, Gordon > > wrote: > >> Good morning. >> >> I had created ticket https://code.djangoproject.com/ticket/31402 after >> discussing in IRC about a built in way to stop a continuous delivery &

Management command that fails when there are created migrations waiting to be applied to the database

Good morning. I had created ticket https://code.djangoproject.com/ticket/31402 after discussing in IRC about a built in way to stop a continuous delivery pipeline if the deployment would need to run database migrations. (i.e. if running `python manage.py migration` would do anything or not.

Re: Automatic prefetching in querysets

My existing code for this is now available as a pypi package https://github.com/tolomea/django-auto-prefetch -- 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

Re: Add subdomains of localhost to ALLOWED_HOSTS in DEBUG mode

all in favour of making development easier. Would be in favour of this > if I could see a source :) Also can you check the behaviour in more > browsers than Chrom(e|ium)? :) > > On Thu, 21 Nov 2019 at 21:40, Gordon wrote: > >> Good afternoon, >> >> It seems p

Add subdomains of localhost to ALLOWED_HOSTS in DEBUG mode

for new projects. Please let me know what you think =) Thanks, Gordon -- 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, sen

Re: Force "required" fields to be included in a ModelForm

Well shoot...this definitely seems like something only I'm running into. Appreciate y'alls feedback. Thanks  -- 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

Re: Force "required" fields to be included in a ModelForm

Would it be weird to just make it so that the "required" field *must* be present in exclude? This way, if you *accidentally* leave off a required field, you're quickly notified about itbut if you explicitly mark it as something to exclude, it makes it clear to everyone exactly what you're

Re: Force "required" fields to be included in a ModelForm

I can certainly agree that there may be some use cases where it should be possible to disable this functionality, but I would argue that erroring on a missing, required field should be the default, and allow for a way to override...as opposed to allowing missing fields and requiring a

Re: Force "required" fields to be included in a ModelForm

Sorry if I wasn't more clear, but using a warning was exactly what I was proposing. In the same way that a FieldError is raised when an editable field is listed in fields, I was essentially planning on doing the exact same check on the blank attribute. I agree that this should be ignorable, and

Force "required" fields to be included in a ModelForm

In the same way that editable fields are forced to not be included in a ModelForm ( https://github.com/django/django/blob/master/django/forms/models.py#L146), I would like to propose that "required" fields (`blank=False`) be forced to be included in a ModelForm. While I understand that a

Re: Why does ModelForm do validation and not Model

Ahh, cool. That makes more sense. I worry that it still leaves open the potential of accidentally not validating something. It may make more sense to offer instance.save(validate=False) instead of relying on the developer to always know whether they can trust the input. But I agree that for

Re: Why does ModelForm do validation and not Model

So the validation is cheaper when performed by ModelForm, as opposed to the Model? -- 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

Why does ModelForm do validation and not Model

I can't seem to find a good reason for this. And I could foresee this preventing potential mistakes. I'm not proposing to actually change the implementation, I guess I'm just looking for the reason of it. -- You received this message because you are subscribed to the Google Groups "Django

Re: Sealing or locking QuerySets -- a suggestion to prevent surprise N+1 queries.

Regarding auto prefetch, after the discussion here I created a ticket https://code.djangoproject.com/ticket/28586 It didn't get much attention presumably because it was around Django 2 release time. I have a todo note to add tests and doco and generally get it to a mergable state in order to

Re: Automatic prefetching in querysets

This received some positive responses, so to help move the conversation along I have created a ticket and pull request. https://code.djangoproject.com/ticket/28586 https://github.com/django/django/pull/9064 Regards G On Tue, Aug 15, 2017 at 10:44 AM, Gordon Wrigley <gordon.wrig...@gmail.

Re: Automatic prefetching in querysets

I'm not advocating either way on this, but it's probably worth noting that the context manager proposal is compatible with a queryset level optin/out and an object level optout. So you could for example have prefetch_related(auto=None) which can be explicitly set to True / False and takes it's

Re: Automatic prefetching in querysets

Regarding 2, it does work for reverse one-to-one relations. On Wed, Aug 16, 2017 at 9:17 PM, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > On 15 Aug 2017, at 11:44, Gordon Wrigley <gordon.wrig...@gmail.com> wrote: > > I'd like to discuss automatic pre

Re: Automatic prefetching in querysets

tion may be accessed >>> once or twice while iterating over a large python filtered queryset. >>> Prefetching this relation based on the original queryset has the >>> potential to add around 5 seconds to the response time (probably more, that >>> table has

Re: Automatic prefetching in querysets

lution would be for Django to detect these O(n) query > cases and display intelligent warnings, with suggestions as to the correct > select/prefetch calls to add. When debug mode is enabled we could detect > repeated foreign key referencing from the same source. > > On 15 Aug 2017 19:44

Re: Automatic prefetching in querysets

t unlike Django where I have years of experience I have next to no experience with other ORM's. Regards G On Tue, Aug 15, 2017 at 7:44 PM, Gordon Wrigley <gordon.wrig...@gmail.com> wrote: > Sorry maybe I wasn't clear enough about the proposed mechanism. > > Currently when you d

Re: Automatic prefetching in querysets

15, 2017 at 8:03 PM, Collin Anderson <cmawebs...@gmail.com> wrote: > Hi Gordon, > > How is it implemented? Does each object keep a reference to the queryset > it came from? > > Collin > > On Tue, Aug 15, 2017 at 2:44 PM, Gordon Wrigley <gordon.wrig...@gmail.com>

Re: Automatic prefetching in querysets

clear how this mechanism would sanely interact with filtering etc. So this is purely about the forward direction of foreign keys. I hope that clarifies my thinking some. Regards G On Tue, Aug 15, 2017 at 7:02 PM, Marc Tamlyn <marc.tam...@gmail.com> wrote: > Hi Gordon, > > Thanks for the sugg

Automatic prefetching in querysets

I'd like to discuss automatic prefetching in querysets. Specifically automatically doing prefetch_related where needed without the user having to request it. For context consider these three snippets using the Question & Choice models from the tutorial

Re: delegating our static file serving

. It is roughly 100 lines. https://gist.github.com/thenewguy/a92e05a3568fb6f1cc7c On Saturday, January 16, 2016 at 6:11:46 PM UTC-5, Gordon wrote: > > Apologies if this has already been mentioned but I read this thread in > full awhile ago and now everything is collapsed. > >

Re: delegating our static file serving

Apologies if this has already been mentioned but I read this thread in full awhile ago and now everything is collapsed. If staticfiles serving is brought into django proper it would be nice if the storage api was used so that staticfiles can be stored remotely. I just ran into this looking at

Re: Why is from_db_value not called on ModelClass.objects.create()?

Thanks for the replies and suggestions Simon and Marten. I am definitely calling form.clean() because I am using the default admin for views in my tests. The field in the case that was tripping me up is being used as an auto-populating primary key... so the admin form was excluding it from

Why is from_db_value not called on ModelClass.objects.create()?

I originally asked this on IRC. It was suggested to raise the question in the mailing list. I've copied the log below with irrelevant lines removed (dpastes provided after the quoted irc) Why is from_db_value not called on Cls.objects.create()? For example, > in the CashModel test, why

Re: django admin: open popups as modals instead of windows

I just wanted to add my 2cents worth as an opinion in favor of modals replacing popups for many of the admin links. I am in no way claiming that a poorly implemented modal window is superior to a new window... and there are certainly cases where a new window is preferable to the "perfect"

Re: Removing formtools from contrib (and call for maintainers)

I mentioned this in the other thread but I will post here as well since it has moved. I would be interested in being part of this. Is there any sort of timeline on the move or is it just a proposal at this time? On Saturday, July 12, 2014 12:55:52 PM UTC-4, Jannis Leidel wrote: > > Hi all, >

Re: FormWizard needs confirmation step logic. ticket #21644

> > If we did split it out, would you be interested in being a maintainer? > > I was against this at first but the more I've thought about it, I would be interested. Has anyone else expressed any interest or will I be the only maintainer? I have another project coming up that will most likely

Re: FormWizard needs confirmation step logic. ticket #21644

How would that work? Being part of contrib is a big plus for the app in many ways. I am not familiar with another app that was removed from contrib that would show an overview of the process and if it was successful. -- You received this message because you are subscribed to the Google

Re: FormWizard needs confirmation step logic. ticket #21644

If > would be a good candidate for deprecation from Django itself, in my opinion. > > On Monday, May 26, 2014 3:32:41 PM UTC-4, Gordon wrote: >> >> Hello, >> >> I have posted an implementation/proof of concept to ticket 21644 ( >> https://code.d

FormWizard needs confirmation step logic. ticket #21644

ld inherit from to detect when confirmation logic should be used. This allows for a backwards compatible opt-in approach. Thanks, Gordon -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop r

Re: Is the solution in #12235 correct?

After a chat on IRC I submitted ticket https://code.djangoproject.com/ticket/19888 On Friday, February 22, 2013 5:07:25 PM UTC-5, Gordon wrote: > > Hello, > > I don't think the issue is fixed. > > I am trying to use a UUID primary key. Per > https://code.djangoproject.c

Is the solution in #12235 correct?

Hello, I don't think the issue is fixed. I am trying to use a UUID primary key. Per https://code.djangoproject.com/ticket/12235, I've marked my field as the autofield in contribute_to_class. However, now when I try to save a new instance, django is trying to insert an integer into my

issue 15644

Is this bug fix too late for the upcoming release? https://code.djangoproject.com/ticket/15644 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit

Re: Tests blocked by AssertionError 200 != 302 in login() calls

On Dec 5, 7:06 pm, Russell Keith-Magee wrote: > It's unclear if you're in the right place. Django-dev is for > discussing the development of Django itself; django-users is for > general user queries. Generally, if you're unsure, django-users is the > right place to start.

Tests blocked by AssertionError 200 != 302 in login() calls

Apologies if this isn't the right forum for this question. When I run "manage.py test", I get many errors of this form: FAIL: test_password_change_fails_with_invalid_old_password File File tests/views.py", line 136, in login AssertionError 200 != 302 The last line is always a call on a