Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend
Hi! I would be happy to make a contribution if a decision can be reached. I'm in favor of making the Group model swappable with the AUTH_GROUP_MODEL setting, similar to the User model. The ticket was marked as Someday/Maybe, I'm not sure why. The customization of the Group model is necessary in any bigger project, and defining a secondary model doesn't always cut it (e.g. when nesting the Group model). AUTH_GROUP_MODEL is consistent with the User model and addresses all customization concerns. Yes, it's hard to swap the User model in production, and it will be hard to swap the Group model. It's still better than hacking around Django (see: https://stackoverflow.com/questions/2181039/how-do-i-extend-the-django-group-model). I opened a PR <https://github.com/django/django/pull/18053> to add this, it addresses the basic functionality. Let me know! On Friday 24 January 2020 at 16:57:17 UTC+8 Adam Johnson wrote: > Exactly as you see, nothing is done in secret. > > On Fri, 24 Jan 2020 at 08:44, LBris wrote: > >> Hi everyone. >> >> >> What is the state of this discussion and its attached ticket ? >> >> -- >> > 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-develop...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/47517107-c5d2-4986-8845-087cba05e340%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/47517107-c5d2-4986-8845-087cba05e340%40googlegroups.com?utm_medium=email_source=footer> >> . >> > > > -- > 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/103b9150-54b5-4cd4-b27b-1fd6db7e5f5en%40googlegroups.com.
Django bugfix release issued: 5.0.4
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2024/apr/03/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 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/CA%2BfOnFaCFdiy_ZQoP%3DOq2imzJr%2BgwmR5Ptfcqs0eTufjiztCfQ%40mail.gmail.com.
Re: Should Django use Ada?
Thanks for the replies everybody. A few thoughts >From Adrián: > You should probably be addressing urllib devs with this inquiry (e.g. such vuln is then probably in many other web frameworks) I did that in 2021 when I found the issue with newlines in URLs. Python devs had the resources to fix the newlines but not to make urlparse spec/browser compliant. They had concerns about backwards compatibility (fair enough), and it seemed like they'd have to largely rewrite the library to do things properly b/c URLs are so nasty these days. I think they also felt like they couldn't keep up with the standard and that the language shouldn't try. Instead, they argued the usual thing: folks should use third party libraries that can be better and that can change more quickly (fair enough). Until Ada, I hadn't heard of better solutions, so I let it lay. >From Jorg: > the fact that django or an upstream lib decided to slightly deviate from the latest URL parsing spec incarnation does not make it vulnerable per se >From Adam: > On the contradictory standards, see the cURL maintainer’s post I agree, Jorg, and thanks for the cURL reference, Adam. Specs aren't my target so much as "what browsers do," and wherever our URL parser diverges from what browsers do, we risk a redirect vulnerability. It's been a few years since I worked on this issue, but IIRC, this particular spec is actually well aligned with what browsers do, so they're essentially one and the same. I understand the push back that we need proof of an issue here before we'd move forward with anything. WHATHG provides a test suite of nasty URLs <https://github.com/web-platform-tests/wpt/tree/master/url>. I guess what I should do is run that through urlparse and look for places where it fails. If, for example, it's possible to send a valid URL to urlparse and have it get the wrong (sub)domain name, we would consider that a vulnerability or at least an issue, right? - That's it for my substantive comments, but I want to reply to this too: > But then add something about their time being too valuable to work on making it better. I don't know C, so I can't help much with the Python language, but I am here, where I have more expertise. You'll note that I offered to assign a paid developer to adding Ada to Django if we wanted to. That's me being busy with other priorities, but offering resources from my org. If that's not good enough, I don't know what is. Also, I'm not denigrating Python by saying it's maintained by volunteers — in my experience, it is. The fact that Python doesn't have tons of resources is one of the reasons it was difficult to get this vulnerability fixed in the language itself. They did a minimal fix because a bigger one wasn't possible given the resources of those that work on the language (and concerns about backwards compat). Finally, you might also consider that I spent a lot of my time working on the vulnerability above, and that I contribute to other open source projects practically every day for the last decade. Point being: If you want to drive me away from contributing here, you're on your way, but I'm here trying to help, and I've got a record of doing so here and elsewhere in various ways. Sorry to others here for the off topic response. Though I probably should, I can't let that kind of comment go in the Django discussion group. Thank you all, Mike -- 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/3f95d432-67ad-45bc-aec1-063e9b762ac7n%40googlegroups.com.
Re: Should Django use Ada?
I agree with Jörg. We need evidence of problems before we decide to act, and that those problems aren’t being addressed in Python. Forcing a new dependency on all users is not something we’d do lightly. On the contradictory standards, see the cURL maintainer’s post: https://daniel.haxx.se/blog/2022/10/18/deviating-from-specs/ . > Anyhow, just out of curiosity, wouldn't it be possible to use > functools.partial function to replace urllib.parse.urlparse with ada-python > in settings.py? Or make some kind of django extension that integrates this > other dependency? It should always be possible to create and use custom classes that use ada, such as an alternative URL field. On Mon, 1 Apr 2024, at 23:45, Jörg Breitbart wrote: > You write: > > "It could still be a vulnerability ... / It could fail to parse ... / > could decide it's invalid - This is all pretty bad..." > > I agree - this indeed would be really bad, if it can be used in > malicious ways. But note that the fact that django or an upstream lib > decided to slightly deviate from the latest URL parsing spec incarnation > does not make it vulnerable per se. URL specs (or URI in general) used > to contradict itself across various RFCs, so there is some ground of > interpretation and which rules to follow in an implementation. Also > django has to maintain backwards compat to some degree, and introducing > a foreign c++ lib binding in its default installation is a very bold move. > > Anything into this direction needs proper justification and not just > handwaving arguments (FUD?), unless there actually is a real > vulnerability with the current impl. > > Cheers, > Jörg > > -- > 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 > <mailto:django-developers%2bunsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/726fce28-2273-4672-8e00-f8619b95b0d9%40netzkolchose.de. > -- 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/d97f33e2-5ac5-4ee5-8850-8b8cda3dc8b0%40app.fastmail.com.
Re: Should Django use Ada?
You should probably be addressing urllib devs with this inquiry (e.g. such vuln is then probably in many other web frameworks). Anyhow, just out of curiosity, wouldn't it be possible to use functools.partial function to replace urllib.parse.urlparse with ada-python in settings.py? Or make some kind of django extension that integrates this other dependency? On Mon, Apr 1, 2024 at 10:37 PM 'Michael Lissner' via Django developers (Contributions to Django itself) wrote: > Hi all, > > A few years ago, I reported a vulnerability in Django because Python > wasn't parsing URLs containing tabs or newlines correctly. In this ticket, > it was fixed in Python: > > https://bugs.python.org/issue43882 > > But Python, being maintained mostly by volunteers, did the minimum needed > work to fix the vulnerability without really fixing the urlparse library > properly. > > This means that it's probably still possible to send a URL to django that > urlparse doesn't know how to handle. When this happens: > > 1. It could still be a vulnerability.* If this is the case, Django could > redirect people to domains where it shouldn't. > > 2. It could fail to parse the URL properly, leading to the wrong URL being > provided to the user. > > 3. urlparse could decide it's an invalid URL even though it's not. > > This is all pretty bad, but there is some hope in the form of a tool > called Ada, which aims to actually support URL parsing properly: > > Homepage: https://www.ada-url.com/ > Github (more useful, really): https://github.com/ada-url/ada > > It's written in C++, is used in Node and Cloudflare Workers. It has > bindings for Python, Rust, R, and Go. It's licensed under MIT and Apache > License 2.0. It's fuzzed by Google OSS Fuzzer, and it's much faster than > urlparse. > > I'm curious: Would Django consider switching to this library? I'm not sure > if I'll have time to do the work, but I can at least open an issue if it's > a useful switch to make, and I might be able to assign a developer to it if > this is something we want. > > Love to hear thoughts, > > Mike > > > * I'm posting this publicly because this kind of vulnerability is really > well known these days, and exists across most general-purpose languages. > URLs are just very difficult to parse properly. > > -- > 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/f31bc17b-c0c5-4ce4--7d1ec3dfe90bn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/f31bc17b-c0c5-4ce4--7d1ec3dfe90bn%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CABKWZPkFZFnxSLfxVZT_%2B69Yfyem4ZALK-s7HOtUGXs5%2Bs7J4w%40mail.gmail.com.
Re: Should Django use Ada?
You write: "It could still be a vulnerability ... / It could fail to parse ... / could decide it's invalid - This is all pretty bad..." I agree - this indeed would be really bad, if it can be used in malicious ways. But note that the fact that django or an upstream lib decided to slightly deviate from the latest URL parsing spec incarnation does not make it vulnerable per se. URL specs (or URI in general) used to contradict itself across various RFCs, so there is some ground of interpretation and which rules to follow in an implementation. Also django has to maintain backwards compat to some degree, and introducing a foreign c++ lib binding in its default installation is a very bold move. Anything into this direction needs proper justification and not just handwaving arguments (FUD?), unless there actually is a real vulnerability with the current impl. Cheers, Jörg -- 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/726fce28-2273-4672-8e00-f8619b95b0d9%40netzkolchose.de.
Re: Should Django use Ada?
I always wonder why people feel the need to belittle others' work with statements like " But Python, being maintained mostly by volunteers, did the minimum needed work to fix the vulnerability without really fixing the urlparse library properly." But then add something about their time being too valuable to work on making it better. Dylan On Mon, Apr 1, 2024 at 1:37 PM 'Michael Lissner' via Django developers (Contributions to Django itself) wrote: > Hi all, > > A few years ago, I reported a vulnerability in Django because Python > wasn't parsing URLs containing tabs or newlines correctly. In this ticket, > it was fixed in Python: > > https://bugs.python.org/issue43882 > > But Python, being maintained mostly by volunteers, did the minimum needed > work to fix the vulnerability without really fixing the urlparse library > properly. > > This means that it's probably still possible to send a URL to django that > urlparse doesn't know how to handle. When this happens: > > 1. It could still be a vulnerability.* If this is the case, Django could > redirect people to domains where it shouldn't. > > 2. It could fail to parse the URL properly, leading to the wrong URL being > provided to the user. > > 3. urlparse could decide it's an invalid URL even though it's not. > > This is all pretty bad, but there is some hope in the form of a tool > called Ada, which aims to actually support URL parsing properly: > > Homepage: https://www.ada-url.com/ > Github (more useful, really): https://github.com/ada-url/ada > > It's written in C++, is used in Node and Cloudflare Workers. It has > bindings for Python, Rust, R, and Go. It's licensed under MIT and Apache > License 2.0. It's fuzzed by Google OSS Fuzzer, and it's much faster than > urlparse. > > I'm curious: Would Django consider switching to this library? I'm not sure > if I'll have time to do the work, but I can at least open an issue if it's > a useful switch to make, and I might be able to assign a developer to it if > this is something we want. > > Love to hear thoughts, > > Mike > > > * I'm posting this publicly because this kind of vulnerability is really > well known these days, and exists across most general-purpose languages. > URLs are just very difficult to parse properly. > > -- > 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/f31bc17b-c0c5-4ce4--7d1ec3dfe90bn%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/f31bc17b-c0c5-4ce4-9999-7d1ec3dfe90bn%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CAHtg44DJfVrF4ZmUQLVaJyGTCcb%2BcQ4rJZr0%3DV39_f-PwVDTxg%40mail.gmail.com.
Should Django use Ada?
Hi all, A few years ago, I reported a vulnerability in Django because Python wasn't parsing URLs containing tabs or newlines correctly. In this ticket, it was fixed in Python: https://bugs.python.org/issue43882 But Python, being maintained mostly by volunteers, did the minimum needed work to fix the vulnerability without really fixing the urlparse library properly. This means that it's probably still possible to send a URL to django that urlparse doesn't know how to handle. When this happens: 1. It could still be a vulnerability.* If this is the case, Django could redirect people to domains where it shouldn't. 2. It could fail to parse the URL properly, leading to the wrong URL being provided to the user. 3. urlparse could decide it's an invalid URL even though it's not. This is all pretty bad, but there is some hope in the form of a tool called Ada, which aims to actually support URL parsing properly: Homepage: https://www.ada-url.com/ Github (more useful, really): https://github.com/ada-url/ada It's written in C++, is used in Node and Cloudflare Workers. It has bindings for Python, Rust, R, and Go. It's licensed under MIT and Apache License 2.0. It's fuzzed by Google OSS Fuzzer, and it's much faster than urlparse. I'm curious: Would Django consider switching to this library? I'm not sure if I'll have time to do the work, but I can at least open an issue if it's a useful switch to make, and I might be able to assign a developer to it if this is something we want. Love to hear thoughts, Mike * I'm posting this publicly because this kind of vulnerability is really well known these days, and exists across most general-purpose languages. URLs are just very difficult to parse properly. -- 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/f31bc17b-c0c5-4ce4--7d1ec3dfe90bn%40googlegroups.com.
Django security releases issued: 5.0.3, 4.2.11, and 3.2.25
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2024/mar/04/security-releases/ -- 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/3c24bf94-c80b-4cd0-821b-97b738cfb93b%40gmail.com.
Re: Proposal for SyncChatRoom Integration in Django
That sounds great, I will keep you updated for any technologies to use or have you have any technical issues also keep me updated On Sun, Feb 18, 2024, 03:08 David Ansa wrote: > Hi Fawemimo Owolabi, > > Thank you for your support and feedback! I appreciate your suggestion to > use SyncChatRoom as a third-party package, and I'm considering extending it > to integrate with Django REST Framework as well. > > I'll keep the community updated on the progress, and feel free to share > any further thoughts or ideas you may have. > > Best regards, > David Ansa > > On Friday, February 16, 2024 at 5:52:53 PM UTC+1 Fawemimo Owolabi wrote: > >> I really support these motions, it really sound great but it will be best >> to used as a third-party package, also for drf as well >> >> On Tuesday, February 13, 2024 at 11:21:02 PM UTC+1 Adam Johnson wrote: >> >>> Hi David >>> >>> SyncChatRoom sounds more like something that Django would help users >>> build, rather than include in the framework. If it’s somewhat reusable >>> between projects, it would be best be published as a third-party package. >>> >>> Thanks, >>> >>> Adam >>> >>> On Tue, Feb 13, 2024, at 8:57 PM, David Ansa wrote: >>> >>> Hi Everyone, >>> >>> I'm excited to propose the integration of SyncChatRoom, a real-time chat >>> functionality, into the Django framework. SyncChatRoom aims to provide >>> native support for WebSocket communication, making it easier for developers >>> to implement real-time chat features in their Django applications. >>> >>> >>> *Proposal Summary:* >>> >>>- Feature Name: SyncChatRoom >>>- Purpose: Enable Django developers to seamlessly integrate >>>real-time chat functionality, enhancing user engagement and >>> collaboration. >>>- Implementation: Utilize Django Channels for WebSocket support and >>>provide a set of APIs and components for real-time communication. >>> >>> *Use Cases:* >>> >>>- Live chat applications >>>- Collaborative editing platforms >>>- Real-time notifications >>> >>> *Why SyncChatRoom?* >>> >>> Real-time communication is crucial for modern web applications. >>> SyncChatRoom aligns with Django's commitment to staying relevant and >>> user-friendly. >>> >>> *Technical Details:* >>> >>>- SyncChatRoom will leverage Django Channels for WebSocket support. >>> - Detailed technical specifications and design considerations will >>>be discussed during the development process. >>> >>> >>> *Potential Benefits:* >>> >>>- Easier integration of real-time features in Django projects. >>>- Consistent and standardized implementation across the Django >>>ecosystem. >>> >>> >>> I'm thrilled about the potential of SyncChatRoom and look forward to >>> hearing your thoughts and suggestions. Let's discuss how we can make Django >>> even more powerful in the realm of real-time communication! >>> >>> >>> -- >>> 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-develop...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> >>> >>> -- > 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/1506f3ca-325b-4355-bd98-ed5374e43ff5n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/1506f3ca-325b-4355-bd98-ed5374e43ff5n%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CANfEbGJ%2BaKLEfPw2DMGj6Lra1Fm9zs0s3bAq2wMxifzymAyqAA%40mail.gmail.com.
Re: Proposal for SyncChatRoom Integration in Django
Hi Fawemimo Owolabi, Thank you for your support and feedback! I appreciate your suggestion to use SyncChatRoom as a third-party package, and I'm considering extending it to integrate with Django REST Framework as well. I'll keep the community updated on the progress, and feel free to share any further thoughts or ideas you may have. Best regards, David Ansa On Friday, February 16, 2024 at 5:52:53 PM UTC+1 Fawemimo Owolabi wrote: > I really support these motions, it really sound great but it will be best > to used as a third-party package, also for drf as well > > On Tuesday, February 13, 2024 at 11:21:02 PM UTC+1 Adam Johnson wrote: > >> Hi David >> >> SyncChatRoom sounds more like something that Django would help users >> build, rather than include in the framework. If it’s somewhat reusable >> between projects, it would be best be published as a third-party package. >> >> Thanks, >> >> Adam >> >> On Tue, Feb 13, 2024, at 8:57 PM, David Ansa wrote: >> >> Hi Everyone, >> >> I'm excited to propose the integration of SyncChatRoom, a real-time chat >> functionality, into the Django framework. SyncChatRoom aims to provide >> native support for WebSocket communication, making it easier for developers >> to implement real-time chat features in their Django applications. >> >> >> *Proposal Summary:* >> >>- Feature Name: SyncChatRoom >>- Purpose: Enable Django developers to seamlessly integrate real-time >>chat functionality, enhancing user engagement and collaboration. >>- Implementation: Utilize Django Channels for WebSocket support and >>provide a set of APIs and components for real-time communication. >> >> *Use Cases:* >> >>- Live chat applications >>- Collaborative editing platforms >>- Real-time notifications >> >> *Why SyncChatRoom?* >> >> Real-time communication is crucial for modern web applications. >> SyncChatRoom aligns with Django's commitment to staying relevant and >> user-friendly. >> >> *Technical Details:* >> >>- SyncChatRoom will leverage Django Channels for WebSocket support. >>- Detailed technical specifications and design considerations will be >>discussed during the development process. >> >> >> *Potential Benefits:* >> >>- Easier integration of real-time features in Django projects. >>- Consistent and standardized implementation across the Django >>ecosystem. >> >> >> I'm thrilled about the potential of SyncChatRoom and look forward to >> hearing your thoughts and suggestions. Let's discuss how we can make Django >> even more powerful in the realm of real-time communication! >> >> >> -- >> 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-develop...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%40googlegroups.com?utm_medium=email_source=footer> >> . >> >> >> -- 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/1506f3ca-325b-4355-bd98-ed5374e43ff5n%40googlegroups.com.
Re: Proposal for SyncChatRoom Integration in Django
I really support these motions, it really sound great but it will be best to used as a third-party package, also for drf as well On Tuesday, February 13, 2024 at 11:21:02 PM UTC+1 Adam Johnson wrote: > Hi David > > SyncChatRoom sounds more like something that Django would help users > build, rather than include in the framework. If it’s somewhat reusable > between projects, it would be best be published as a third-party package. > > Thanks, > > Adam > > On Tue, Feb 13, 2024, at 8:57 PM, David Ansa wrote: > > Hi Everyone, > > I'm excited to propose the integration of SyncChatRoom, a real-time chat > functionality, into the Django framework. SyncChatRoom aims to provide > native support for WebSocket communication, making it easier for developers > to implement real-time chat features in their Django applications. > > > *Proposal Summary:* > >- Feature Name: SyncChatRoom >- Purpose: Enable Django developers to seamlessly integrate real-time >chat functionality, enhancing user engagement and collaboration. >- Implementation: Utilize Django Channels for WebSocket support and >provide a set of APIs and components for real-time communication. > > *Use Cases:* > >- Live chat applications >- Collaborative editing platforms >- Real-time notifications > > *Why SyncChatRoom?* > > Real-time communication is crucial for modern web applications. > SyncChatRoom aligns with Django's commitment to staying relevant and > user-friendly. > > *Technical Details:* > >- SyncChatRoom will leverage Django Channels for WebSocket support. >- Detailed technical specifications and design considerations will be > discussed during the development process. > > > *Potential Benefits:* > >- Easier integration of real-time features in Django projects. >- Consistent and standardized implementation across the Django >ecosystem. > > > I'm thrilled about the potential of SyncChatRoom and look forward to > hearing your thoughts and suggestions. Let's discuss how we can make Django > even more powerful in the realm of real-time communication! > > > -- > 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-develop...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%40googlegroups.com?utm_medium=email_source=footer> > . > > > -- 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/0fbad1ca-62fc-4273-8ea4-5e0a8151d4b9n%40googlegroups.com.
Re: Proposal for SyncChatRoom Integration in Django
Hi David SyncChatRoom sounds more like something that Django would help users build, rather than include in the framework. If it’s somewhat reusable between projects, it would be best be published as a third-party package. Thanks, Adam On Tue, Feb 13, 2024, at 8:57 PM, David Ansa wrote: > Hi Everyone, > > I'm excited to propose the integration of SyncChatRoom, a real-time chat > functionality, into the Django framework. SyncChatRoom aims to provide native > support for WebSocket communication, making it easier for developers to > implement real-time chat features in their Django applications. > > *Proposal Summary: * > • Feature Name: SyncChatRoom > • Purpose: Enable Django developers to seamlessly integrate real-time chat > functionality, enhancing user engagement and collaboration. > • Implementation: Utilize Django Channels for WebSocket support and provide > a set of APIs and components for real-time communication. > *Use Cases:* > • Live chat applications > • Collaborative editing platforms > • Real-time notifications > *Why SyncChatRoom?* > > Real-time communication is crucial for modern web applications. > SyncChatRoom aligns with Django's commitment to staying relevant and > user-friendly. > > *Technical Details:* > • SyncChatRoom will leverage Django Channels for WebSocket support. > • Detailed technical specifications and design considerations will be > discussed during the development process. > > *Potential Benefits:* > • Easier integration of real-time features in Django projects. > • Consistent and standardized implementation across the Django ecosystem. > > I'm thrilled about the potential of SyncChatRoom and look forward to hearing > your thoughts and suggestions. Let's discuss how we can make Django even more > powerful in the realm of real-time communication! > > > -- > 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/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%40googlegroups.com?utm_medium=email_source=footer>. -- 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/ad3ce392-0ccf-4343-b2f2-1135c1ae91a9%40app.fastmail.com.
Proposal for SyncChatRoom Integration in Django
Hi Everyone, I'm excited to propose the integration of SyncChatRoom, a real-time chat functionality, into the Django framework. SyncChatRoom aims to provide native support for WebSocket communication, making it easier for developers to implement real-time chat features in their Django applications. *Proposal Summary:* - Feature Name: SyncChatRoom - Purpose: Enable Django developers to seamlessly integrate real-time chat functionality, enhancing user engagement and collaboration. - Implementation: Utilize Django Channels for WebSocket support and provide a set of APIs and components for real-time communication. *Use Cases:* - Live chat applications - Collaborative editing platforms - Real-time notifications *Why SyncChatRoom?* Real-time communication is crucial for modern web applications. SyncChatRoom aligns with Django's commitment to staying relevant and user-friendly. *Technical Details:* - SyncChatRoom will leverage Django Channels for WebSocket support. - Detailed technical specifications and design considerations will be discussed during the development process. *Potential Benefits:* - Easier integration of real-time features in Django projects. - Consistent and standardized implementation across the Django ecosystem. I'm thrilled about the potential of SyncChatRoom and look forward to hearing your thoughts and suggestions. Let's discuss how we can make Django even more powerful in the realm of real-time communication! -- 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/a97b01fb-b0ed-42ea-ae8b-08e1e8ee89a3n%40googlegroups.com.
Django security releases issued: 5.0.2, 4.2.10, and 3.2.24
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2024/feb/06/security-releases/ -- 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/CA%2BfOnFZadFAC4gNiD3tdkKkL4ktsnwAAdfQ2dFDgq26T%3DLbUhw%40mail.gmail.com.
Django project website UX: call for help!
Hello everyone, at 20tab we just finished collaborating with the Django Software Foundation to improve the Django project website's accessibility and usability. We now need you to help us understand how involved people are in the Django project and how much they care for good UX. Fill out this very short form and let us know! https://t.co/cWiMc6SJPB Thank you to all of you who will take the time to respond - your input is of immense value to us. Feel free to raise any questions here. -- 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/76615d60-853a-45a7-b4a6-b75f85d808b5n%40googlegroups.com.
Re: Possible async view regression in django 5.0?
Hello Hugo, thanks for this email. Just for completeness sake and for future readers, I'm leaving a note here that a ticket was created for this issue ( https://code.djangoproject.com/ticket/35148) which was closed as a duplicate of https://code.djangoproject.com/ticket/35059. On Sun, Jan 28, 2024 at 9:23 PM Hugo Heyman wrote: > Hello! > > I've been troubleshooting an issue with lingering idle db connections > (postgres) since upgrading from django 4.2 to 5.0. The issue manifested by > db raising OperationalError FATAL: sorry, too many clients already not long > after deploying the new version. We're running asgi with uvicorn + gunicorn. > > After extensive troubleshooting I installed django from a local repo and > ran a git bisect to pin down the commit where this first occurred and ended > up on this commit > https://github.com/django/django/commit/64cea1e48f285ea2162c669208d95188b32bbc82 > > Since I've recently built something quite async heavy I decided to dig > into how the ASGIHandler code works and see if I can understand it and > possibly make a fix if there really is some issue there. > > Now for the possible regression with django: > > The change introduced in Django 5.0 to allow handling of > asyncio.CancelledError in views seems to also allow async views with normal > HttpResponse handling client disconnects. As a consequence though the > request_finished signal may not run leading to db connection not being > closed. > > What currently seems to be happening in ASGIHandler in > django/core/handlers/asgi.py goes something like this: > > 1. Concurrent tasks are started for > - disconnect listener (listen for "http.disconnect" from webserver) > - process_request > 2. If disconnect happens first (e.g. browser refresh) cancel() is run on > process_request task and request_finished may not have been triggered > 3. db connection for the request is not closed :( > > Here are the lines of code where all this happens, marked: > https://github.com/django/django/blob/9c6d7b4a678b7bbc6a1a14420f686162ba9016f5/django/core/handlers/asgi.py#L191-L232 > > Possible fix? I'm thinking only views that return a HTTPStreamingResponse > would need to allow for cancellation cleanup handling via the view. If so > response = await self.run_get_response(request) could run before and > outside of any task so we could check response.streaming attribute and only > run listen_for_disconnect task when there's a streaming response. > > I've made a patch to try the above out and it seems to fix the issues. > https://github.com/HeyHugo/django/commit/e25a1525654e00dcd5b483689ef16e0dc74d32d1 > > Here's a minimal setup to demonstrate the issue via print debugging: > https://github.com/HeyHugo/django_async_issue > > (I have never found a real bug in django so I'm still having doubts :D) > > Best regards > /Hugo > > -- > 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/4c7a761b-1420-4997-900f-b8f0d59f4f31n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/4c7a761b-1420-4997-900f-b8f0d59f4f31n%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CA%2BfOnFY0-3GEhi2k%3DLzL9AiD8acRuCTMKPR62fgyPMnrN%2B803g%40mail.gmail.com.
Possible async view regression in django 5.0?
Hello! I've been troubleshooting an issue with lingering idle db connections (postgres) since upgrading from django 4.2 to 5.0. The issue manifested by db raising OperationalError FATAL: sorry, too many clients already not long after deploying the new version. We're running asgi with uvicorn + gunicorn. After extensive troubleshooting I installed django from a local repo and ran a git bisect to pin down the commit where this first occurred and ended up on this commit https://github.com/django/django/commit/64cea1e48f285ea2162c669208d95188b32bbc82 Since I've recently built something quite async heavy I decided to dig into how the ASGIHandler code works and see if I can understand it and possibly make a fix if there really is some issue there. Now for the possible regression with django: The change introduced in Django 5.0 to allow handling of asyncio.CancelledError in views seems to also allow async views with normal HttpResponse handling client disconnects. As a consequence though the request_finished signal may not run leading to db connection not being closed. What currently seems to be happening in ASGIHandler in django/core/handlers/asgi.py goes something like this: 1. Concurrent tasks are started for - disconnect listener (listen for "http.disconnect" from webserver) - process_request 2. If disconnect happens first (e.g. browser refresh) cancel() is run on process_request task and request_finished may not have been triggered 3. db connection for the request is not closed :( Here are the lines of code where all this happens, marked: https://github.com/django/django/blob/9c6d7b4a678b7bbc6a1a14420f686162ba9016f5/django/core/handlers/asgi.py#L191-L232 Possible fix? I'm thinking only views that return a HTTPStreamingResponse would need to allow for cancellation cleanup handling via the view. If so response = await self.run_get_response(request) could run before and outside of any task so we could check response.streaming attribute and only run listen_for_disconnect task when there's a streaming response. I've made a patch to try the above out and it seems to fix the issues. https://github.com/HeyHugo/django/commit/e25a1525654e00dcd5b483689ef16e0dc74d32d1 Here's a minimal setup to demonstrate the issue via print debugging: https://github.com/HeyHugo/django_async_issue (I have never found a real bug in django so I'm still having doubts :D) Best regards /Hugo -- 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/4c7a761b-1420-4997-900f-b8f0d59f4f31n%40googlegroups.com.
Django bugfix releases issued: 4.2.9 and 5.0.1
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2024/jan/02/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 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/546916ac-cf8b-4689-9401-2ba31c084844%40gmail.com.
Django 5.0 released
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/dec/04/django-50-released/ -- 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/CA%2BfOnFb5dYHD8toWYMndRe%3DbU4Wc5FyOgb%3DaU3wMG0Oc333V-w%40mail.gmail.com.
Django bugfix release: 4.2.8
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/dec/04/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 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/ab2ae413-2766-4694-be86-ff768272d052%40gmail.com.
Django 5.0 release candidate 1 released
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/nov/20/django-50-rc1/ -- 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/CA%2BfOnFY3u1Tor%3Dj6dAQyzdJNdCZwhsb%2BqDzpqwG2qKgohPwxfQ%40mail.gmail.com.
Re: How do you set the python path for django-admin?
Hi tobias. The django-admin command has a `--pythonpath` option for this (docs <https://docs.djangoproject.com/en/4.2/ref/django-admin/#cmdoption-pythonpath> ). So, for example in a 3rd party package using the src layout (example <https://github.com/carltongibson/neapolitan>) where the module itself is installed in the venv, but the tests module is at the package root, you can run the tests like: django-admin test --settings=tests.settings --pythonpath=. HTH. Kind Regards, Carlton On Wed, 8 Nov 2023 at 20:18, Tobias Bengfort wrote: > Hi everyone, > > https://docs.djangoproject.com/en/4.2/ref/django-admin/ claims that > manage.py, django-admin and python -m django are practically > interchangable. However, I noticed that they behave differently when it > comes to the python path (the path you can import modules from). I used > `CMD shell -c 'import sys; print(sys.path[0])' to check each one: > > - `manage.py` adds its own location to the python path. That is fine > because `django-admin startproject` puts it right next to the project > directory. > > - `django-admin` also adds its own location to the python path. That is > less fine because that is usualy something like /some/venv/bin/, so the > project package is not importable. Simply running `django-admin > runserver --settings=example.settings` fails with `ModuleNotFoundError: > No module named 'example'`. > > - `python -m django` uses the current directory, which is slightly less > useful than manage.py, but quite intuitive. > > Of course you can circumvent all of this by setting PYTHONPATH explicitly. > > I personally was burned by this because I use `pip install -e` to add > the folder containing the project directory to the python path. However, > when switching to PEP 517 based packaging, the behavior changed and some > modules could no longer be imported. > > is there any official recommendation about this? My impression was > always that manage.py is meant for development and django-admin is meant > for production. But how are you supposed to set the python path in that > case? Is this assumption even correct? I could not find anything about > it in the docs. > > In any case, I think the docs need an update because currently, all > examples use `django-admin`, which does not work out of the box in my > experience. > > thanks, > tobias > > -- > 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/2b27a633-f658-4fe8-ab41-d553890b03c6%40posteo.de > . > -- 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/CAJwKpyT2onzVkQ3MdGQR83uPxs_7GG5Zb%2BsZtzwy7gR1-6-aHA%40mail.gmail.com.
How do you set the python path for django-admin?
Hi everyone, https://docs.djangoproject.com/en/4.2/ref/django-admin/ claims that manage.py, django-admin and python -m django are practically interchangable. However, I noticed that they behave differently when it comes to the python path (the path you can import modules from). I used `CMD shell -c 'import sys; print(sys.path[0])' to check each one: - `manage.py` adds its own location to the python path. That is fine because `django-admin startproject` puts it right next to the project directory. - `django-admin` also adds its own location to the python path. That is less fine because that is usualy something like /some/venv/bin/, so the project package is not importable. Simply running `django-admin runserver --settings=example.settings` fails with `ModuleNotFoundError: No module named 'example'`. - `python -m django` uses the current directory, which is slightly less useful than manage.py, but quite intuitive. Of course you can circumvent all of this by setting PYTHONPATH explicitly. I personally was burned by this because I use `pip install -e` to add the folder containing the project directory to the python path. However, when switching to PEP 517 based packaging, the behavior changed and some modules could no longer be imported. is there any official recommendation about this? My impression was always that manage.py is meant for development and django-admin is meant for production. But how are you supposed to set the python path in that case? Is this assumption even correct? I could not find anything about it in the docs. In any case, I think the docs need an update because currently, all examples use `django-admin`, which does not work out of the box in my experience. thanks, tobias -- 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/2b27a633-f658-4fe8-ab41-d553890b03c6%40posteo.de.
Re: Wrong ordering of many-to-many fields with explicit intermediary model in Django admin
Hi Alan, This is a known issue, you can find a discussion in https://code.djangoproject.com/ticket/12203. It's an accepted ticket so feel-free to work on it. Best, Mariusz -- 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/c8dcce28-3f24-42a3-b069-cb6a026bea31n%40googlegroups.com.
Wrong ordering of many-to-many fields with explicit intermediary model in Django admin
Hi, all. I was not sure if this question was better suited to the users or developers mailing list and posted in both. Feel free to delete one of them if you see fit. I have a Submission model with a many-to-many relationship with a Market model and explicitly defined a SubmissionMarket model as intermediary model. I have defined Submission inlines in a ModelAdmin class (used by Django admin) and defined the markets field as the first one in the fields attribute of a form associated with that submission inline. However, that field is being shown by last (at the end of the inline row). Debugging, I found out that: - django.forms.models.fields_for_model() creates a dict of form fields for a Django model. That function is used during the construction of any form. - a form field defined in the Form.Meta.fields is ignored in fields_for_model() if formfield_callback is passed as argument and if that callable returns None - django.forms.models.ModelFormMetaclass passes BaseModelAdmin.formfield_for_dbfield as formfield_callback arg in fields_for_model() - This formfield_for_dbfield() method ends up calling formfield_for_manytomany() if the field is m2m. The latter method returns None if the intermediary model was not created automatically by Django, which causes the field to be ignored. This is the code that does it in django/contrib/admin/options.py: # If it uses an intermediary model that isn't auto created, don't show # a field in admin. if not db_field.remote_field.through._meta.auto_created: return None - Later, the markets field is added at the end of the form, I haven't investigated why. My question is: what's the motivation of ignoring the m2m field if the intermediary model is not auto created? Could this behavior be customized? Thanks in advance! Regards, Alan -- 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/d8db85d2-91ca-4779-8316-638ebc1f07dan%40googlegroups.com.
Django security releases issued: 4.2.7, 4.1.13, and 3.2.23
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/nov/01/security-releases/ -- 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/328c78c5-f91a-4240-b018-cc55c230a53d%40gmail.com.
Re: Potential bug with how Value works with Django ORM queries
Hi David,
Thanks for response. I understand it now. I was assuming that Value auto
typecasts to the field that we are querying. This makes sense.
Thank you for taking time to respond.
Cheers
Nitin
On Thursday, October 26, 2023 at 3:52:17 AM UTC-4 David Sanders wrote:
> Hi Nitin,
>
> Not sure what db you're using but will explain assuming PG.
>
> In this particular example, Django uses the `->` operator which requires
> that we compare jsonb types. The `__in=("Program1", "Program2")` is
> converted to jsonb via `DatabaseOperations.adapt_json_value()` where as
> `Value()` isn't.
>
> `Value()` assumes the type of the argument passed in – in this case `str`
> – unless you pass a second argument, `output_field`. Specifying
> `output_field=JSONField()` will cause the ORM to pass these values to
> `DatabaseOperations.adapt_json_value()`.
>
> So this will work:
>
> `Study.objects.filter(study_data__protocol__general__program_name__in=(Value("Program1",
>
> output_field=JSONField()), ...))`
>
> Regards
> David
>
> On Thursday, 26 October 2023 at 03:39:08 UTC+11 Nitin Chaudhary wrote:
>
>> Hi
>> I recently came across a very interesting scenario. I have a JSON Field
>> which I want to query on. I was trying to do some performance
>> optimizations and came across this
>>
>> If I query a non-JSON field like this:
>> Study.objects.all().filter(study_id__in=[Value("Tes1"),Value("Test2")])
>> and
>> Study.objects.all().filter(study_id__in=["Test1","Test2"])
>> both of these queries return the same results
>>
>> but if I try performing the same on a JSONField
>> Study.objects.all().filter(study_data__protocol__general__program_name__in=(Value("Program1"),
>>
>> Value("Program2")))
>> results in
>> DataError: invalid input syntax for type json
>> LINE 1: ...> ARRAY['protocol','general','program_name']) IN ('Prog ...
>> ^
>> DETAIL: Token "Program1" is invalid.
>> CONTEXT: JSON data, line 1: Program1
>>
>> and
>>
>> Study.objects.all().filter(study_data__protocol__general__program_name__in=("Program1","Program2"))
>> works fine.
>>
>> I am not sure if this is a potential bug with Django or is like this by
>> design. Would really appreciate if someone can explain this behavior
>> difference.
>>
>> Cheers
>>
>>
--
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/ca7c9196-535f-4372-843e-82544fa6ed89n%40googlegroups.com.
Re: Potential bug with how Value works with Django ORM queries
Hi Nitin,
Not sure what db you're using but will explain assuming PG.
In this particular example, Django uses the `->` operator which requires
that we compare jsonb types. The `__in=("Program1", "Program2")` is
converted to jsonb via `DatabaseOperations.adapt_json_value()` where as
`Value()` isn't.
`Value()` assumes the type of the argument passed in – in this case `str` –
unless you pass a second argument, `output_field`. Specifying
`output_field=JSONField()` will cause the ORM to pass these values to
`DatabaseOperations.adapt_json_value()`.
So this will work:
`Study.objects.filter(study_data__protocol__general__program_name__in=(Value("Program1",
output_field=JSONField()), ...))`
Regards
David
On Thursday, 26 October 2023 at 03:39:08 UTC+11 Nitin Chaudhary wrote:
> Hi
> I recently came across a very interesting scenario. I have a JSON Field
> which I want to query on. I was trying to do some performance
> optimizations and came across this
>
> If I query a non-JSON field like this:
> Study.objects.all().filter(study_id__in=[Value("Tes1"),Value("Test2")])
> and
> Study.objects.all().filter(study_id__in=["Test1","Test2"])
> both of these queries return the same results
>
> but if I try performing the same on a JSONField
> Study.objects.all().filter(study_data__protocol__general__program_name__in=(Value("Program1"),
>
> Value("Program2")))
> results in
> DataError: invalid input syntax for type json
> LINE 1: ...> ARRAY['protocol','general','program_name']) IN ('Prog ...
> ^
> DETAIL: Token "Program1" is invalid.
> CONTEXT: JSON data, line 1: Program1
>
> and
>
> Study.objects.all().filter(study_data__protocol__general__program_name__in=("Program1","Program2"))
> works fine.
>
> I am not sure if this is a potential bug with Django or is like this by
> design. Would really appreciate if someone can explain this behavior
> difference.
>
> Cheers
>
>
--
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/95511868-4a44-4757-a992-b4e17c716668n%40googlegroups.com.
Potential bug with how Value works with Django ORM queries
Hi
I recently came across a very interesting scenario. I have a JSON Field
which I want to query on. I was trying to do some performance
optimizations and came across this
If I query a non-JSON field like this:
Study.objects.all().filter(study_id__in=[Value("Tes1"),Value("Test2")])
and
Study.objects.all().filter(study_id__in=["Test1","Test2"])
both of these queries return the same results
but if I try performing the same on a JSONField
Study.objects.all().filter(study_data__protocol__general__program_name__in=(Value("Program1"),
Value("Program2")))
results in
DataError: invalid input syntax for type json
LINE 1: ...> ARRAY['protocol','general','program_name']) IN ('Prog ...
^
DETAIL: Token "Program1" is invalid.
CONTEXT: JSON data, line 1: Program1
and
Study.objects.all().filter(study_data__protocol__general__program_name__in=("Program1","Program2"))
works fine.
I am not sure if this is a potential bug with Django or is like this by
design. Would really appreciate if someone can explain this behavior
difference.
Cheers
--
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/207d0ca7-4b5a-4988-9bd9-db34fb061f68n%40googlegroups.com.
Django 5.0 beta 1 released
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/oct/23/django-50-beta-1-released/ -- 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/CA%2BfOnFbYwY-Q%2BT%2B_woL_0eE1emSj4OiSUQdhdvu_9AVmdN%3D%3DLw%40mail.gmail.com.
Re: HELP needed in a Reactjs Django project
I have done like this where there is input in front end and data is passed to django admin panel you have to make first crossorigin in django and then make api structure in django and then pass it in reactjs call api from axios I have code of it I will send you after some time understand it simple code you will resolve your problem On Fri, Oct 13, 2023, 19:44 Plamedi klj wrote: > Bien > > Le ven. 13 oct. 2023 à 14:14, Tejas Vaij a > écrit : > >> I am trying to upload a blob from a service-worker in react-js to a >> django server but for some reason it is not getting uploaded. I have tried >> a lot of things but nothing seems to be working. Can anyone please help me >> know what is going wrong with my code. >> >> Here is the stackoverflow link where I have mentioned about the problem >> in detail >> >> https://stackoverflow.com/questions/77280149/not-able-to-upload-file-to-django-server-from-service-worker-in-react-js >> >> -- >> 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/a1255819-e1c5-40fe-925d-406c9683fa53n%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/a1255819-e1c5-40fe-925d-406c9683fa53n%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- > 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/CABZ%3D34h5knp_Nz0P3kO9p%3D9%3DW30wxNrZHe9SokSwu0iFOW40Ew%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CABZ%3D34h5knp_Nz0P3kO9p%3D9%3DW30wxNrZHe9SokSwu0iFOW40Ew%40mail.gmail.com?utm_medium=email_source=footer> > . > -- 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/CAFmGLqmw2_30qvZ%2BELtyzhcQ-%3DhJ0Sb%2BQrgeM6Js%2BvFJu8XKTA%40mail.gmail.com.
Re: HELP needed in a Reactjs Django project
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 to answer your support query with their limited time and energy. For support, please follow the "Getting Help" page: https://docs.djangoproject.com/en/stable/faq/help/ . This will help you find people who are willing to support you, and to ask your question in a way that makes it easy for them to answer. Thanks for your understanding and all the best, Adam On Thu, Oct 12, 2023, at 8:03 AM, Plamedi klj wrote: > Bien > > Le ven. 13 oct. 2023 à 14:14, Tejas Vaij a écrit : >> I am trying to upload a blob from a service-worker in react-js to a django >> server but for some reason it is not getting uploaded. I have tried a lot of >> things but nothing seems to be working. Can anyone please help me know what >> is going wrong with my code. >> >> Here is the stackoverflow link where I have mentioned about the problem in >> detail >> https://stackoverflow.com/questions/77280149/not-able-to-upload-file-to-django-server-from-service-worker-in-react-js >> >> >> -- >> 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/a1255819-e1c5-40fe-925d-406c9683fa53n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/a1255819-e1c5-40fe-925d-406c9683fa53n%40googlegroups.com?utm_medium=email_source=footer>. > > > -- > 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/CABZ%3D34h5knp_Nz0P3kO9p%3D9%3DW30wxNrZHe9SokSwu0iFOW40Ew%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CABZ%3D34h5knp_Nz0P3kO9p%3D9%3DW30wxNrZHe9SokSwu0iFOW40Ew%40mail.gmail.com?utm_medium=email_source=footer>. -- 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/a8894a08-62ab-4820-8297-4bdc1d72963c%40app.fastmail.com.
Re: HELP needed in a Reactjs Django project
Bien Le ven. 13 oct. 2023 à 14:14, Tejas Vaij a écrit : > I am trying to upload a blob from a service-worker in react-js to a django > server but for some reason it is not getting uploaded. I have tried a lot > of things but nothing seems to be working. Can anyone please help me know > what is going wrong with my code. > > Here is the stackoverflow link where I have mentioned about the problem in > detail > > https://stackoverflow.com/questions/77280149/not-able-to-upload-file-to-django-server-from-service-worker-in-react-js > > -- > 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/a1255819-e1c5-40fe-925d-406c9683fa53n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/a1255819-e1c5-40fe-925d-406c9683fa53n%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CABZ%3D34h5knp_Nz0P3kO9p%3D9%3DW30wxNrZHe9SokSwu0iFOW40Ew%40mail.gmail.com.
HELP needed in a Reactjs Django project
I am trying to upload a blob from a service-worker in react-js to a django server but for some reason it is not getting uploaded. I have tried a lot of things but nothing seems to be working. Can anyone please help me know what is going wrong with my code. Here is the stackoverflow link where I have mentioned about the problem in detail https://stackoverflow.com/questions/77280149/not-able-to-upload-file-to-django-server-from-service-worker-in-react-js -- 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/a1255819-e1c5-40fe-925d-406c9683fa53n%40googlegroups.com.
Django security releases issued: 4.2.6, 4.1.12, and 3.2.22
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/oct/04/security-releases/ -- 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/CA%2BfOnFY6jjAeC8ftfXuGbPuEYQzw0GeVAnL7iENbvu%2BPU6v-Vw%40mail.gmail.com.
Re: Django in Portuguese
Hi, I created the following issue: https://code.djangoproject.com/ticket/34854 Thanks, Uri. אורי u...@speedy.net On Tue, Sep 19, 2023 at 9:57 PM אורי wrote: > Django Developers, > > I need to translate my website (Django) to Portuguese (Europe/Portugal > version). I translated the site and I was surprised to see that a specific > error message was in English (from FileExtensionValidator). I checked and > found out that there are many untranslated strings in language code pt, > although they are translated in pt_BR. What's the difference and isn't it > better to copy all the missing translations from pt_BR to pt, rather than > display them in English to the visitors of sites such as mine? I mean they > might understand English, but the site is meant to be in Portuguese. I > think the minimum is to show them pt_BR translations if pt translations are > missing. > > I checked other po files such as de, es, it and nl and there are no > missing translations there. > > Thanks, > Uri Rodberg, Speedy Net. > אורי > u...@speedy.net > -- 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/CABD5YeHazYY6X4xAr0XjppS2e3bWzVrdsmQvftJjzdC_AfCZcg%40mail.gmail.com.
Django in Portuguese
Django Developers, I need to translate my website (Django) to Portuguese (Europe/Portugal version). I translated the site and I was surprised to see that a specific error message was in English (from FileExtensionValidator). I checked and found out that there are many untranslated strings in language code pt, although they are translated in pt_BR. What's the difference and isn't it better to copy all the missing translations from pt_BR to pt, rather than display them in English to the visitors of sites such as mine? I mean they might understand English, but the site is meant to be in Portuguese. I think the minimum is to show them pt_BR translations if pt translations are missing. I checked other po files such as de, es, it and nl and there are no missing translations there. Thanks, Uri Rodberg, Speedy Net. אורי u...@speedy.net -- 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/CABD5YeFSj4cTdZ%3DJadAS4chg%3DJOVxJGOO%3Dv0JoE0hDedCO8DKg%40mail.gmail.com.
Django 5.0 alpha 1 released
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/sep/18/django-50-alpha-1-released/ This is my first alpha release, so let me know if you see something odd! Cheers, Natalia. -- 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/CA%2BfOnFYxgPkkn1CkPeuvm2TgbZv87PzkaVYf5bzooYSoJzMuPA%40mail.gmail.com.
Django security releases issued: 4.2.5, 4.1.11, and 3.2.21
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/sep/04/security-releases/ -- 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/a57778fc-dc16-787d-7067-e45f23805aa3%40gmail.com.
Re: Digest for django-developers@googlegroups.com - 1 update in 1 topic
I just want to share my 2 cents... Oracle is highly used in government and big Corporations in my country and banks and many critical places. So while the number of django user of oracle might be low, the prospect of introducing python and django to a legacy project is invaluable. I personally know this from work experience. But on the other hand, we should also consider future maintenance experts for oracle backend. I believe with some guidelines and help From current oracle backend maintainers would help to pass the knowledge to new prospective future contributors. Best regards to all of you. Asif On Mon, 28 Aug 2023, 9:40 am , wrote: > django-developers@googlegroups.com > <https://groups.google.com/forum/?utm_source=digest_medium=email#!forum/django-developers/topics> > Google > Groups > <https://groups.google.com/forum/?utm_source=digest_medium=email/#!overview> > <https://groups.google.com/forum/?utm_source=digest_medium=email/#!overview> > Topic digest > View all topics > <https://groups.google.com/forum/?utm_source=digest_medium=email#!forum/django-developers/topics> > >- Proposing the removal of Oracle from the Django supported backend >databases <#m_2265663842392659825_group_thread_0> - 1 Update > > Proposing the removal of Oracle from the Django supported backend > databases > <http://groups.google.com/group/django-developers/t/9ed042fa553b27b8?utm_source=digest_medium=email> > David Sanders : Aug 28 01:10AM +1000 > > I posted a thread a while back about the latest version of Oracle 23c which > appears to add support for a few things that would fix some of the > workarounds we have in the ORM (eg boolean expressions). I know dropping > 19c is a long way off but at least the future is looking brighter > > On Wed, 9 Aug 2023, 6:40 pm Carlton Gibson, > wrote: > > Back to top <#m_2265663842392659825_digest_top> > You received this digest because you're subscribed to updates for this > group. You can change your settings on the group membership page > <https://groups.google.com/forum/?utm_source=digest_medium=email#!forum/django-developers/join> > . > To unsubscribe from this group and stop receiving emails from it send an > email to django-developers+unsubscr...@googlegroups.com. > -- 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/CAKAqTgqDaApZBQ9077bZjBzdyabQjX9T_Ama5wykD8CJDy%2BYYA%40mail.gmail.com.
Re: Proposing the removal of Oracle from the Django supported backend databases
I posted a thread a while back about the latest version of Oracle 23c which appears to add support for a few things that would fix some of the workarounds we have in the ORM (eg boolean expressions). I know dropping 19c is a long way off but at least the future is looking brighter On Wed, 9 Aug 2023, 6:40 pm Carlton Gibson, wrote: > Thanks for raising this Paolo. It's good to discuss, even if we maintain > the status quo. > > I think this will come to a head when Mariusz steps away. It's been him > that's kept it going the last few years, and I'm not at all sure that we > have another currently active contributor that's an Oracle expert. (Perhaps > we do... 樂) > > It's good to see Chris' comment that Oracle wish to contribute themselves, > but if that doesn't materialise, we're going to need to claim *force > majeure*. > > Q: Are we sure we can maintain Oracle without Mariusz? What does that look > like? If not, we need to make plans for something else. > > > FWIW: If possible I'd like to keep Oracle support if we can — it's good > for the ORM. > (If we could see a way of it being maintainable, I'd have us add SQL > Server in core too — but I don't think that is feasible given the state of > play today). > > > The difference with Windows (of course) is that we have lots of > contributors using it. > > > Kind Regards, > > Carlton > > On Fri, 4 Aug 2023 at 15:19, Paolo Melchiorre > wrote: > >> Hi Mariusz, >> >> On Thu, Aug 3, 2023 at 8:47 PM Mariusz Felisiak >> wrote: >> > I'm quite surprised that you've started a new thread for something that >> was already discussed, you could always add a comment to the existing >> thread e.g. >> https://groups.google.com/g/django-developers/c/dg8BUVHKOo4/m/5uFVmdWCAwAJ >> >> I was not aware of this thread, thanks for linking it. >> >> >> I wanted to share the frustration of seeing yet another great new ORM >> feature blocked due to Oracle compatibility: >> https://github.com/django/django/pull/16417 >> > I'm not sure how you reached this conclusion. This is not blocked due >> because of Oracle compatibility. I will review it and try to merge it >> before the Django 5.0 feature freeze. You have to be patient, it has >> nothing to do with Oracle >> >> It was not my intention to push you into reviewing this PR given how >> much you already do. But it seems to me that without Oracle >> compatibility this functionality would have been ready for a long >> time. However, this reflection of mine was born after seeing the >> difficulty of the original contributor to add support to Oracle, at >> the same time I also watch again Carlton's keynote at PyCon Italia >> 2023 because the videos have recently been published. Lastly, while >> volunteering at the DSF booth at EuroPython 2023, I happened to meet >> an Oracle Django developer for the first time, who admitted that he >> had never contributed to the Oracle backend itself. >> >> >> Over the last few months, I've tried to encourage newcomers and young >> users to contribute to Django and they almost always ran into the need to >> provide compatibility to Oracle, so much so that they eventually gave up >> contributing. >> > Really? Django is not only the ORM. It is easy to demonize Oracle. I'm >> working with contributors on daily basis, and don't remember anyone who >> would resign because we have builtin Oracle backend. We don't have much >> more open tickets in the Oracle backend then in others. The number of >> unsupported features is similar to SQLite or MySQL. >> >> In my personal experience, the people I collaborate with at work or >> meet in the local communities where I go to talk about Django all have >> experience with Open Source databases and none have ever worked with >> Oracle, which makes it very difficult for them to try to contribute in >> Django's ORM why should they ensure compatibility for this DB without >> ever having seen it. >> >> >> The point is that I think Oracle is a historical anomaly among the >> database backends supported by Django because it is the only one that is >> not Open Source, it has irrelevant usage numbers >> > It's not an anomaly. Oracle support was a conscious decision, keeping >> the ORM features Oracle-compatible is a good battlefield, that helps >> keeping the ORM friendly for 3rd-party database backends as we have more >> feature flags and hooks for custom behaviors. >> >> I think this would be the same if the Oracle backend was a third-party >> package, perhaps maintained by the same company >>
Hi, I'm new to the django community
hi, I'm new to the django community and I had 1 suggestion. Django admin panel needs a new modern design. -- 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/6c245a9c-b6e9-4b4d-b753-f5d21448e795n%40googlegroups.com.
Fwd: Django dynamic multiple databases
-- Forwarded message - From: pankaj palmate Date: Sat, 12 Aug, 2023, 20:12 Subject: Django dynamic multiple databases To: I want to creating saas based application containing one super admin and rest will be customers where each customer will have their own database .want multiple database with dynamic credentials based on request.I want the database to be identified from the subdomain provided.Is this possible using django ? If yes how ? If not what's the option? I did read about the django tenants but it is schema based but I want multiple database approach while creating tenants.(database must be identified from subdomains ) Thanks and regards, Pankaj palmate -- 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/CAPyMU1KEsddfFjQ5Z7b%2B7tSMcf2cghr4esDvDFXoqBLWDsCnhA%40mail.gmail.com.
Re: Proposing the removal of Oracle from the Django supported backend databases
I've had to deal with adding Oracle support to the features I've worked on recently and with Mariusz's pointer to the right bit of the wiki (https://code.djangoproject.com/wiki/OracleTestSetup) I was able to get a working local development setup. I think once you have this local dev setup, working on Oracle support isn't much different to MySQL or Postgres. One thing I think might be valuable for improving the local developer experience would be adding test settings files for Oracle (and MySQL and Postgres) to the repository with instructions for those extra steps a contributor needs to do to use them (i.e. how to configure each database). I think experienced contributors tend to have a working setup, but there's a bit of a hurdle for newer contributors. Adding this information to the main repository would I hope also mean it is better maintained - I usually forget the wiki exists and I think it has worse bitrot than other resources. Lily --- Original Message --- On Wednesday, August 9th, 2023 at 09:39, Carlton Gibson wrote: > Thanks for raising this Paolo. It's good to discuss, even if we maintain the > status quo. > > I think this will come to a head when Mariusz steps away. It's been him > that's kept it going the last few years, and I'm not at all sure that we have > another currently active contributor that's an Oracle expert. (Perhaps we > do... 樂) > > It's good to see Chris' comment that Oracle wish to contribute themselves, > but if that doesn't materialise, we're going to need to claim *force majeure*. > > Q: Are we sure we can maintain Oracle without Mariusz? What does that look > like? If not, we need to make plans for something else. > > FWIW: If possible I'd like to keep Oracle support if we can — it's good for > the ORM. > (If we could see a way of it being maintainable, I'd have us add SQL Server > in core too — but I don't think that is feasible given the state of play > today). > > The difference with Windows (of course) is that we have lots of contributors > using it. > > Kind Regards, > > Carlton > > On Fri, 4 Aug 2023 at 15:19, Paolo Melchiorre wrote: > >> Hi Mariusz, >> >> On Thu, Aug 3, 2023 at 8:47 PM Mariusz Felisiak >> wrote: >>> I'm quite surprised that you've started a new thread for something that was >>> already discussed, you could always add a comment to the existing thread >>> e.g. >>> https://groups.google.com/g/django-developers/c/dg8BUVHKOo4/m/5uFVmdWCAwAJ >> >> I was not aware of this thread, thanks for linking it. >> >>>> I wanted to share the frustration of seeing yet another great new ORM >>>> feature blocked due to Oracle compatibility: >>>> https://github.com/django/django/pull/16417 >>> I'm not sure how you reached this conclusion. This is not blocked due >>> because of Oracle compatibility. I will review it and try to merge it >>> before the Django 5.0 feature freeze. You have to be patient, it has >>> nothing to do with Oracle >> >> It was not my intention to push you into reviewing this PR given how >> much you already do. But it seems to me that without Oracle >> compatibility this functionality would have been ready for a long >> time. However, this reflection of mine was born after seeing the >> difficulty of the original contributor to add support to Oracle, at >> the same time I also watch again Carlton's keynote at PyCon Italia >> 2023 because the videos have recently been published. Lastly, while >> volunteering at the DSF booth at EuroPython 2023, I happened to meet >> an Oracle Django developer for the first time, who admitted that he >> had never contributed to the Oracle backend itself. >> >>>> Over the last few months, I've tried to encourage newcomers and young >>>> users to contribute to Django and they almost always ran into the need to >>>> provide compatibility to Oracle, so much so that they eventually gave up >>>> contributing. >>> Really? Django is not only the ORM. It is easy to demonize Oracle. I'm >>> working with contributors on daily basis, and don't remember anyone who >>> would resign because we have builtin Oracle backend. We don't have much >>> more open tickets in the Oracle backend then in others. The number of >>> unsupported features is similar to SQLite or MySQL. >> >> In my personal experience, the people I collaborate with at work or >> meet in the local communities where I go to talk about Django all have >> experience with Open Source databases and none have ever worked with >> Oracle, which makes it very difficult for them to try to contribute
Re: Proposing the removal of Oracle from the Django supported backend databases
Thanks for raising this Paolo. It's good to discuss, even if we maintain the status quo. I think this will come to a head when Mariusz steps away. It's been him that's kept it going the last few years, and I'm not at all sure that we have another currently active contributor that's an Oracle expert. (Perhaps we do... 樂) It's good to see Chris' comment that Oracle wish to contribute themselves, but if that doesn't materialise, we're going to need to claim *force majeure*. Q: Are we sure we can maintain Oracle without Mariusz? What does that look like? If not, we need to make plans for something else. FWIW: If possible I'd like to keep Oracle support if we can — it's good for the ORM. (If we could see a way of it being maintainable, I'd have us add SQL Server in core too — but I don't think that is feasible given the state of play today). The difference with Windows (of course) is that we have lots of contributors using it. Kind Regards, Carlton On Fri, 4 Aug 2023 at 15:19, Paolo Melchiorre wrote: > Hi Mariusz, > > On Thu, Aug 3, 2023 at 8:47 PM Mariusz Felisiak > wrote: > > I'm quite surprised that you've started a new thread for something that > was already discussed, you could always add a comment to the existing > thread e.g. > https://groups.google.com/g/django-developers/c/dg8BUVHKOo4/m/5uFVmdWCAwAJ > > I was not aware of this thread, thanks for linking it. > > >> I wanted to share the frustration of seeing yet another great new ORM > feature blocked due to Oracle compatibility: > https://github.com/django/django/pull/16417 > > I'm not sure how you reached this conclusion. This is not blocked due > because of Oracle compatibility. I will review it and try to merge it > before the Django 5.0 feature freeze. You have to be patient, it has > nothing to do with Oracle > > It was not my intention to push you into reviewing this PR given how > much you already do. But it seems to me that without Oracle > compatibility this functionality would have been ready for a long > time. However, this reflection of mine was born after seeing the > difficulty of the original contributor to add support to Oracle, at > the same time I also watch again Carlton's keynote at PyCon Italia > 2023 because the videos have recently been published. Lastly, while > volunteering at the DSF booth at EuroPython 2023, I happened to meet > an Oracle Django developer for the first time, who admitted that he > had never contributed to the Oracle backend itself. > > >> Over the last few months, I've tried to encourage newcomers and young > users to contribute to Django and they almost always ran into the need to > provide compatibility to Oracle, so much so that they eventually gave up > contributing. > > Really? Django is not only the ORM. It is easy to demonize Oracle. I'm > working with contributors on daily basis, and don't remember anyone who > would resign because we have builtin Oracle backend. We don't have much > more open tickets in the Oracle backend then in others. The number of > unsupported features is similar to SQLite or MySQL. > > In my personal experience, the people I collaborate with at work or > meet in the local communities where I go to talk about Django all have > experience with Open Source databases and none have ever worked with > Oracle, which makes it very difficult for them to try to contribute in > Django's ORM why should they ensure compatibility for this DB without > ever having seen it. > > >> The point is that I think Oracle is a historical anomaly among the > database backends supported by Django because it is the only one that is > not Open Source, it has irrelevant usage numbers > > It's not an anomaly. Oracle support was a conscious decision, keeping > the ORM features Oracle-compatible is a good battlefield, that helps > keeping the ORM friendly for 3rd-party database backends as we have more > feature flags and hooks for custom behaviors. > > I think this would be the same if the Oracle backend was a third-party > package, perhaps maintained by the same company > > >> ... and the company that earns from it does not contribute in any way > to its maintenance or support > > Should be also drop support for Windows for exactly the same reason? > (rhetorical question) > > I don't know, I haven't used Windows since 2000 :-) > > Anyway, tornado to talk about Database, SQL Server is a third-party package > > >> I, therefore, suggest that we start a discussion on removing Oracle > from supported databases. > > This was already discussed. I'm still strongly against it. > > Thank you for your point of view, and also for all the extra work you > do to help Django contributors who are having trouble making their > functionalit
Re: Proposing the removal of Oracle from the Django supported backend databases
Hi Mariusz, On Thu, Aug 3, 2023 at 8:47 PM Mariusz Felisiak wrote: > I'm quite surprised that you've started a new thread for something that was > already discussed, you could always add a comment to the existing thread e.g. > https://groups.google.com/g/django-developers/c/dg8BUVHKOo4/m/5uFVmdWCAwAJ I was not aware of this thread, thanks for linking it. >> I wanted to share the frustration of seeing yet another great new ORM >> feature blocked due to Oracle compatibility: >> https://github.com/django/django/pull/16417 > I'm not sure how you reached this conclusion. This is not blocked due because > of Oracle compatibility. I will review it and try to merge it before the > Django 5.0 feature freeze. You have to be patient, it has nothing to do with > Oracle It was not my intention to push you into reviewing this PR given how much you already do. But it seems to me that without Oracle compatibility this functionality would have been ready for a long time. However, this reflection of mine was born after seeing the difficulty of the original contributor to add support to Oracle, at the same time I also watch again Carlton's keynote at PyCon Italia 2023 because the videos have recently been published. Lastly, while volunteering at the DSF booth at EuroPython 2023, I happened to meet an Oracle Django developer for the first time, who admitted that he had never contributed to the Oracle backend itself. >> Over the last few months, I've tried to encourage newcomers and young users >> to contribute to Django and they almost always ran into the need to provide >> compatibility to Oracle, so much so that they eventually gave up >> contributing. > Really? Django is not only the ORM. It is easy to demonize Oracle. I'm > working with contributors on daily basis, and don't remember anyone who > would resign because we have builtin Oracle backend. We don't have much more > open tickets in the Oracle backend then in others. The number of unsupported > features is similar to SQLite or MySQL. In my personal experience, the people I collaborate with at work or meet in the local communities where I go to talk about Django all have experience with Open Source databases and none have ever worked with Oracle, which makes it very difficult for them to try to contribute in Django's ORM why should they ensure compatibility for this DB without ever having seen it. >> The point is that I think Oracle is a historical anomaly among the database >> backends supported by Django because it is the only one that is not Open >> Source, it has irrelevant usage numbers > It's not an anomaly. Oracle support was a conscious decision, keeping the ORM > features Oracle-compatible is a good battlefield, that helps keeping the ORM > friendly for 3rd-party database backends as we have more feature flags and > hooks for custom behaviors. I think this would be the same if the Oracle backend was a third-party package, perhaps maintained by the same company >> ... and the company that earns from it does not contribute in any way to its >> maintenance or support > Should be also drop support for Windows for exactly the same reason? > (rhetorical question) I don't know, I haven't used Windows since 2000 :-) Anyway, tornado to talk about Database, SQL Server is a third-party package >> I, therefore, suggest that we start a discussion on removing Oracle from >> supported databases. > This was already discussed. I'm still strongly against it. Thank you for your point of view, and also for all the extra work you do to help Django contributors who are having trouble making their functionality compatible with Oracle. I reiterate that my only intention was to understand if I were the only one to have this point of view without wanting to criticize anyone's work or past choices, things simply change in the field of information technology and choices could be reviewed after years. Ciao, Paolo -- Paolo Melchiorre https://www.paulox.net -- 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/CAKFO%2Bx6VjKOBpUtujXh-SJ3wjfO3sfLz4ekMRukiBNfy2W-FMw%40mail.gmail.com.
Re: Proposing the removal of Oracle from the Django supported backend databases
Hello, when I got started with Django more than 10 years ago, I had inherited a legacy project with an Oracle database for porting from PHP to Python. It might also have worked out well if Oracle support had been a 3rd party package, but I can say for sure that Oracle being a core feature of Django was a huge help in getting me started. I'm aware that this is a weak argument from unfortunately a code non-contributor (or indirect contributor at best) who is not shouldering the work and not even using the Oracle backend any more (we migrated to MySQL). But still, I would like to express my opinion that having Oracle in Django core is a worthwhile asset. Best regards, Carsten Am 03.08.23 um 10:25 schrieb Paolo Melchiorre: > Hi all, > I wanted to share the frustration of seeing yet another great new ORM > feature blocked due to Oracle compatibility: > https://github.com/django/django/pull/16417 > > In the past, I too have had to put a lot of effort trying to make a PR > compatible with Oracle, making the overall contributing experience > much less pleasant and holding me back from contributing, especially > in the early days. > > Over the last few months, I've tried to encourage newcomers and young > users to contribute to Django and they almost always ran into the need > to provide compatibility to Oracle, so much so that they eventually > gave up contributing. > > I stress that I am absolutely not criticizing the contributors (very > few) in the community who help overcome the difficulties with Oracle. > > The point is that I think Oracle is a historical anomaly among the > database backends supported by Django because it is the only one that > is not Open Source, it has irrelevant usage numbers (see Django > Developers Survey 2022 Results > https://lp.jetbrains.com/django-developer-survey-2022/#horizontal-bar-chart-862) > and the company that earns from it does not contribute in any way to > its maintenance or support (see Carlton Gibson keynote at PyCon Italia > 2023 https://youtu.be/AHjnGtaWDjU?t=836) > > To add to all this we consider that developing for Oracle is much more > difficult than for the other Open Source databases supported by Django > and above all the new contributors to the ORM have a frustrating > experience and therefore they are less and less. > > I, therefore, suggest that we start a discussion on removing Oracle > from supported databases. > > Ciao, > Paolo -- 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/199b5a9f-1b10-eb13-68ea-46a66cad609b%40cafu.de.
Re: Proposing the removal of Oracle from the Django supported backend databases
Hi Paolo, I'm quite surprised that you've started a new thread for something that was already discussed, you could always add a comment to the existing thread e.g. https://groups.google.com/g/django-developers/c/dg8BUVHKOo4/m/5uFVmdWCAwAJ > I wanted to share the frustration of seeing yet another great new ORM feature blocked due to Oracle compatibility: https://github.com/django/django/pull/16417 I'm not sure how you reached this conclusion. This is not blocked due because of Oracle compatibility. I will review it and try to merge it before the Django 5.0 feature freeze. You have to be patient, it has nothing to do with Oracle. I just need more time as it's complicated feature, e.g. it took me 2 weeks to review and merge PR with database defaults. I do my best to avoid regressions and provide stable feature, unfortunately such pedantic approach takes time. > Over the last few months, I've tried to encourage newcomers and young users to contribute to Django and they almost always ran into the need to provide compatibility to Oracle, so much so that they eventually gave up contributing. Really? Django is not only the ORM. It is easy to demonize Oracle. I'm working with contributors on daily basis, and don't remember anyone who would resign because we have builtin Oracle backend. We don't have much more open tickets in the Oracle backend then in others*. *The number of unsupported features is similar to SQLite or MySQL. > The point is that I think Oracle is a historical anomaly among the database backends supported by Django because it is the only one that is not Open Source, it has irrelevant usage numbers It's not an anomaly. Oracle support was a conscious decision, keeping the ORM features Oracle-compatible is a good battlefield, that helps keeping the ORM friendly for 3rd-party database backends as we have more feature flags and hooks for custom behaviors. > ... and the company that earns from it does not contribute in any way to its maintenance or support Should be also drop support for Windows for exactly the same reason? (rhetorical question) > I, therefore, suggest that we start a discussion on removing Oracle from supported databases. This was already discussed. I'm still strongly against it. Best, Mariusz -- 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/3878edbd-23cf-4854-afcf-08aefb01e0c7n%40googlegroups.com.
Re: Proposing the removal of Oracle from the Django supported backend databases
I don't have a strong opinion in either direction here. I would like to point out that every database we support is a maintenance burden, however. It's an exaggeration that Oracle alone causes problems but other backends don't. For example when I was working on collations, I ran into issues with SQLite's lack of good ways to inspect the database. I ran into problems with MySQL's lacking documentation on collations and its seeming semi-support for it. I ran into problems with Postgres as you need to create some of its more powerful collations in SQL first. I also ran into issues with Oracle, but they were actually easier to overcome than some of the others. I also gave up on an attempt at an EnumField for models because Postgres handles them in a totally different way from other databases and it ended up raising so many questions that I just gave up. I would say, however, that Oracle usually has perhaps more than its share of problems. And of course Oracle's lack of financial support gives impetus to care less about it, as we seemingly do for MS SQL server, which probably sees more use overall than Oracle. Bur Oracle is already established in the codebase. It also shouldn't be forgotten that while 2% as a relative number is quite small, the absolute number of people it will affect is quite large, and I certainly wouldn't call it "irrelevant". I wouldn't be against moving it to jazzband, say, but without people stepping up to maintain it (and there is an impetus for this when it's in Django's codebase), it may just end up abandoned. Tom On Thu, 3 Aug 2023 at 13:27, Jörg Breitbart wrote: > +1 from my side for removing oracle support from django itself. > > If very low usage + high maintenance burden does not qualify for feature > removal, idk what does - maybe not being supportive at all. Oh wait... > > In the end such low usage numbers are prolly better served by a 3rd > party package. > > Regards, > Jerch > > -- > 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/0380eceb-c0bc-1a81-411b-b8e0e8588c83%40netzkolchose.de > . > -- 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/CAHoz%3DMYDBpgD_r87HaAr9sG%2BY7KpOLNVPJ4sZAqDP9T-vc_MyA%40mail.gmail.com.
Re: Proposing the removal of Oracle from the Django supported backend databases
+1 from my side for removing oracle support from django itself. If very low usage + high maintenance burden does not qualify for feature removal, idk what does - maybe not being supportive at all. Oh wait... In the end such low usage numbers are prolly better served by a 3rd party package. Regards, Jerch -- 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/0380eceb-c0bc-1a81-411b-b8e0e8588c83%40netzkolchose.de.
Re: Proposing the removal of Oracle from the Django supported backend databases
On Thu, Aug 3, 2023 at 6:26 PM Paolo Melchiorre wrote: > Hi all, > I wanted to share the frustration of seeing yet another great new ORM > feature blocked due to Oracle compatibility: > https://github.com/django/django/pull/16417 > > In the past, I too have had to put a lot of effort trying to make a PR > compatible with Oracle, making the overall contributing experience > much less pleasant and holding me back from contributing, especially > in the early days. > > Over the last few months, I've tried to encourage newcomers and young > users to contribute to Django and they almost always ran into the need > to provide compatibility to Oracle, so much so that they eventually > gave up contributing. > > I stress that I am absolutely not criticizing the contributors (very > few) in the community who help overcome the difficulties with Oracle. > > The point is that I think Oracle is a historical anomaly among the > database backends supported by Django because it is the only one that > is not Open Source, it has irrelevant usage numbers (see Django > Developers Survey 2022 Results > > https://lp.jetbrains.com/django-developer-survey-2022/#horizontal-bar-chart-862 > ) > and the company that earns from it does not contribute in any way to > its maintenance or support (see Carlton Gibson keynote at PyCon Italia > 2023 https://youtu.be/AHjnGtaWDjU?t=836) > > To add to all this we consider that developing for Oracle is much more > difficult than for the other Open Source databases supported by Django > and above all the new contributors to the ORM have a frustrating > experience and therefore they are less and less. > > I, therefore, suggest that we start a discussion on removing Oracle > from supported databases. > > Ciao, > Paolo > -- > Paolo Melchiorre > > https://www.paulox.net > > We (Oracle0 would like to improve Oracle support in Django and intend to contribute. However the PR to add support for the latest Oracle driver is blocked because debugging information about a test failure isn't available, and the failure isn't seen by us. If that can be overcome, then we can make headway. Chris -- 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/CAPEpGM9%3D0iPJA-JHAfRtf0s1FLZEcRkL_j5En4y1nD584658kQ%40mail.gmail.com.
Proposing the removal of Oracle from the Django supported backend databases
Hi all, I wanted to share the frustration of seeing yet another great new ORM feature blocked due to Oracle compatibility: https://github.com/django/django/pull/16417 In the past, I too have had to put a lot of effort trying to make a PR compatible with Oracle, making the overall contributing experience much less pleasant and holding me back from contributing, especially in the early days. Over the last few months, I've tried to encourage newcomers and young users to contribute to Django and they almost always ran into the need to provide compatibility to Oracle, so much so that they eventually gave up contributing. I stress that I am absolutely not criticizing the contributors (very few) in the community who help overcome the difficulties with Oracle. The point is that I think Oracle is a historical anomaly among the database backends supported by Django because it is the only one that is not Open Source, it has irrelevant usage numbers (see Django Developers Survey 2022 Results https://lp.jetbrains.com/django-developer-survey-2022/#horizontal-bar-chart-862) and the company that earns from it does not contribute in any way to its maintenance or support (see Carlton Gibson keynote at PyCon Italia 2023 https://youtu.be/AHjnGtaWDjU?t=836) To add to all this we consider that developing for Oracle is much more difficult than for the other Open Source databases supported by Django and above all the new contributors to the ORM have a frustrating experience and therefore they are less and less. I, therefore, suggest that we start a discussion on removing Oracle from supported databases. Ciao, Paolo -- Paolo Melchiorre https://www.paulox.net -- 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/CAKFO%2Bx6WXzhhKPoDVodD_dKQEkyLKT3hJOA26seC6%2B3Tb1QrXQ%40mail.gmail.com.
Django bugfix release: 4.2.4
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/aug/01/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 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/CA%2BfOnFYWcfe8j2fD1K_Fhb03jseLf8xKST6Wn27reeUCJN_hzQ%40mail.gmail.com.
Re: Django app
Yahh I can help too On Thu, Jul 6, 2023, 20:41 Sospeter Mong'are wrote: > Hi, > I need a mate to help me a simple django app test here. to brainstom > > -- > 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/3aae35cb-3a43-4f91-aa1b-e414b9adedb7n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/3aae35cb-3a43-4f91-aa1b-e414b9adedb7n%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CAG8%2B7xbQah_4ZFsHVUeDp-Rx7G%3DF18WoogEq8rd2SEwnd1G8YA%40mail.gmail.com.
Re: Django app
Hi there, I too can help. If you need another developer to help you I am available. Regards, On Fri, 7 Jul 2023, 3:30 am Sospeter Mong'are, wrote: > Hi @marline, > Kindly check your google chat. > > On Thursday, July 6, 2023 at 8:00:44 PM UTC+3 Marline Khavele wrote: > >> I can help >> >> On Thu 6. Jul 2023 at 17:12, Sospeter Mong'are >> wrote: >> >>> Hi, >>> I need a mate to help me a simple django app test here. to brainstom >>> >>> -- >>> 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-develop...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/3aae35cb-3a43-4f91-aa1b-e414b9adedb7n%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/3aae35cb-3a43-4f91-aa1b-e414b9adedb7n%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> >> -- > 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/8746f046-046e-4e84-891e-a2b89b965f65n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/8746f046-046e-4e84-891e-a2b89b965f65n%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CAJ5pyZ%3DcLbv174e7z%2B%2BGqz2vU%3DaKNMRk0-gyYkvfdBps3qWWng%40mail.gmail.com.
Re: Django app
Hi @marline, Kindly check your google chat. On Thursday, July 6, 2023 at 8:00:44 PM UTC+3 Marline Khavele wrote: > I can help > > On Thu 6. Jul 2023 at 17:12, Sospeter Mong'are wrote: > >> Hi, >> I need a mate to help me a simple django app test here. to brainstom >> >> -- >> 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-develop...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/3aae35cb-3a43-4f91-aa1b-e414b9adedb7n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/3aae35cb-3a43-4f91-aa1b-e414b9adedb7n%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- 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/8746f046-046e-4e84-891e-a2b89b965f65n%40googlegroups.com.
Re: Django app
I can help On Thu 6. Jul 2023 at 17:12, Sospeter Mong'are wrote: > Hi, > I need a mate to help me a simple django app test here. to brainstom > > -- > 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/3aae35cb-3a43-4f91-aa1b-e414b9adedb7n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/3aae35cb-3a43-4f91-aa1b-e414b9adedb7n%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CAKjf-SBRamA%3DhD2jvRXdbb8ZZ0T6B-x1QVL-LiFsB3VS98f7uA%40mail.gmail.com.
Django app
Hi, I need a mate to help me a simple django app test here. to brainstom -- 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/3aae35cb-3a43-4f91-aa1b-e414b9adedb7n%40googlegroups.com.
Django security releases issued: 4.2.3, 4.1.10, and 3.2.20
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/jul/03/security-releases/ -- 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/dd4b460f-3e40-62fd-5435-c1ab7468ce0a%40gmail.com.
Re: Deploying Django under a sub-path
I actually meant this as a developer question: as, at least in my review of the code, and testing with `manage.py runserver`. use of `SCRIPT_NAME` has no observable effect. If that can be confirmed, then yes, the documentation should be updated, and I can do a PR accordingly. Use of `SCRIPT_NAME` itself is not documented anywhere; seems like it should at least be mentioned in the Deployment section. Arthur Pemberton On Fri, Jun 23, 2023 at 3:07 PM 'Adam Johnson' via Django developers (Contributions to Django itself) wrote: > Hi Arthur, > > You've found the wrong mailing list for this thread. This mailing list is > for discussing the development of Django itself, not for support using > Django. I guess that's why no one replied. > > If you would like to suggest a documentation change please do open a PR > with reference to the information you found. > > Thanks, > > Adam > > On Fri, Jun 16, 2023 at 10:23 PM Arthur Pemberton > wrote: > >> I found https://code.djangoproject.com/ticket/7930 seems like >> `FORCE_SCRIPT_NAME` just isn't meant to work. >> >> Maybe the docs should reflect that. >> >> Arthur Pemberton >> >> On Fri, Jun 16, 2023 at 5:18 PM Arthur Pemberton >> wrote: >> >>> Even with `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly, >>> but not `STATIC_URL` . >>> >>> Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ? >>> >>> Arthur Pemberton >>> >>> On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton >>> wrote: >>> >>>> The docs reference `FORCE_SCRIPT_NAME` but say very little of how to >>>> use it. >>>> >>>> Reading through the code, I see very little use of `SCRIPT_NAME` >>>> itself, however as far as I can tell, use of `SCRIPT_NAME` is supposed to >>>> be how one deploys Django at a sub-path. >>>> >>>> I had to modify wsgi.py per >>>> https://ruddra.com/deploy-django-subpath-openshift/ to get things to >>>> work. >>>> >>>> Shouldn't this be a complete feature? >>>> >>>> I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/ >>>> and there's no information on the topic (that I could find). >>>> >>>> Arthur Pemberton >>>> >>> -- >> 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/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%40mail.gmail.com?utm_medium=email_source=footer> >> . >> > -- > 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/CAMyDDM016eww3f5GBB1sPHJncf%2BWUHk7nLdQsf9ezUhJY0d9XQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMyDDM016eww3f5GBB1sPHJncf%2BWUHk7nLdQsf9ezUhJY0d9XQ%40mail.gmail.com?utm_medium=email_source=footer> > . > -- 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/CA%2BX4dQQDEdkmuvFHrpcBKkQEeQ1aF6SNvuZ7Om1hAacEPx_jLg%40mail.gmail.com.
Re: Deploying Django under a sub-path
Hi Arthur, You've found the wrong mailing list for this thread. This mailing list is for discussing the development of Django itself, not for support using Django. I guess that's why no one replied. If you would like to suggest a documentation change please do open a PR with reference to the information you found. Thanks, Adam On Fri, Jun 16, 2023 at 10:23 PM Arthur Pemberton wrote: > I found https://code.djangoproject.com/ticket/7930 seems like > `FORCE_SCRIPT_NAME` just isn't meant to work. > > Maybe the docs should reflect that. > > Arthur Pemberton > > On Fri, Jun 16, 2023 at 5:18 PM Arthur Pemberton > wrote: > >> Even with `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly, >> but not `STATIC_URL` . >> >> Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ? >> >> Arthur Pemberton >> >> On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton >> wrote: >> >>> The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use >>> it. >>> >>> Reading through the code, I see very little use of `SCRIPT_NAME` itself, >>> however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how >>> one deploys Django at a sub-path. >>> >>> I had to modify wsgi.py per >>> https://ruddra.com/deploy-django-subpath-openshift/ to get things to >>> work. >>> >>> Shouldn't this be a complete feature? >>> >>> I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/ >>> and there's no information on the topic (that I could find). >>> >>> Arthur Pemberton >>> >> -- > 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/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%40mail.gmail.com?utm_medium=email_source=footer> > . > -- 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/CAMyDDM016eww3f5GBB1sPHJncf%2BWUHk7nLdQsf9ezUhJY0d9XQ%40mail.gmail.com.
Re: Ticket #34646 Ordering a Django admin column based on multiple model fields
I really hope the developers implement the patch. On Monday, June 19, 2023 at 4:55:42 AM UTC+3 David Sanders wrote: > Sorry to clarify I intended to respond with "niche solution" not "nice > solution" lol. I didn't realise the phone's autocomplete had done that. > > On Monday, 19 June 2023 at 11:05:41 UTC+10 David Sanders wrote: > >> Mariusz is a developer, so that's at least 1 developer's opinion :) >> >> Unless anybody else pipes up to counter this I'd consider it to be a nice >> solution. >> >> On Monday, 19 June 2023 at 05:01:52 UTC+10 Mubarak Alrashidi wrote: >> >>> Can we at least know what the developers think about it? >>> >>> >>> On Sunday, June 11, 2023 at 1:28:58 AM UTC+3 Mubarak Alrashidi wrote: >>> >>>> Hello, >>>> >>>> I posted this StackOverflow question >>>> <https://stackoverflow.com/q/76425892/67579>, and @Willem Van Onsem >>>> <https://code.djangoproject.com/query?status=!closed=KommuSoft> >>>> tried >>>> to help by opening a ticket numbered #34646 >>>> <https://code.djangoproject.com/ticket/34646>, and creating a patch >>>> for supporting the order by multiple fields in admin.display decorator. >>>> >>>> But it got closed as a duplicate of #31975 >>>> <https://code.djangoproject.com/ticket/31975> which was reported about >>>> 3 years ago, and it got closed as wontfix by @Mariusz Felisiak >>>> <https://github.com/felixxm> because he said: *"We don't want to add >>>> unnecessary complexity to the API.".* >>>> >>>> And I agree with what @Petr Dlouhý >>>> <https://code.djangoproject.com/query?status=!closed=PetrDlouhy> >>>> says: *"it is small modification of Django code and small increase in >>>> API complexity (which is consistent with the logic of other order fields, >>>> BTW)."**.* >>>> >>>> The inconsistency is when somewhere we're able to order by multiple >>>> fields, and somewhere else we can't. >>>> >>>> If we can order by multiple fields in the modelAdmin classes, why can't >>>> we do so in the admin.display decorator? >>>> >>>> So, I do hope to reconsider implementing the patch >>>> <https://code.djangoproject.com/attachment/ticket/34646/django_ordering.py.diff> >>>> that @Willem Van Onsem >>>> <https://code.djangoproject.com/query?status=!closed=KommuSoft> >>>> created. >>>> >>>> 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 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/6fe718c4-9faa-44eb-b981-a6f720372cd9n%40googlegroups.com.
Re: Ticket #34646 Ordering a Django admin column based on multiple model fields
Sorry to clarify I intended to respond with "niche solution" not "nice solution" lol. I didn't realise the phone's autocomplete had done that. On Monday, 19 June 2023 at 11:05:41 UTC+10 David Sanders wrote: > Mariusz is a developer, so that's at least 1 developer's opinion :) > > Unless anybody else pipes up to counter this I'd consider it to be a nice > solution. > > On Monday, 19 June 2023 at 05:01:52 UTC+10 Mubarak Alrashidi wrote: > >> Can we at least know what the developers think about it? >> >> >> On Sunday, June 11, 2023 at 1:28:58 AM UTC+3 Mubarak Alrashidi wrote: >> >>> Hello, >>> >>> I posted this StackOverflow question >>> <https://stackoverflow.com/q/76425892/67579>, and @Willem Van Onsem >>> <https://code.djangoproject.com/query?status=!closed=KommuSoft> >>> tried >>> to help by opening a ticket numbered #34646 >>> <https://code.djangoproject.com/ticket/34646>, and creating a patch for >>> supporting the order by multiple fields in admin.display decorator. >>> >>> But it got closed as a duplicate of #31975 >>> <https://code.djangoproject.com/ticket/31975> which was reported about >>> 3 years ago, and it got closed as wontfix by @Mariusz Felisiak >>> <https://github.com/felixxm> because he said: *"We don't want to add >>> unnecessary complexity to the API.".* >>> >>> And I agree with what @Petr Dlouhý >>> <https://code.djangoproject.com/query?status=!closed=PetrDlouhy> >>> says: *"it is small modification of Django code and small increase in >>> API complexity (which is consistent with the logic of other order fields, >>> BTW)."**.* >>> >>> The inconsistency is when somewhere we're able to order by multiple >>> fields, and somewhere else we can't. >>> >>> If we can order by multiple fields in the modelAdmin classes, why can't >>> we do so in the admin.display decorator? >>> >>> So, I do hope to reconsider implementing the patch >>> <https://code.djangoproject.com/attachment/ticket/34646/django_ordering.py.diff> >>> that @Willem Van Onsem >>> <https://code.djangoproject.com/query?status=!closed=KommuSoft> >>> created. >>> >>> 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 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/9de4defb-b14b-4174-8678-4c3b3227aca5n%40googlegroups.com.
Re: Ticket #34646 Ordering a Django admin column based on multiple model fields
I also lately stumbled across this and was a little surprised that it could not handle multiple fields, as it is the case in other places. So +1 for fixing this from me :) Am 19. Juni 2023 03:05:41 MESZ schrieb David Sanders : >Mariusz is a developer, so that's at least 1 developer's opinion :) > >Unless anybody else pipes up to counter this I'd consider it to be a nice >solution. > >On Monday, 19 June 2023 at 05:01:52 UTC+10 Mubarak Alrashidi wrote: > >> Can we at least know what the developers think about it? >> >> >> On Sunday, June 11, 2023 at 1:28:58 AM UTC+3 Mubarak Alrashidi wrote: >> >>> Hello, >>> >>> I posted this StackOverflow question >>> <https://stackoverflow.com/q/76425892/67579>, and @Willem Van Onsem >>> <https://code.djangoproject.com/query?status=!closed=KommuSoft> >>> tried >>> to help by opening a ticket numbered #34646 >>> <https://code.djangoproject.com/ticket/34646>, and creating a patch for >>> supporting the order by multiple fields in admin.display decorator. >>> >>> But it got closed as a duplicate of #31975 >>> <https://code.djangoproject.com/ticket/31975> which was reported about 3 >>> years ago, and it got closed as wontfix by @Mariusz Felisiak >>> <https://github.com/felixxm> because he said: *"We don't want to add >>> unnecessary complexity to the API.".* >>> >>> And I agree with what @Petr Dlouhý >>> <https://code.djangoproject.com/query?status=!closed=PetrDlouhy> >>> says: *"it is small modification of Django code and small increase in >>> API complexity (which is consistent with the logic of other order fields, >>> BTW)."**.* >>> >>> The inconsistency is when somewhere we're able to order by multiple >>> fields, and somewhere else we can't. >>> >>> If we can order by multiple fields in the modelAdmin classes, why can't >>> we do so in the admin.display decorator? >>> >>> So, I do hope to reconsider implementing the patch >>> <https://code.djangoproject.com/attachment/ticket/34646/django_ordering.py.diff> >>> that @Willem Van Onsem >>> <https://code.djangoproject.com/query?status=!closed=KommuSoft> >>> created. >>> >>> 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 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/02535619-27e9-40ec-835b-1ea1c5a08315n%40googlegroups.com. -- 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/5D677F69-2F6F-480C-8657-F1851B175E4A%40posteo.de.
Re: Ticket #34646 Ordering a Django admin column based on multiple model fields
Mariusz is a developer, so that's at least 1 developer's opinion :) Unless anybody else pipes up to counter this I'd consider it to be a nice solution. On Monday, 19 June 2023 at 05:01:52 UTC+10 Mubarak Alrashidi wrote: > Can we at least know what the developers think about it? > > > On Sunday, June 11, 2023 at 1:28:58 AM UTC+3 Mubarak Alrashidi wrote: > >> Hello, >> >> I posted this StackOverflow question >> <https://stackoverflow.com/q/76425892/67579>, and @Willem Van Onsem >> <https://code.djangoproject.com/query?status=!closed=KommuSoft> >> tried >> to help by opening a ticket numbered #34646 >> <https://code.djangoproject.com/ticket/34646>, and creating a patch for >> supporting the order by multiple fields in admin.display decorator. >> >> But it got closed as a duplicate of #31975 >> <https://code.djangoproject.com/ticket/31975> which was reported about 3 >> years ago, and it got closed as wontfix by @Mariusz Felisiak >> <https://github.com/felixxm> because he said: *"We don't want to add >> unnecessary complexity to the API.".* >> >> And I agree with what @Petr Dlouhý >> <https://code.djangoproject.com/query?status=!closed=PetrDlouhy> >> says: *"it is small modification of Django code and small increase in >> API complexity (which is consistent with the logic of other order fields, >> BTW)."**.* >> >> The inconsistency is when somewhere we're able to order by multiple >> fields, and somewhere else we can't. >> >> If we can order by multiple fields in the modelAdmin classes, why can't >> we do so in the admin.display decorator? >> >> So, I do hope to reconsider implementing the patch >> <https://code.djangoproject.com/attachment/ticket/34646/django_ordering.py.diff> >> that @Willem Van Onsem >> <https://code.djangoproject.com/query?status=!closed=KommuSoft> >> created. >> >> 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 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/02535619-27e9-40ec-835b-1ea1c5a08315n%40googlegroups.com.
Re: Ticket #34646 Ordering a Django admin column based on multiple model fields
Can we at least know what the developers think about it? On Sunday, June 11, 2023 at 1:28:58 AM UTC+3 Mubarak Alrashidi wrote: > Hello, > > I posted this StackOverflow question > <https://stackoverflow.com/q/76425892/67579>, and @Willem Van Onsem > <https://code.djangoproject.com/query?status=!closed=KommuSoft> > tried > to help by opening a ticket numbered #34646 > <https://code.djangoproject.com/ticket/34646>, and creating a patch for > supporting the order by multiple fields in admin.display decorator. > > But it got closed as a duplicate of #31975 > <https://code.djangoproject.com/ticket/31975> which was reported about 3 > years ago, and it got closed as wontfix by @Mariusz Felisiak > <https://github.com/felixxm> because he said: *"We don't want to add > unnecessary complexity to the API.".* > > And I agree with what @Petr Dlouhý > <https://code.djangoproject.com/query?status=!closed=PetrDlouhy> > says: *"it is small modification of Django code and small increase in > API complexity (which is consistent with the logic of other order fields, > BTW)."**.* > > The inconsistency is when somewhere we're able to order by multiple > fields, and somewhere else we can't. > > If we can order by multiple fields in the modelAdmin classes, why can't we > do so in the admin.display decorator? > > So, I do hope to reconsider implementing the patch > <https://code.djangoproject.com/attachment/ticket/34646/django_ordering.py.diff> > that @Willem Van Onsem > <https://code.djangoproject.com/query?status=!closed=KommuSoft> > created. > > 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 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/7ca7b6c0-204e-47d3-8971-8d05722fed11n%40googlegroups.com.
Re: Deploying Django under a sub-path
I found https://code.djangoproject.com/ticket/7930 seems like `FORCE_SCRIPT_NAME` just isn't meant to work. Maybe the docs should reflect that. Arthur Pemberton On Fri, Jun 16, 2023 at 5:18 PM Arthur Pemberton wrote: > Even with `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly, but > not `STATIC_URL` . > > Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ? > > Arthur Pemberton > > On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton > wrote: > >> The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use >> it. >> >> Reading through the code, I see very little use of `SCRIPT_NAME` itself, >> however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how >> one deploys Django at a sub-path. >> >> I had to modify wsgi.py per >> https://ruddra.com/deploy-django-subpath-openshift/ to get things to >> work. >> >> Shouldn't this be a complete feature? >> >> I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/ >> and there's no information on the topic (that I could find). >> >> Arthur Pemberton >> > -- 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/CA%2BX4dQSQDcaApgWFmEE8MRERKbdHBBPh4KXa12pTi9FHO7zx1g%40mail.gmail.com.
Re: Deploying Django under a sub-path
Even with `FORCE_SCRIPT_NAME` `MEDIA_URL` is being prefixed properly, but not `STATIC_URL` . Was `FORCE_SCRIPT_NAME` just not meant to be used with the `runserver` ? Arthur Pemberton On Fri, Jun 16, 2023 at 5:01 PM Arthur Pemberton wrote: > The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use > it. > > Reading through the code, I see very little use of `SCRIPT_NAME` itself, > however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how > one deploys Django at a sub-path. > > I had to modify wsgi.py per > https://ruddra.com/deploy-django-subpath-openshift/ to get things to work. > > Shouldn't this be a complete feature? > > I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/ > and there's no information on the topic (that I could find). > > Arthur Pemberton > -- 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/CA%2BX4dQRYbJ4NnKD89ptsJHGx2EUxO4vqZH0oepHVAN%2Bf%3D7S_Ag%40mail.gmail.com.
Deploying Django under a sub-path
The docs reference `FORCE_SCRIPT_NAME` but say very little of how to use it. Reading through the code, I see very little use of `SCRIPT_NAME` itself, however as far as I can tell, use of `SCRIPT_NAME` is supposed to be how one deploys Django at a sub-path. I had to modify wsgi.py per https://ruddra.com/deploy-django-subpath-openshift/ to get things to work. Shouldn't this be a complete feature? I've re-checked https://docs.djangoproject.com/en/4.2/howto/deployment/ and there's no information on the topic (that I could find). Arthur Pemberton -- 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/CA%2BX4dQRiRkPKQVik9aRQ1z07-j_jOVK9fHQAtt2r_v%3Dajrd0uQ%40mail.gmail.com.
Ticket #34646 Ordering a Django admin column based on multiple model fields
Hello, I posted this StackOverflow question <https://stackoverflow.com/q/76425892/67579>, and @Willem Van Onsem <https://code.djangoproject.com/query?status=!closed=KommuSoft> tried to help by opening a ticket numbered #34646 <https://code.djangoproject.com/ticket/34646>, and creating a patch for supporting the order by multiple fields in admin.display decorator. But it got closed as a duplicate of #31975 <https://code.djangoproject.com/ticket/31975> which was reported about 3 years ago, and it got closed as wontfix by @Mariusz Felisiak <https://github.com/felixxm> because he said: *"We don't want to add unnecessary complexity to the API.".* And I agree with what @Petr Dlouhý <https://code.djangoproject.com/query?status=!closed=PetrDlouhy> says: *"it is small modification of Django code and small increase in API complexity (which is consistent with the logic of other order fields, BTW)."**.* The inconsistency is when somewhere we're able to order by multiple fields, and somewhere else we can't. If we can order by multiple fields in the modelAdmin classes, why can't we do so in the admin.display decorator? So, I do hope to reconsider implementing the patch <https://code.djangoproject.com/attachment/ticket/34646/django_ordering.py.diff> that @Willem Van Onsem <https://code.djangoproject.com/query?status=!closed=KommuSoft> created. 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 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/60b18b91-935b-432c-940d-6a25ebb4f6a6n%40googlegroups.com.
Interaction to Django community
Hey Techies, Kumbhaj this side. I am new member here I just want explore and intract to you all community members. Current status: MERN developer, College student, founder of bugbaar THINKING TO Deep drive python django also. Let's Connect: Linkedin: https://www.linkedin.com/in/kumbhaj Youtube: http://youtube.com/@Kumbhaj Thanks 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPjc%3DUXiQ4NexTg_XDN7cRm823Xqn2GPz%3Dbp95%3DiRn6QjScwJA%40mail.gmail.com.
Django bugfix release: 4.2.2
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/jun/05/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 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/CA%2BfOnFYER4sDJs8pdWPsoxHBa-nYspPuPH3Ab1SL%2BdfjF-X_iw%40mail.gmail.com.
Re: Django t-shirt
Hi Fabien, for what it’s worth Django also has merch with FreeWear, who are based in Spain: https://www.freewear.org/Django Cheers, Thibaud On Monday, 16 January 2023 at 13:26:25 UTC Fabien Schwob wrote: > Hello, > > It would be awesome to also have a Threadless alternative for Europe, to > avoid huge delivery costs and customs fees. > > Best regards, > > Dim 15 janv 2023, à 09:03, 'Adam Johnson' via Django developers > (Contributions to Django itself) a écrit : > > There is a Django Threadless store where you can buy T-Shirts and other > merchandise, which all supports the DSF: https://django.threadless.com/ > > It’s linked from the fundraising page: > https://www.djangoproject.com/fundraising/ > > I have a Django phone case from there! > > On Fri, Jan 13, 2023 at 11:44 AM Stephen Wolff > wrote: > > Hi there, > > A few Django versions ago (1.7 and maybe 1.8?!), t-shirts were produced > and sold (i guess for fundraising purposes?). > > Just wondering given the forthcoming LTS is 4.2, which has similarities to > Douglas Adams's answer to the life, universe and everything, whether a new > t-shirt could be produced? > > Yours hopefully, > > Stephen > > > -- > 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-develop...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/7570a944-3822-4493-acf0-4510c24e7b8bn%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/7570a944-3822-4493-acf0-4510c24e7b8bn%40googlegroups.com?utm_medium=email_source=footer> > . > > > -- > 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-develop...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMyDDM2jQx2RTyDktvi%2BTCMa%3D4PR43SXPpwxv7V9A8bL-z-hEA%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CAMyDDM2jQx2RTyDktvi%2BTCMa%3D4PR43SXPpwxv7V9A8bL-z-hEA%40mail.gmail.com?utm_medium=email_source=footer> > . > > > -- 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/a75c0e16-1670-464d-9d6e-20835ba22df8n%40googlegroups.com.
Django 5.x Steering Council Election Results
The Steering Council for the Django 5.x release cycle will be: * Simon Charette * Andrew Godwin * Adam Johnson * James Bennett Congratulations to the new council, and a special thank you for the departing members Thomas Forbes and Florian Apolloner. Thank you to everyone who participated in the nominations and voting. Voting breakdown: * 268 eligible voters * 74 votes received There were not enough candidates to fill the positions available, so all candidates were successful. Full voting breakdown available at https://app.rankedvote.co/rv/maknqpc22widuqn869/results -- 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/f56cecb2-49f8-4c3a-95d0-e63da32f19dfn%40googlegroups.com.
Django security releases issued: 4.2.1, 4.1.9, and 3.2.19
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/may/03/security-releases/ -- 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/5d4bc931-5e62-7341-6de2-ac983fea95e7%40gmail.com.
Re: Django behavior on translatable URL patterns (i18n_patterns) when prefix_default_language=False is used.
Anthony, please don't start the same discussion on multiple channels. If anyone wants to add a comment, please do so in the forum <https://forum.djangoproject.com/t/django-behavior-on-translatable-url-patterns-i18n-patterns-when-prefix-default-language-false-is-used/20564/11> . -- 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/e5ac7207-08c9-49e9-8045-404c28489cb7n%40googlegroups.com.
Django behavior on translatable URL patterns (i18n_patterns) when prefix_default_language=False is used.
I have reported a few days ago an issue in Django 4.2 regarding translatable URL patterns: https://code.djangoproject.com/ticket/34515 Sarah Boyce (thank you Sarah) is working on a patch to fix the 404 issue: https://github.com/django/django/pull/16797 But, for now, we do not agree on the correct behavior in the case described. So, as she suggested ( https://github.com/django/django/pull/16797#issuecomment-1524958085), I write to ask the community. In brief: 1. Using i18n_patterns with default_prefix_language = True with 3 different languages (perfectly OK): - */en/about/* goes to English page - */es/a-proposito/* goes to Spanish page - */fr/a-propos/* goes to French page 2. Using i18n_patterns with default_prefix_language = False with 3 different languages and default to english (perfectly OK): - about/ goes to English page - */es/a-proposito/* goes to Spanish page - */fr/a-propos/* goes to French page 3. Using i18n_patterns with default_prefix_language = False with 3 different languages and default to french in Django 4.1 (seems OK to me): - */en/about/* goes to English page - */es/a-proposito/* goes to Spanish page - */a-propos/* goes to French page 4. Using i18n_patterns with default_prefix_language = False with 3 different languages and default to french in Django 4.2 (bug report): - */en/about/* goes to English page - */es/a-proposito/* goes to Spanish page - */a-propos/* raises HTTP 404 (because cookie or http header is not 'fr') 5. Using i18n_patterns with default_prefix_language = False with 3 different languages and default to french with Sarah's patch (what we do not agree on): - */en/about/* goes to English page - */es/a-proposito/* goes to Spanish page - */a-propos/* redirects to */en/about/* (because cookie or http header is 'en') IMO, behavior 3 is good (because it reproduces 1 without prefix). Sarah's and Nessita's opinion is that behavior 5 is correct. More details in the issues and PR. So, what do you think? Thank you! Anthony -- 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/cdc7e87e-929a-447b-be21-de180ef9f6bbn%40googlegroups.com.
Re: Django 5.x Technical Board Candidate Registration
With apologies from the Secretary, the above information is incorrect regarding the candidacy requirements for this election. The new post with the updated details has been posted here: https://groups.google.com/g/django-developers/c/ZjkbmE5bIoE Regards, Katie McLaughlin Secretary Django Software Foundation On Sunday, 23 April 2023 at 07:57:11 UTC+10 Katie McLaughlin wrote: > With the completion of the Django 4.x major release cycle and in > accordance with DEP-0010 > <https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#process-of-selecting-the-technical-board>, > > it is now time to collect candidates for the Django Technical Board. > > Technical board candidates must demonstrate: > >- A history of technical contributions to Django or the Django >ecosystem. This history MUST begin at least 18 months prior to the >individual's candidacy for the Technical Board. >- A history of participation in Django's development outside of >contributions merged to the https://github.com/django/django/ >repository. This may include, but is not restricted to: > - Participation in discussions on the django-developers mailing > list or Django Forum. > - Reviewing and offering feedback on pull requests in the Django > source-code repository > - Assisting in triage and management of the Django bug tracker. >- A history of recent engagement with the direction and development of >Django. Such engagement MUST have occurred within a period of no more than >two years prior to the individual's candidacy for the Technical Board. > > > To register your candidacy, we require you to enter your name, email, and > a bio/evidence of qualifications. The candidacy form has optional fields > for your GitHub, Twitter, and website which can be useful for evaluating > your qualifications. > > Your email address will only be used by the DSF to contact you related to > the election and process and will not be shared publicly. > > Registration for Candidates will end on April 28th, 2023 AoE. > > Please register using this form <https://forms.gle/LdbwqDu2QynDu8MF7>. > > If you have any questions about the election, please see the post on > djangoproject.com for contact details: > https://www.djangoproject.com/weblog/2023/apr/22/technical-board-candidate-registration/ > -- 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/1877360d-0542-4dbc-a759-55b56d279f3cn%40googlegroups.com.
Django 5.x Steering Council Candidate Registration
With the completion of the Django 4.x major release cycle and in accordance with DEP-0010 <https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#process-of-selecting-the-technical-board> and DEP-0012 <https://github.com/django/deps/blob/main/accepted/0012-steering-council.rst#specification>, it is now time to collect candidates for the Django Steering Council. Steering council candidates must demonstrate: - A history of substantive contributions to Django or the Django ecosystem. This history must begin at least 18 months prior to the individual's candidacy for the Steering Council, and include substantive contributions in at least two of these bullet points: - Code contributions on Django projects or major third-party packages in the Django ecosystem - Reviewing pull requests and/or triaging Django project tickets - Documentation, tutorials or blog posts - Discussions about Django on the django-developers mailing list or the Django Forum - Running Django-related events or user groups - A history of engagement with the direction and future of Django. This does not need to be recent, but candidates who have not engaged in the past three years must still demonstrate an understanding of Django's changes and direction within those three years. To register your candidacy, we require you to enter your name, email, and a bio/evidence of qualifications. The candidacy form has optional fields for your GitHub, Twitter, and website which can be useful for evaluating your qualifications. Your email address will only be used by the DSF to contact you related to the election and process and will not be shared publicly. Registration for Candidates will end on April 30th, 2023 AoE. Please register using this form <https://forms.gle/LdbwqDu2QynDu8MF7>. If you have questions about the election please see the post on djangoproject.com for contact details: https://www.djangoproject.com/weblog/2023/apr/22/steering-council-candidate-registration/ *Please note: A previous version of this post used the term "Technical Board" with the candidacy requirements in DEP-0010. It has since been updated to reflect the requirements in DEP-0012, which updates DEP-0010. Additional time has been added to the candidacy nomination window to compensate.* -- 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/b2d38401-e527-437d-aed3-c08e7b470a9cn%40googlegroups.com.
Django 5.x Technical Board Candidate Registration
With the completion of the Django 4.x major release cycle and in accordance
with DEP-0010
<https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#process-of-selecting-the-technical-board>,
it is now time to collect candidates for the Django Technical Board.
Technical board candidates must demonstrate:
- A history of technical contributions to Django or the Django
ecosystem. This history MUST begin at least 18 months prior to the
individual's candidacy for the Technical Board.
- A history of participation in Django's development outside of
contributions merged to the https://github.com/django/django/
repository. This may include, but is not restricted to:
- Participation in discussions on the django-developers mailing list
or Django Forum.
- Reviewing and offering feedback on pull requests in the Django
source-code repository
- Assisting in triage and management of the Django bug tracker.
- A history of recent engagement with the direction and development of
Django. Such engagement MUST have occurred within a period of no more than
two years prior to the individual's candidacy for the Technical Board.
To register your candidacy, we require you to enter your name, email, and a
bio/evidence of qualifications. The candidacy form has optional fields for
your GitHub, Twitter, and website which can be useful for evaluating your
qualifications.
Your email address will only be used by the DSF to contact you related to
the election and process and will not be shared publicly.
Registration for Candidates will end on April 28th, 2023 AoE.
Please register using this form <https://forms.gle/LdbwqDu2QynDu8MF7>.
If you have any questions about the election, please see the post on
djangoproject.com for contact
details:
https://www.djangoproject.com/weblog/2023/apr/22/technical-board-candidate-registration/
--
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/c91632a5-de61-4547-9c76-01eb8b5d973fn%40googlegroups.com.
Re: Production Django use and "real ip"
> Are there any deployment scenarios where META.REMOTE_ADDR is ever even correct? Yes, when running a WSGI server that faces the internet, with no intermediate proxies. On Wed, Apr 19, 2023 at 3:51 PM Arthur Pemberton wrote: > At this point, I'm not even suggesting that Django handle this internally. > I'm suggesting that the behaviour/expectation be documented, at least in > the deployment guide. > > Are there any deployment scenarios where META.REMOTE_ADDR is ever even > correct? > > Arthur Pemberton > > On Wed, Apr 19, 2023 at 3:37 AM 'st...@jigsawtech.co.uk' via Django > developers (Contributions to Django itself) < > django-developers@googlegroups.com> wrote: > >> As someone whose worked on various projects in different languages over >> the last 15 years that heavily involved deciphering IP sent in headers to >> try to determine the "real" IP address of a connection, I would urge >> caution with anything around determining a "real IP". There is no standard >> in terms of where to look and what to trust. The X-FORWARDED-FOR is not >> always right, can easily be spoofed, it can include multiple IPs of which >> the order is not consistent. Sometimes the left most element is the first >> and "true IP", sometimes it's the right, sometimes its a value in the >> middle. It all depends what's included, what appended to the request, what >> the values are and what you want to trust/ignore. I've seen requests that >> include internal network IPs, then router/gateway IPs, proxy IPs and load >> balancers all within that head all in different orders. It's especially >> messy when dealing with requests on mobile network where the carrier uses >> proxies, sometimes 3rd parties, and where your website is hosted behind >> both load balancers and webserver as each may manipulate the header in >> different ways. >> >> One of the best packages within the Django eco-system for trying to >> identify a users actual external IP that I've come across is >> django-ipware <https://github.com/un33k/django-ipware>. It allows you to >> choose the precedence order that matches your use case, yo have private IP >> prefixes, to configure how many proxies you wish to ignore etc. They also >> have a handy notice/disclaimer >> <https://github.com/un33k/django-ipware/blob/master/README.md#Notice> on >> the subject. >> >> IMO Django core should leave this 3rd party packages and individual >> deployments to decide and determine what they deem as being the source of >> the "real IP" for their individual project. >> >> >> >> On Friday, 14 April 2023 at 10:13:22 UTC+1 Adam Johnson wrote: >> >>> It's surprisingly complex to interpret x-forwarded-for: >>> https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ . >>> We will never be able to safely add automated handling. >>> >>> I *guess* we could add a note to the deployment guide like "check your >>> HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards >>> making the guide too long, and filled with irrelevant details. Most sites >>> don't care about recording the user's IP. On those that do, it should be >>> easy enough to discover the setting. >>> >>> On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton >>> wrote: >>> >>>> I have read previous discussions (most recent I could find was Dec 2013 >>>> [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the >>>> "real" IP address of an HttpRequest. From what I can see, currently there >>>> is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django. >>>> >>>> However, I do notice that Django acknowledges `X_FORWARDED_HOST`, >>>> `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO` >>>> (though SECURE_PROXY_SSL_HEADER). >>>> >>>> If there is still opposition to having some built-in handling for >>>> `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at >>>> least mention the need for the developer to handle this explicitly. >>>> >>>> Regards, >>>> Arthur P. >>>> >>>> >>>> >>>> [1] >>>> https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J >>>> [2] https://docs.djangoproject.com/en/4.1/howto/deployment/ >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Dja
Re: Production Django use and "real ip"
At this point, I'm not even suggesting that Django handle this internally. I'm suggesting that the behaviour/expectation be documented, at least in the deployment guide. Are there any deployment scenarios where META.REMOTE_ADDR is ever even correct? Arthur Pemberton On Wed, Apr 19, 2023 at 3:37 AM 'st...@jigsawtech.co.uk' via Django developers (Contributions to Django itself) < django-developers@googlegroups.com> wrote: > As someone whose worked on various projects in different languages over > the last 15 years that heavily involved deciphering IP sent in headers to > try to determine the "real" IP address of a connection, I would urge > caution with anything around determining a "real IP". There is no standard > in terms of where to look and what to trust. The X-FORWARDED-FOR is not > always right, can easily be spoofed, it can include multiple IPs of which > the order is not consistent. Sometimes the left most element is the first > and "true IP", sometimes it's the right, sometimes its a value in the > middle. It all depends what's included, what appended to the request, what > the values are and what you want to trust/ignore. I've seen requests that > include internal network IPs, then router/gateway IPs, proxy IPs and load > balancers all within that head all in different orders. It's especially > messy when dealing with requests on mobile network where the carrier uses > proxies, sometimes 3rd parties, and where your website is hosted behind > both load balancers and webserver as each may manipulate the header in > different ways. > > One of the best packages within the Django eco-system for trying to > identify a users actual external IP that I've come across is django-ipware > <https://github.com/un33k/django-ipware>. It allows you to choose the > precedence order that matches your use case, yo have private IP prefixes, > to configure how many proxies you wish to ignore etc. They also have a > handy notice/disclaimer > <https://github.com/un33k/django-ipware/blob/master/README.md#Notice> on > the subject. > > IMO Django core should leave this 3rd party packages and individual > deployments to decide and determine what they deem as being the source of > the "real IP" for their individual project. > > > > On Friday, 14 April 2023 at 10:13:22 UTC+1 Adam Johnson wrote: > >> It's surprisingly complex to interpret x-forwarded-for: >> https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ . >> We will never be able to safely add automated handling. >> >> I *guess* we could add a note to the deployment guide like "check your >> HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards >> making the guide too long, and filled with irrelevant details. Most sites >> don't care about recording the user's IP. On those that do, it should be >> easy enough to discover the setting. >> >> On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton wrote: >> >>> I have read previous discussions (most recent I could find was Dec 2013 >>> [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the >>> "real" IP address of an HttpRequest. From what I can see, currently there >>> is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django. >>> >>> However, I do notice that Django acknowledges `X_FORWARDED_HOST`, >>> `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO` >>> (though SECURE_PROXY_SSL_HEADER). >>> >>> If there is still opposition to having some built-in handling for >>> `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at >>> least mention the need for the developer to handle this explicitly. >>> >>> Regards, >>> Arthur P. >>> >>> >>> >>> [1] >>> https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J >>> [2] https://docs.djangoproject.com/en/4.1/howto/deployment/ >>> >>> -- >>> 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-develop...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> >> -- > Yo
Re: Production Django use and "real ip"
As someone whose worked on various projects in different languages over the last 15 years that heavily involved deciphering IP sent in headers to try to determine the "real" IP address of a connection, I would urge caution with anything around determining a "real IP". There is no standard in terms of where to look and what to trust. The X-FORWARDED-FOR is not always right, can easily be spoofed, it can include multiple IPs of which the order is not consistent. Sometimes the left most element is the first and "true IP", sometimes it's the right, sometimes its a value in the middle. It all depends what's included, what appended to the request, what the values are and what you want to trust/ignore. I've seen requests that include internal network IPs, then router/gateway IPs, proxy IPs and load balancers all within that head all in different orders. It's especially messy when dealing with requests on mobile network where the carrier uses proxies, sometimes 3rd parties, and where your website is hosted behind both load balancers and webserver as each may manipulate the header in different ways. One of the best packages within the Django eco-system for trying to identify a users actual external IP that I've come across is django-ipware <https://github.com/un33k/django-ipware>. It allows you to choose the precedence order that matches your use case, yo have private IP prefixes, to configure how many proxies you wish to ignore etc. They also have a handy notice/disclaimer <https://github.com/un33k/django-ipware/blob/master/README.md#Notice> on the subject. IMO Django core should leave this 3rd party packages and individual deployments to decide and determine what they deem as being the source of the "real IP" for their individual project. On Friday, 14 April 2023 at 10:13:22 UTC+1 Adam Johnson wrote: > It's surprisingly complex to interpret x-forwarded-for: > https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ . We > will never be able to safely add automated handling. > > I *guess* we could add a note to the deployment guide like "check your > HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards > making the guide too long, and filled with irrelevant details. Most sites > don't care about recording the user's IP. On those that do, it should be > easy enough to discover the setting. > > On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton wrote: > >> I have read previous discussions (most recent I could find was Dec 2013 >> [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the >> "real" IP address of an HttpRequest. From what I can see, currently there >> is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django. >> >> However, I do notice that Django acknowledges `X_FORWARDED_HOST`, >> `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO` >> (though SECURE_PROXY_SSL_HEADER). >> >> If there is still opposition to having some built-in handling for >> `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at >> least mention the need for the developer to handle this explicitly. >> >> Regards, >> Arthur P. >> >> >> >> [1] >> https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J >> [2] https://docs.djangoproject.com/en/4.1/howto/deployment/ >> >> -- >> 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-develop...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- 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/4f06664d-135e-4eb2-86ec-11eccf4cb495n%40googlegroups.com.
Re: Production Django use and "real ip"
It's surprisingly complex to interpret x-forwarded-for: https://www.brainonfire.net/blog/2022/03/04/understanding-using-xff/ . We will never be able to safely add automated handling. I *guess* we could add a note to the deployment guide like "check your HTTP_X_FORWARDED_FOR setting". I'm concerned it would be a step towards making the guide too long, and filled with irrelevant details. Most sites don't care about recording the user's IP. On those that do, it should be easy enough to discover the setting. On Sat, Apr 1, 2023 at 4:39 AM Arthur Pemberton wrote: > I have read previous discussions (most recent I could find was Dec 2013 > [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the > "real" IP address of an HttpRequest. From what I can see, currently there > is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django. > > However, I do notice that Django acknowledges `X_FORWARDED_HOST`, > `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO` > (though SECURE_PROXY_SSL_HEADER). > > If there is still opposition to having some built-in handling for > `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at > least mention the need for the developer to handle this explicitly. > > Regards, > Arthur P. > > > > [1] > https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J > [2] https://docs.djangoproject.com/en/4.1/howto/deployment/ > > -- > 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/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CAMyDDM2zStXs8eHk5icicfdfGJtYT%3DeQaQK%3DHST0cmL4Yd1WCg%40mail.gmail.com.
Re: Django "makemigrations -- update" donot working
Indeed, David is right. The --update flag is intended for developing a feature branch and adding extra changes to a work-in-progress migration. This is why it requires the migration to not be applied. On Sun, Apr 9, 2023 at 9:20 PM David Wobrock wrote: > Hi, > > As you can see, the error message seems quite clear: > > Cannot update applied migration 'authentication.0001_initial'. > One cannot edit a migration that has already been applied. > To update it, you can undo it by running "migrate authentication zero" and > then run "makemigrations --update" again. > > I do not think it's a bug in Django. > > Cheers, > David > > Le sam. 8 avr. 2023 à 16:50, Muhammad Juwaini Abdul Rahman < > juwa...@gmail.com> a écrit : > >> Do you need that '--update' parameter? >> >> On Fri, 7 Apr 2023 at 05:57, Saifullah Shahen >> wrote: >> >>> in my custom user model, initially, my model looks like this >>> >>> class User(AbstractUser, BaseModelWithUUID): >>> phone = models.CharField(max_length=11, >>> validators=[validate_phone_number]) >>> I do command "makemigrations" which create a initial migration file >>> >>> but after updating my model like this >>> >>> class User(AbstractUser, BaseModelWithUUID): >>> phone = models.CharField(max_length=11, >>> validators=[validate_phone_number]) >>> name = models.CharField(max_length=255) >>> >>> after adding a field "name" when i run "makemigrations --update" it >>> shows a error: >>> >>> CommandError: Cannot update applied migration >>> 'authentication.0001_initial'. >>> >>> -- >>> 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/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> >> -- >> 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/CAFKhtoS4wer5PRzA-G%3D1MvOMV8S2oGnMRZ83PTQ6fy3DukWzdQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAFKhtoS4wer5PRzA-G%3D1MvOMV8S2oGnMRZ83PTQ6fy3DukWzdQ%40mail.gmail.com?utm_medium=email_source=footer> >> . >> > -- > 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/CAHS_w9bXLJ0Cj30yU%2BLw%2BATofw%2B-kkeH2NYF8YCcv6ax303xeg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAHS_w9bXLJ0Cj30yU%2BLw%2BATofw%2B-kkeH2NYF8YCcv6ax303xeg%40mail.gmail.com?utm_medium=email_source=footer> > . > -- 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/CAMyDDM0dVF5qgiPGHTo-MND86PAPVKwhmm4ROw_pCnStJbgqTw%40mail.gmail.com.
Re: Django "makemigrations -- update" donot working
Hi, As you can see, the error message seems quite clear: > Cannot update applied migration 'authentication.0001_initial'. One cannot edit a migration that has already been applied. To update it, you can undo it by running "migrate authentication zero" and then run "makemigrations --update" again. I do not think it's a bug in Django. Cheers, David Le sam. 8 avr. 2023 à 16:50, Muhammad Juwaini Abdul Rahman < juwa...@gmail.com> a écrit : > Do you need that '--update' parameter? > > On Fri, 7 Apr 2023 at 05:57, Saifullah Shahen > wrote: > >> in my custom user model, initially, my model looks like this >> >> class User(AbstractUser, BaseModelWithUUID): >> phone = models.CharField(max_length=11, >> validators=[validate_phone_number]) >> I do command "makemigrations" which create a initial migration file >> >> but after updating my model like this >> >> class User(AbstractUser, BaseModelWithUUID): >> phone = models.CharField(max_length=11, >> validators=[validate_phone_number]) >> name = models.CharField(max_length=255) >> >> after adding a field "name" when i run "makemigrations --update" it shows >> a error: >> >> CommandError: Cannot update applied migration >> 'authentication.0001_initial'. >> >> -- >> 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/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- > 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/CAFKhtoS4wer5PRzA-G%3D1MvOMV8S2oGnMRZ83PTQ6fy3DukWzdQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFKhtoS4wer5PRzA-G%3D1MvOMV8S2oGnMRZ83PTQ6fy3DukWzdQ%40mail.gmail.com?utm_medium=email_source=footer> > . > -- 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/CAHS_w9bXLJ0Cj30yU%2BLw%2BATofw%2B-kkeH2NYF8YCcv6ax303xeg%40mail.gmail.com.
Re: Opensource Django Project
Yes. See https://docs.djangoproject.com/en/dev/internals/contributing/new-contributors/ On Saturday, April 8, 2023 at 10:50:17 AM UTC-4 Naresh Pahariya wrote: > Me too... > > I think there is a documentation for django contribution. > > Thanks, > Naresh > > On Sat, 8 Apr, 2023, 3:51 pm Dipankar, wrote: > >> Hi All, >> >> I want to contribute to the Open Source Django Project as a developer. >> Can anybody help me please? >> >> -- >> Warm Regards, >> Dipankar B. >> >> -- >> 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-develop...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAFdBwp-m8nUVrP0Jd4o16XwBEOOOkE9ys42yYXRze58aUQZ4qQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-developers/CAFdBwp-m8nUVrP0Jd4o16XwBEOOOkE9ys42yYXRze58aUQZ4qQ%40mail.gmail.com?utm_medium=email_source=footer> >> . >> > -- 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/bb49f44b-056f-4e9d-95b2-c7f0462ddcd0n%40googlegroups.com.
Re: Django "makemigrations -- update" donot working
Do you need that '--update' parameter? On Fri, 7 Apr 2023 at 05:57, Saifullah Shahen wrote: > in my custom user model, initially, my model looks like this > > class User(AbstractUser, BaseModelWithUUID): > phone = models.CharField(max_length=11, > validators=[validate_phone_number]) > I do command "makemigrations" which create a initial migration file > > but after updating my model like this > > class User(AbstractUser, BaseModelWithUUID): > phone = models.CharField(max_length=11, > validators=[validate_phone_number]) > name = models.CharField(max_length=255) > > after adding a field "name" when i run "makemigrations --update" it shows > a error: > > CommandError: Cannot update applied migration > 'authentication.0001_initial'. > > -- > 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/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CAFKhtoS4wer5PRzA-G%3D1MvOMV8S2oGnMRZ83PTQ6fy3DukWzdQ%40mail.gmail.com.
Re: Opensource Django Project
Me too... I think there is a documentation for django contribution. Thanks, Naresh On Sat, 8 Apr, 2023, 3:51 pm Dipankar, wrote: > Hi All, > > I want to contribute to the Open Source Django Project as a developer. > Can anybody help me please? > > -- > Warm Regards, > Dipankar B. > > -- > 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/CAFdBwp-m8nUVrP0Jd4o16XwBEOOOkE9ys42yYXRze58aUQZ4qQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFdBwp-m8nUVrP0Jd4o16XwBEOOOkE9ys42yYXRze58aUQZ4qQ%40mail.gmail.com?utm_medium=email_source=footer> > . > -- 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/CAMpxr5pPUqAtGdLe3dfErf_wDp7Bqu9YoeHcvh%3DN3sQWahEsfg%40mail.gmail.com.
Opensource Django Project
Hi All, I want to contribute to the Open Source Django Project as a developer. Can anybody help me please? -- Warm Regards, Dipankar B. -- 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/CAFdBwp-m8nUVrP0Jd4o16XwBEOOOkE9ys42yYXRze58aUQZ4qQ%40mail.gmail.com.
Re: Django "makemigrations -- update" donot working
Please follow https://docs.djangoproject.com/en/4.1/topics/auth/customizing/ On Fri, Apr 7, 2023 at 3:27 AM Saifullah Shahen wrote: > in my custom user model, initially, my model looks like this > > class User(AbstractUser, BaseModelWithUUID): > phone = models.CharField(max_length=11, > validators=[validate_phone_number]) > I do command "makemigrations" which create a initial migration file > > but after updating my model like this > > class User(AbstractUser, BaseModelWithUUID): > phone = models.CharField(max_length=11, > validators=[validate_phone_number]) > name = models.CharField(max_length=255) > > after adding a field "name" when i run "makemigrations --update" it shows > a error: > > CommandError: Cannot update applied migration > 'authentication.0001_initial'. > > -- > 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/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com?utm_medium=email_source=footer> > . > -- Warm Regards, Dipankar B. -- 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/CAFdBwp8DK5SgXgzQde9bS_Uf8tMvAFdfKQR%2BTgecyptYvqeA%3Dg%40mail.gmail.com.
Django "makemigrations -- update" donot working
in my custom user model, initially, my model looks like this class User(AbstractUser, BaseModelWithUUID): phone = models.CharField(max_length=11, validators=[validate_phone_number]) I do command "makemigrations" which create a initial migration file but after updating my model like this class User(AbstractUser, BaseModelWithUUID): phone = models.CharField(max_length=11, validators=[validate_phone_number]) name = models.CharField(max_length=255) after adding a field "name" when i run "makemigrations --update" it shows a error: CommandError: Cannot update applied migration 'authentication.0001_initial'. -- 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/793fee18-1231-456b-8d91-f976bebad5e2n%40googlegroups.com.
Re: Issue with get_FOO_display not working in Django admin
At this point I'll let others chime in with their opinion on whether this is something that needs to change because: 1. I rarely use admin 2. I've never really had the need to override a choice's display over those supplied via `choices` :) On Wed, 5 Apr 2023 at 19:05, 'Ibrahim Abou Elenein' via Django developers (Contributions to Django itself) wrote: > Isn't this some sort of duplication? why not just use it instead of > writing its logic again? > > -- 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/CADyZw-7r%3D%3Dwybp8XWp7tEdAOYWuhKucXGE_Kjq0twTy%3DN8KWPg%40mail.gmail.com.
Re: Issue with get_FOO_display not working in Django admin
Isn't this some sort of duplication? why not just use it instead of writing its logic again? On Wednesday, April 5, 2023 at 7:12:48 AM UTC+2 David Sanders wrote: > Hi Ibrahim, > > get_FOO_display() isn't intended to be overridden like that, it's just a > convenience method for use in templates/whatever that refers to the > underlying flatchoices. > > For clarity, please see the documentation: > https://docs.djangoproject.com/en/4.2/ref/models/instances/#django.db.models.Model.get_FOO_display > > Kind regards, > David > > On Wed, 5 Apr 2023 at 09:10, 'Ibrahim Abou Elenein' via Django developers > (Contributions to Django itself) wrote: > >> Dear All, >> >> I am writing to report an issue I encountered while working with Django >> admin. I had a model with a field that uses Choices as follows: >> >> ``` >> status = FSMField(default=STATUSES.PENDING, choices=STATUSES, >> protected=True) >> ``` >> I overrode the get_status_display method, but to my surprise, it did not >> have any effect in the Django admin. >> >> Upon investigating Django's code, I found the following method in >> contrib.admin >> >> ``` >> def display_for_field(value, field, empty_value_display): >> from django.contrib.admin.templatetags.admin_list import _boolean_icon >> >> if getattr(field, "flatchoices", None): >> return dict(field.flatchoices).get(value, empty_value_display) >> ``` >> I noticed that this method uses flatchoices to get the display value for >> fields with choices. However, it does not take into account any custom >> display methods that may have been defined for the field. >> >> To resolve this issue, I modified the code to use get_FOO_display instead >> of flatchoices as follows: >> >> ``` >> def display_for_field(value, field, empty_value_display, model=None): >> from django.contrib.admin.templatetags.admin_list import _boolean_icon >> >> if getattr(field, "flatchoices", None): >> if model: >> return getattr(model, "get_%s_display" % field.name)() >> return dict(field.flatchoices).get(value, empty_value_display) >> ``` >> This modification allowed my custom display method to work as expected in >> the Django admin. >> >> However, I am curious to know why Django's code behaves this way and how >> I can make use of this behavior in my application. >> >> Thank you for your attention to this matter. >> >> Sincerely, >> Ibrahim. >> >> -- >> 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-develop...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/4f432f39-b959-422e-b062-5db54722b18en%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/4f432f39-b959-422e-b062-5db54722b18en%40googlegroups.com?utm_medium=email_source=footer> >> . >> > -- 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/f60ef476-412e-4739-b43e-15e181d7a986n%40googlegroups.com.
Re: Issue with get_FOO_display not working in Django admin
Hi Ibrahim, get_FOO_display() isn't intended to be overridden like that, it's just a convenience method for use in templates/whatever that refers to the underlying flatchoices. For clarity, please see the documentation: https://docs.djangoproject.com/en/4.2/ref/models/instances/#django.db.models.Model.get_FOO_display Kind regards, David On Wed, 5 Apr 2023 at 09:10, 'Ibrahim Abou Elenein' via Django developers (Contributions to Django itself) wrote: > Dear All, > > I am writing to report an issue I encountered while working with Django > admin. I had a model with a field that uses Choices as follows: > > ``` > status = FSMField(default=STATUSES.PENDING, choices=STATUSES, > protected=True) > ``` > I overrode the get_status_display method, but to my surprise, it did not > have any effect in the Django admin. > > Upon investigating Django's code, I found the following method in > contrib.admin > > ``` > def display_for_field(value, field, empty_value_display): > from django.contrib.admin.templatetags.admin_list import _boolean_icon > > if getattr(field, "flatchoices", None): > return dict(field.flatchoices).get(value, empty_value_display) > ``` > I noticed that this method uses flatchoices to get the display value for > fields with choices. However, it does not take into account any custom > display methods that may have been defined for the field. > > To resolve this issue, I modified the code to use get_FOO_display instead > of flatchoices as follows: > > ``` > def display_for_field(value, field, empty_value_display, model=None): > from django.contrib.admin.templatetags.admin_list import _boolean_icon > > if getattr(field, "flatchoices", None): > if model: > return getattr(model, "get_%s_display" % field.name)() > return dict(field.flatchoices).get(value, empty_value_display) > ``` > This modification allowed my custom display method to work as expected in > the Django admin. > > However, I am curious to know why Django's code behaves this way and how I > can make use of this behavior in my application. > > Thank you for your attention to this matter. > > Sincerely, > Ibrahim. > > -- > 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/4f432f39-b959-422e-b062-5db54722b18en%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/4f432f39-b959-422e-b062-5db54722b18en%40googlegroups.com?utm_medium=email_source=footer> > . > -- 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/CADyZw-65tb_3LZq0D%2BVbU4Dh71V%3DGMRWDeFHCuhT8pDcChVn_w%40mail.gmail.com.
Issue with get_FOO_display not working in Django admin
Dear All, I am writing to report an issue I encountered while working with Django admin. I had a model with a field that uses Choices as follows: ``` status = FSMField(default=STATUSES.PENDING, choices=STATUSES, protected=True) ``` I overrode the get_status_display method, but to my surprise, it did not have any effect in the Django admin. Upon investigating Django's code, I found the following method in contrib.admin ``` def display_for_field(value, field, empty_value_display): from django.contrib.admin.templatetags.admin_list import _boolean_icon if getattr(field, "flatchoices", None): return dict(field.flatchoices).get(value, empty_value_display) ``` I noticed that this method uses flatchoices to get the display value for fields with choices. However, it does not take into account any custom display methods that may have been defined for the field. To resolve this issue, I modified the code to use get_FOO_display instead of flatchoices as follows: ``` def display_for_field(value, field, empty_value_display, model=None): from django.contrib.admin.templatetags.admin_list import _boolean_icon if getattr(field, "flatchoices", None): if model: return getattr(model, "get_%s_display" % field.name)() return dict(field.flatchoices).get(value, empty_value_display) ``` This modification allowed my custom display method to work as expected in the Django admin. However, I am curious to know why Django's code behaves this way and how I can make use of this behavior in my application. Thank you for your attention to this matter. Sincerely, Ibrahim. -- 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/4f432f39-b959-422e-b062-5db54722b18en%40googlegroups.com.
Django 4.2 released
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2023/apr/03/django-42-released/ -- 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/7dbf7d40-41a3-832a-ef7f-968bdf5490c1%40gmail.com.
media files are autmoatically deleted django deployment
hell all , <https://stackoverflow.com/posts/75834665/timeline> question: latest code deploying in the jenkins server after checkeing in server p existing media images are not displayed(retrieved) and updated code changes working perfectly and uploading new images displayed. except result: when i deployed latest code in server do not delete media files -- 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/74bf2543-76f0-43cf-98c2-32e794bff442n%40googlegroups.com.
Production Django use and "real ip"
I have read previous discussions (most recent I could find was Dec 2013 [1] ) on the inclusion of `HTTP_X_FORWARDED_FOR` based logic to get the "real" IP address of an HttpRequest. From what I can see, currently there is currently no automatic handling of `HTTP_X_FORWARDED_FOR` in Django. However, I do notice that Django acknowledges `X_FORWARDED_HOST`, `X_FORWARDED_PORT` and (indirectly) `X_FORWARDED_PROTO` (though SECURE_PROXY_SSL_HEADER). If there is still opposition to having some built-in handling for `HTTP_X_FORWARDED_FOR`, I think that the deployment guide [1] should at least mention the need for the developer to handle this explicitly. Regards, Arthur P. [1] https://groups.google.com/g/django-developers/c/J5O28jB5D3Q/m/KLLgllFS7v0J [2] https://docs.djangoproject.com/en/4.1/howto/deployment/ -- 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/96d735ee-4ac0-4bf4-9850-a49f287e6e2an%40googlegroups.com.
