Re: Backport for ticket 34063?

On Sun, Jan 1, 2023 at 7:01 PM Tim Graham wrote: > Incidentally, I don't think it's important for the ultimate decision here, > but I looked at the below analysis of ticket #32189. Carlton's analysis on > the ticket that request.POST is empty when using 'content-type': > 'application/json'

Re: Generated Field

I have implemented a first draft for this feature! Feedback and ideas are greatly appreciated. https://github.com/django/django/pull/16417 https://code.djangoproject.com/ticket/34238 On Saturday, December 24, 2022 at 8:56:38 p.m. UTC-7 schinckel wrote: > I believe there are a bunch of

Re: Backport for ticket 34063?

Incidentally, I don't think it's important for the ultimate decision here, but I looked at the below analysis of ticket #32189. Carlton's analysis on the ticket that request.POST is empty when using 'content-type': 'application/json' remains true. The results of the tests provided in the

Re: Backport for ticket 34063?

I guess it's nice to have a strict backport policy, partly to avoid hours of discussion like this, which ultimately boils down to a judgment/prediction about severity and whether or not the current backport policy should be amended. If I encountered a similar issue, I would have just worked

Re: Backport for ticket 34063?

On Sun, Jan 1, 2023 at 12:54 PM Tim Graham wrote: > Older Django releases are currently maintained with minimal support that > allows existing projects to continue running securely. I don't think we > should invest resources in promoting them as a place to use experimental > features. A

Re: Apache and mod_wsgi

Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely

Apache and mod_wsgi

Hi i am using Apache with mod_wsgi.i want to serve 5000 users at a time.how many processes and threads should I use in order to serve 5000 connections concurrently...in wsgi daemon process ? -- You received this message because you are subscribed to the Google Groups "Django developers

Re: Backport for ticket 34063?

Older Django releases are currently maintained with minimal support that allows existing projects to continue running securely. I don't think we should invest resources in promoting them as a place to use experimental features. A benefit of running an old LTS release like 3.2 is that any

Re: get_manager short ut function proposal

Mmmm I believe what you shared Shai is very sophisticated than what is proposed. The proposal is a shortcut function for with ability to have a custom parent for more usability for an everyday use , like what's in the documentation about managers. My proposal is *not* a new way to write managers

Re: get_manager short ut function proposal

On Sun, 1 Jan 2023 16:33:45 +0200 Ramez Ashraf wrote: > > Interested or do you think the function can be enhanced it to make > more useable for your everyday other cases ? > This is half-baked, just a thought, but maybe you can take it some place interesting: Imagine a class that "collects"

Re: Backport for ticket 34063?

Hi, I think at this point it would help to move the discussion forward, if we tried to step beyond the specific issue and phrase the revision in the backporting policy. This will let us, I hope, have a more principle-based discussion. If I get it right -- please correct me, James -- it would be

Re: get_manager short ut function proposal

Hello Adam Happy new year! Thank you for the feedback, really appreciate it. I thought the same like you at first, a cool function in my project (which is indeed the case) One thing that gave me more incentive is the documentation code example. IMO, i can see how shorter (and more readable) it

RE: Backport for ticket 34063?

Happy New Year! I've been reading this thread with keen interest since James first brought it up. I think James's rationale is on point and that the back port to fix the bug needs to be done. To the future of async, Matthew -Original Message- From: django-developers@googlegroups.com

Re: Backport for ticket 34063?

On Sat, Dec 31, 2022 at 2:12 AM 'Adam Johnson' via Django developers (Contributions to Django itself) wrote: > In the past I have also been frustrated at particular bug fixes not being > backported. But I've gradually come to appreciate just how valuable the > backport policy is. It keeps

Re: get_manager short ut function proposal

Your proposal is quite niche: it only shortens the creation of a Manager class when you need to add a single filter() call. The function seems like it might be a useful helper within a project, if you use many such managers. But custom managers might use any queryset methods, or other logic. I've

Re: Backport for ticket 34063?

This thread got too long too fast: it's a hell of a lot to catch up on. In the future, please can we all let things sit for a bit so other voices can chime in, especially when the issue has concretely affected very few users. In the past I have also been frustrated at particular bug fixes not

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 11:22 PM Carlton Gibson wrote: > Under normal circumstances you just use the sync Client, as you've always > done. `response = client.get(`/my-async-view/`)`. > Django handles that the **view** is async for you. > > It's only if you need to write an actual **async test**,

Re: Backport for ticket 34063?

Just to clarify this point, which I think has been glossed over: > But unless I'm misunderstanding the nature of the bug, this seems like it basically makes async views un-testable ... This isn't correct. Under normal circumstances you just use the sync Client, as you've always done. `response

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 2:24 PM Tim Graham wrote: > As perfectionists, it's always hard to say (and hear) "no" when this sort of > request comes up. I wrote a 2,000-word argument explaining why I believe this warrants backporting. I think that deserves more engagement than just a "no". > I'm

Re: Backport for ticket 34063?

I'll say upfront that I haven't hit this particular issue, but it's mostly because I've avoided the Django async stack after some challenging experiences on the old(er) channels/daphne/etc. stack and its evolution. I've personally been in the "let's see how this develops" camp, which

Re: Backport for ticket 34063?

As perfectionists, it's always hard to say (and hear) "no" when this sort of request comes up. I'm unconvinced it's a serious issue that requires a break from normal policy. (Unreported for 2 years in 4 major releases; simple workaround present.) Incidentally, escalating an issue to the

Re: Backport for ticket 34063?

I have put it to the Steering Council: https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1 -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)"

Re: Backport for ticket 34063?

> Even if it will not be fixed for older versions, Django 4.1 ought to be eligible for a backport. What you're suggesting is a change to the backport policy. That may be the right thing to do, but it would be quite a significant change. These issues — where a bug report/fix comes outside the

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 2:04 AM Carlton Gibson wrote: > No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that means > if you're using those on older versions of Django, you'll need to work > around. > This is no different than any of a thousand other cases where there's been > a

Re: Backport for ticket 34063?

James, I think the backport policy has proven itself over the years, no? "Django lied" — that's a bit melodramatic don't you think?. Django introduced a new feature, as it is wont to do. There was a bug in that new feature, as there are wont to be. Unfortunately that bug was not discovered

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson wrote: > It's frustrating when this happens, but the backport policy has proven its > worth time and again. > I **really** don't see the case for making an exception here. > (The policy has more value than the inconvenience in any of these cases, or

Re: Backport for ticket 34063?

OK, yes, that's probably right. Had #34063 been reported during the 3.1 cycle it would have been a release blocker. As it was, it wasn't reported until 4.0 (when main was already 4.1) so two cycles later. As such it no longer qualifies for a backport. It's frustrating when this happens, but the

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 1:09 AM Carlton Gibson wrote: > All you're talking about is adding this to your test cases right? > > # Work around Django #34063 until 4.2. > request.body As far as I can tell it needs to go in whatever code will *read* request.POST, not the code that generates the

Re: Backport for ticket 34063?

James, All you're talking about is adding this to your test cases right? # Work around Django #34063 until 4.2. request.body # ... continue C. On Fri, 30 Dec 2022 at 10:04, James Bennett wrote: > On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson > wrote: > > When I looked at the trace you

Re: Backport for ticket 34063?

On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson wrote: > When I looked at the trace you posted in IRC yesterday, my first thought was > "3.2?". I think supporting Django 3.2 at this point isn't worth the effort. It's also broken in 4.0 and 4.1. I just posted the first trace I got back from my

Re: Backport for ticket 34063?

Hey James. Grrr.  I don't think this justifies an exception to the backport policy. It's not significantly different from any of any number of other fixes that folks ask for a backport for and we say no. Fielding "but you backported that one" isn't an extra task that's going to be helpful.

Backport for ticket 34063?

https://code.djangoproject.com/ticket/34063 The short summary of that ticket is that there was a significant behavioral difference between django.test.Client and django.test.AsyncClient: with AsyncClient, any view or middleware which attempted to access request.POST without first accessing

Re: Updating profile image in django

Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely

Re: building a payment app

Hi! I think you've found the wrong mailing list for this post. This mailing list is for discussing the development of Django itself, not for support using Django. This means the discussions of bugs and features in Django itself, rather than in your code using it. People on this list are unlikely

building a payment app

hi everyone, thank your for accepting me. so i am building a payment gateway and i am stuck on how to integrate the cards in the views in django. can anyone help me -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django

Re: Fellow Reports - December 2022

Week ending December 25, 2022 *Triaged: * https://code.djangoproject.com/ticket/34217 - Migration removing a CheckConstraint results in ProgrammingError using MySQL < 8.0.16. (accepted) https://code.djangoproject.com/ticket/34216 - django admin when field is autocomplete it overrides

Updating profile image in django

Hello everyone, so I have I have this issue when trying to update a profile photo in django. The Profile photo actually updates if I upload an image. But there are cases where a user may want to update other details without updating the profile photo. Trying to implement that gives me a

Re: django squashmigrations creating incorrect code?

Yes, a single line message warning that the migration needs some edits would be nice. On Fri, Dec 23, 2022 at 11:18 AM Christian González < christian.gonza...@nerdocs.at> wrote: > HM wouldn't it be better to add a stdout message after completing the > squash? Because if the cmd doesn't say

Re: Generated Field

I believe there are a bunch of similarities between the requirements of generated fields and my project django-shared-property: https://django-shared-property.readthedocs.io/en/latest/ On Sunday, December 25, 2022 at 10:23:10 AM UTC+10:30 jeremy...@gmail.com wrote: > I'd love to help

Re: Generated Field

I'd love to help implement this if we can find a rough syntax! I've made a proof of concept in Postgres, and there are two outstanding limitations to address: - The generated field value is not set until the model is reloaded from the database - The `GENERATED ALWAYS` expression requires an

Re: django squashmigrations creating incorrect code?

HM wouldn't it be better to add a stdout message after completing the squash? Because if the cmd doesn't say anything, the user assumes that everything went well. I wasn't aware of squash migrations being even that smart to recognise RunPython methods. So a stdout.write() with more or less this

Re: django squashmigrations creating incorrect code?

Good to know. On Fri, Dec 23, 2022, 02:43 Christian González < christian.gonza...@nerdocs.at> wrote: > AH, sorry. Just saw it: > > # Functions from the following migrations need manual copying.# Move them and > any dependencies into this file, then update the# RunPython operations to > refer

Re: django squashmigrations creating incorrect code?

AH, sorry. Just saw it: # Functions from the following migrations need manual copying. # Move them and any dependencies into this file, then update the # RunPython operations to refer to the local versions: # medux.core.migrations.0001_initial Am 22.12.22 um 22:12 schrieb Christian

django squashmigrations creating incorrect code?

Hi devs, before I file a bug, small check here: I squashed my migrations using "./manage.py squashmigrations core 0003" It squashed all existing 3 migrations, including a runPython migration in 0001. The resulting migration contains this code: migrations.RunPython(

Re: DEP 12 (Steering Council) Fully Adopted

Awesome On Mon, 19 Dec 2022 at 8:55 PM, Andrew Godwin wrote: > Hi everyone, > > I am pleased to report that we've completed the extended approval process > for DEP 12, which was needed since it was a governance change. Both the > Technical Board and the DSF Board voted to not require a vote

Re: Potential way forward for DATABASE_URL

> To be clear, "pressure to get the API right on the first shot" is a > statement of fact about adding APIs to a heavily used project in > general, not a comment on anything said in this mailing thread. Just > that in this case there's a lot of ways to get the ergonomics wrong. Yes and I think

Re: Potential way forward for DATABASE_URL

To be clear, "pressure to get the API right on the first shot" is a statement of fact about adding APIs to a heavily used project in general, not a comment on anything said in this mailing thread. Just that in this case there's a lot of ways to get the ergonomics wrong. On Wednesday, December

Re: Potential way forward for DATABASE_URL

OK after looking at this some more and trying to write up a review aid, I'm giving up on this branch and trying to integrate DATABASE_URL support into Django proper. A couple reasons: - I misread the original mailing list thread which made me think there was a consensus on this branch, and

get_manager short ut function proposal

Hello everyone, I want to propose a helper function `get_manager(parent_manager=None, *args, **kwargs)` A shortcut to return a manager, *args & **kwargs are passed to the manager .filter() pass parent_manager to customize the parent manager, defaults to ``Manager``. it can be used like this

DEP 12 (Steering Council) Fully Adopted

Hi everyone, I am pleased to report that we've completed the extended approval process for DEP 12, which was needed since it was a governance change. Both the Technical Board and the DSF Board voted to not require a vote from the membership on the change, so it is now officially adopted and I

Re: Fellow Reports - December 2022

Week ending December 18, 2022 *Triaged: * https://code.djangoproject.com/ticket/34204 - Django cannot load when Python is compiled with --without-doc-strings enabled (wontfix) https://code.djangoproject.com/ticket/34208 - Confirm/Add support for GDAL 3.6. (created)

Fellow Reports - December 2022

Week ending December 11, 2022 *Triaged: * https://code.djangoproject.com/ticket/34200 - Allow setting postgres role during connection setup (needsinfo) https://code.djangoproject.com/ticket/34201 - Drop support for SQLite < 3.21.0 (created) https://code.djangoproject.com/ticket/34202 - Strict

Re: Standalon Django ORM

I think we already have this no? See https://docs.djangoproject.com/en/4.1/ref/databases/#s-third-party-notes for a list of 3rd party DB backends. On Tue, 13 Dec 2022 at 10:31, Vasanth Mohan wrote: > I second Jörg about better maintainability with tighter integrations. > > However, for the fun

Re: Standalon Django ORM

I second Jörg about better maintainability with tighter integrations. However, for the fun of stirring the pot, what's the opinion on letting Django define an API for the ORM and letting a library deal with the DB-specific implementation that generates the SQL for query? Django could have a

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

Hi Developers, I am a Junior Python / Django Developer. I have developed some projects with help of Django Backend Development with complete authentication & authorization and others features. So now my question is that, I am also learning Flutter in my university course (Mobile Application

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

Perhaps one of the ideas for GSoC would be to update the code for the ORM (or maybe just a single backend?) to include Type hints. Last year (2022) it was mentioned here . I think this might make it easier to allow newcomers to

Re: Standalon Django ORM

I tend to believe the opposite is true. Django was/is a successor in its field, because it offers an "out-of-the-box" or "batteries included" experience. Subsequently parts were shaped as needed for that bigger picture, e.g. the ORM became what it is today. Does anyone still remember django

Standalon Django ORM

Hi, Given the small number of Django ORM maintainers, making the ORM standalone will, among other things, increase the adoption of Django and bring in new maintainers. An ORM inspired by Django ORM with over 3000+ stars: https://github.com/tortoise/tortoise-orm -- You received this

Re: Make Cookies in Django follow the RFC correctly

I've taken some time to read all the discussion again, imagine some scenarios, and read the comment that Collin made at it's own PR at GitHub here . Most of them would need to break compatibility, and now I agree that there

Django bugfix release: 4.1.4

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2022/dec/06/bugfix-release/ -- 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: Make Cookies in Django follow the RFC correctly

On the ticket associated with that PR ( https://code.djangoproject.com/ticket/33212 ), there was a lot of discussion, ending with Mariusz saying: As far as I'm aware both propositions (PR15015 and PR15019) are backward > incompatible, so they are against out stability policy, unless it's not a >

Re: Can we move the activity on this list to the Forum now?

I did some investigation of moving django-users and django-developers to the Forum right after DjangoCon; I wanted to see if we could import all the old posts too, which we probably could, but I'm not entirely sure of the utility of that. I will say that the forum is a lot easier to moderate -

Make Cookies in Django follow the RFC correctly

Currently the implementation of Cookies doesn't follow the RFC 6265 correctly, especially the *Path* part that seems to be ignored. That was already an attempt here: https://github.com/django/django/pull/15019, but @collinanderson

Re: Fellow Reports - November 2022

Week ending December 4, 2022 *Triaged: * https://code.djangoproject.com/ticket/34187 - UserCreationForm should save data from ManyToMany form fields (accepted) https://code.djangoproject.com/ticket/34189 - Code in Tutorial does not work because of a ',' (invalid)

Re: Fellow Reports - November 2022

Week ending November 27, 2022 *Triaged: * https://code.djangoproject.com/ticket/34171 - QuerySet.bulk_create() crashes on mixed case columns in unique_fields/update_fields. (accepted) https://code.djangoproject.com/ticket/34173 - SessionMiddleware only returns 400 or 500 error in case

Re: Technical Board vote on DEP 0012: The Steering Council

Hi all, I am pleased to announce that this vote has passed with 5 Board members voting +1 and no other votes. I will now proceed to notify the DSF Board that they must hold a vote, as is required by DEP 10. Either they or I will update the list with information once that vote has been

Re: Async wrappers in contrib packages

> But I can file a ticket just to track this one? TBH I'd prefer it if you pondered the design here without opening a ticket until such a point (if ever) that you have a concrete plan. (We'd likely just close it as wontfix unless there's a specific idea on the table anyway, so it's just noise at

Re: Technical Board vote on DEP 0012: The Steering Council

Yes, I agree we can use the forum in future since it's less tied to Google. Provided the current +5 vote carries through to the end of the voting period, I will be suggesting that the Technical Board triggers the DEP 10 mechanism where we move this to the membership for a vote once the DSF

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

Adrian, > I'd personally like to see better support for safe / N-1 compatible migrations within Django itself, currently if you do CD / blue-green tower / etc. deployments you need to be very careful about the migration operations that you introduce version-to-version, although I'm not sure

Re: Set a reasonable default for EMAIL_TIMEOUT

Federico - I think we’d like to see a few more “pro”s in the thread. Personally, I am pro adding a default timeout. The lack of a default timeout in *requests* is a constant source of outages, which lead me to write this hack

Re: Set a reasonable default for EMAIL_TIMEOUT

Hi everyone, do you think you are against on opening an issue for this? I had already opened an issue which was marked as wontfix and I was asked to open this discussion here. Best regards Federico On Monday, November 21, 2022 at 5:31:27 PM

Re: #21978 include production-ready web server

At Florian's suggestion in another thread, I propose that we move further discussion of the settings refactor to the forum: https://forum.djangoproject.com/t/settings-refactor/17352 On Wednesday, November 2, 2022 at 2:58:29 PM UTC-4 f.apo...@gmail.com wrote: > The speckenv example highlights

Re: Integrate dj-database-url into Django

I started a forum thread on the settings refactor here: https://forum.djangoproject.com/t/settings-refactor/17352 Regarding the original topic of this thread ( https://code.djangoproject.com/ticket/28236), are we ready to close this as wontfix? I'm okay not proceeding with it (dj-database-url,

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

I'd personally like to see better support for safe / N-1 compatible migrations within Django itself, currently if you do CD / blue-green tower / etc. deployments you need to be very careful about the migration operations that you introduce version-to-version, although I'm not sure what that

Re: Potential way forward for DATABASE_URL

Alright, I'm writing up a review aid that tries to re-explain the actual changes in the PR I opened before. This document should go over all of the actual API changes that are exposed to users as well. I believe the API _is_ correct, and that future settings improvements could rely on these to

Re: Potential way forward for DATABASE_URL

Hey Raphael. My only query is as we sure the API is correct going forward? The answer could be yes there, but I didn't (as yet get to) review the history in depth. We **can** deprecate things, but we get an awful lot of complaints and pushback, even changes that are clearly for the good. I'd

Re: Integrate dj-database-url into Django

The thread that Carlton refers to is https://groups.google.com/g/django-developers/c/q20_Cxske88 -- don't be deterred by the title of it, it really talks about handling settings as well :) I kinda agree with James. I'd like to have a proper answer for handling settings rather then go setting

Re: Integrate dj-database-url into Django

This must be do-able now. There was some discussion of something along these lines a couple of years ago, with the idea of doing it for GSoC. There was much back-and-forth but no consensus. It has then come up again with Peter's suggestions about making it easier to get to a deployment ready

Re: Potential way forward for DATABASE_URL

(I'm very sorry about the threading going on here, I originally replied to the very old mailing thread and then realized it had not generated consensus, so am going to try and make this thread a more focused discussion regarding concensus) In the other thread people are discussing more

Re: Can we move the activity on this list to the Forum now?

IMO django-announce and django-updates serve a very different purpose and I would be against moving them if it were suggested. I am incredibly strongly in favour of moving django-developers and django-users to the forums. IMO being able to more easily trap people misusing this list as a tech

Re: Can we move the activity on this list to the Forum now?

Big +1 from me, I love the forum. It’s a lot more discoverable and powerful. On Mon, 28 Nov 2022 at 15:22, 'Tobias McNulty' via Django developers (Contributions to Django itself) wrote: > As someone who only just joined the forum -- I'm +1: > >- The forum has seen great adoption from what I

Re: rename internal SetPasswordForm.user into "instance" - or add it

I don’t think it’s worth adding support for “instance”. The name “instance” is used in generic mode view classes because they work with any kind of object. Since the password change view knows it has a user, it can use the more specific variable name. You can add an “instance” property in your

Re: Potential way forward for DATABASE_URL

I’m happy with this approach, it’s a little step forwards towards maintainable settings files. On Sun, 27 Nov 2022 at 20:37, 'Tobias McNulty' via Django developers (Contributions to Django itself) wrote: > Hi Raphael, > > Thanks for taking this on. > > Starting with a limited scope seems like a

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

I am not sure the db level defaults PR is suitable for a GSoC project at this point - it’s pretty well developed. I think it could do with some review and testing form those who are interested. On Mon, 28 Nov 2022 at 17:10, 'st...@jigsawtech.co.uk' via Django developers (Contributions to Django

Re: Technical Board vote on DEP 0012: The Steering Council

+1 from me And +1 to using the forum in future On Tue, 29 Nov 2022 at 00:23, charettes wrote: > +1 from me as well. > > Le lundi 28 novembre 2022 à 08:32:01 UTC-5, carlton...@gmail.com a écrit : > >> Hi All. >> >> Tom Forbes is currently unable to post to the Google Group here, due to >>

Re: Technical Board vote on DEP 0012: The Steering Council

+1 from me as well. Le lundi 28 novembre 2022 à 08:32:01 UTC-5, carlton...@gmail.com a écrit : > Hi All. > > Tom Forbes is currently unable to post to the Google Group here, due to > Currently Undiagnosed Google Account Weirdness™. > > For the record he's asked me to say that his vote is +1

Re: Integrate dj-database-url into Django

I recently did a bit of an audit of "settings types" whilst preparing for an overhaul of django-classy-settings. I found you could cover a majority of the common config types if you could somehow parse from an environ string the following (which closely aligns with django-environ): + str +

Re: Integrate dj-database-url into Django

It feels like this needs to be a broader conversation about not just changing DATABASES to accept a URL, or integrating a particular database-settings project, but to re-think how Django does settings-from-environment as a whole. When I'm setting up new Django-based projects, django-environ

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

On this vein I'd also like to see DB Cascades implemented https://code.djangoproject.com/ticket/21961 On Mon, 28 Nov 2022 at 18:10, 'st...@jigsawtech.co.uk' via Django developers (Contributions to Django itself) < django-developers@googlegroups.com> wrote: > +1 from me on DB defaults

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

+1 from me on DB defaults (constraints too). I've worked on many systems where Django isn't the only place putting records into DBs and having DB level defaults and constraints fixes a lot of common issues with that. Currently I create an empty migrations to then add them in manually when

Re: [Technical Board?] Project Ideas, and beginning GSoC 2023.

I'd like to see database-level defaults supported in models and migrations: https://code.djangoproject.com/ticket/470 There's currently a PR open, which replaces an earlier 2020 PR https://github.com/django/django/pull/16092 It would be a large benefit to those of us practicing continuous

Re: Async wrappers in contrib packages

Hey Carlton, There's: https://code.djangoproject.com/ticket/31949 "Allow builtin view > decorators to be applied directly to async views." > I think this is likely the next step. > > There's a PR for that, which I think took a too complex approach (see > discussion). A simpler (more inline) take

Re: Can we move the activity on this list to the Forum now?

As someone who only just joined the forum -- I'm +1: - The forum has seen great adoption from what I can tell (nearly half the number of posts as django-developers during the same time period, not bad given the mailing list's head start in subscribers). - It seems beneficial to house

Re: Can we move the activity on this list to the Forum now?

Hello, unfortunately, the emails sent by the forum have long prefixes in the subject lines, e.g. [Django Forum] [Django Internals/ORM] Multiple Database Switching That makes the messages easy to filter by mail client software, but comes at the cost of much visual clutter that is hard to

Re: Can we move the activity on this list to the Forum now?

Hey Roger, Indeed it does. You can set up Email Mode (that may not be the actual name) and it’ll work just like a mailing list. You can also subscribe to just a particular category, so the Internals one would map to the discussion on this list. On Monday, 28 November 2022, Roger Gammans

Re: Can we move the activity on this list to the Forum now?

Hi I can't speak for others, but I personally STRONGLY value the fact that this discussion happens in my inbox, not on yet another website. But perhaps the forum still supports this reading mode? On Mon, 2022-11-28 at 05:38 -0800, Carlton Gibson wrote: > Hi all. > Given the issues with Tom's

Can we move the activity on this list to the Forum now?

Hi all. Given the issues with Tom's access to the mailing list here, and the fact that the Forum has been active for a few years now, and is a great success, I'd like to revisit whether we can move on-mass (all few of us :) over there? We'd enjoy the benefits of a much nicer system. We'd

Re: Technical Board vote on DEP 0012: The Steering Council

Hi All. Tom Forbes is currently unable to post to the Google Group here, due to Currently Undiagnosed Google Account Weirdness™. For the record he's asked me to say that his vote is +1 in support of the change, but I feel we should probably move voting to the forum because of this. Kind

Re: Integrate dj-database-url into Django

Hey Tobias. > Could you (or others) provide some examples of the needs this solution doesn't address (not necessarily complete, just to give an idea)? I hadn't seen the other thread this morning when replying to this one. It looks like some of the issues are indeed addressed *but *I was only

Re: Integrate dj-database-url into Django

Hi Carlton, Responses inline below: On Mon, Nov 28, 2022, 2:40 AM Carlton Gibson wrote: > Hi Raphael, thanks for picking this up. > > Looking at the history here, particularly the discussion here > https://groups.google.com/g/django-developers/c/UQjpzB39JN0/m/XGqdV8nbBwAJ > but there are

<    2   3   4   5   6   7   8   9   10   11   >