Django bugfix releases issued: 4.2.13 and 5.0.6

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2024/may/07/bugfix-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

Django bugfix releases issued: 4.2.12 and 5.0.5

Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2024/may/06/bugfix-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

Re: Ticket #34646 Ordering a Django admin column based on multiple model fields

The proposed patch adds very little extra API surface. Django admin in fact already support this, but for this arbitrary restriction in `get_ordering_field`. The patch just makes it possible to pass a list down to `get_queryset` method. I would argue that this patch removes a special case in

Re: Ticket #34646 Ordering a Django admin column based on multiple model fields

Could you re-consider it please? it is really important, and we need it. I have started another project where I need to create a computed column (used_invitations / max_invitations) Best regards On Friday, June 23, 2023 at 10:39:51 AM UTC+3 Mubarak Alrashidi wrote: > I really hope the

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

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

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

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:

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

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

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

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

Re: Fellow Reports - March 2024

March 25-26 *Triaged:* https://code.djangoproject.com/ticket/35330 - The update of related objects fails in the admin when the related model is camel case. (accepted) https://code.djangoproject.com/ticket/35331 - Adding a new related entry using the "+" sign from M2M field doesn't

Re: Intermittent IntegrityError on Model Save with auto_now and auto_now_add Fields

Looks like this issue isn't affecting lots of folks, since nobody is piping up, so I'll just add that if anybody arrives here in the future, we'll be tracking this in a public issue here: https://github.com/freelawproject/courtlistener/issues/3359 My theory is it has something to do with race

Re: Fellow Reports - March 2024

Week ending March 24 *Triaged:* https://code.djangoproject.com/ticket/35312 - FileNotFoundError escapes from run_formatters() (invalid) https://code.djangoproject.com/ticket/34059 - Validation of check constraints on JSONField key transforms with None produces invalid SQL on

Re: Fellow Reports - March 2024

Week ending March 17 *Triaged:* https://code.djangoproject.com/ticket/35287 - manage createsuperuser too restrictive (duplicate) https://code.djangoproject.com/ticket/35291 - Whitenoise Not Working when DEBUG = FALSE - Django - Hosting Static Files (duplicate)

RE: Intermittent IntegrityError on Model Save with auto_now and auto_now_add Fields

Hi Bill, We ended up using a package called Django-audit-log: https://pypi.org/project/django-audit-log/. It’s outdated now, but we used the source code for their CreatingUserField, LastUserField, CreationDateTimeField, and ModificationDateTimeField. More modern packages may have enhanced

Intermittent IntegrityError on Model Save with auto_now and auto_now_add Fields

Hello Django community, We are reaching out after encountering a persistent and elusive issue that manifests as an IntegrityError during the save operation of a Django model. This problem has been sporadically occurring since last year and has successfully stumped four seasoned Django

Fellow Reports - March 2024

Week ending March 10 *Triaged:* https://code.djangoproject.com/ticket/35268 - Migrations raise UnicodeDecodeError on PostgreSQL. (needsinfo) https://code.djangoproject.com/ticket/35266 - Optimize RelatedField._check_clashes() (accepted) https://code.djangoproject.com/ticket/35267 - Correct

Re: Use of TIME_INPUT_FORMATS in TimeField

USE_I18N does not disable localization, but internationalization. USE_L10N was the setting to enable/disable localization, but it was deprecated in Django 4.0: https://docs.djangoproject.com/en/4.0/releases/4.0/#localization . It was removed completely in Django 5.0, in this commit:

Re: Use of TIME_INPUT_FORMATS in TimeField

Thanks, I'll look into that. But does that mean that settings.TIME_INPUT_FORMATS no longer has any use? I don't see any logic flows that lead to it being used. On Tue, Mar 5, 2024 at 3:00 AM David Sanders wrote: > Define TIME_INPUT_FORMATS in your local formats.py setup as per: >

Re: Use of TIME_INPUT_FORMATS in TimeField

Define TIME_INPUT_FORMATS in your local formats.py setup as per: https://docs.djangoproject.com/en/5.0/topics/i18n/formatting/#creating-custom-format-files On Tue, 5 Mar 2024 at 18:43, Arthur Pemberton wrote: > The documentation ( >

Use of TIME_INPUT_FORMATS in TimeField

The documentation ( https://docs.djangoproject.com/en/5.0/ref/forms/fields/#timefield) says that " the default input formats are taken from the active locale format TIME_INPUT_FORMATS key, or from TIME_INPUT_FORMATS

Re: Fellow Reports - February 2024

Week ending March 3 *Triaged:* https://code.djangoproject.com/ticket/35245 - Django freezes on DRF's APIView. (invalid) https://code.djangoproject.com/ticket/35253 - Pagination for StackedInline and TabularInline (duplicate) https://code.djangoproject.com/ticket/35251 - dumpdata

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

Re: Fellow Reports - February 2024

Week ending February 25 *Triaged:* https://code.djangoproject.com/ticket/35232 - Cache Options.verbose_name_raw (accepted) https://code.djangoproject.com/ticket/35234 - ExclusionConstraint.expressions should be checked for foreign relationship references (accepted)

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

I've found the reason why I've been thinking this wrong way. `getattr(self.get_queryset(), name)` is getting a bound method from Manager.get_queryset() which is a QuerySet class instance, while method is getting function from _queryset_class. The difference is one of them is bound method,

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

Thanks for your answer. I will continue to investigate based on your suggestions and if I find the answer I will respond again. 在2024年2月28日星期三 UTC+8 10:13:09 写道： > Hi Ryoma, a good way to investigate this would be to make the change and > see if anything breaks. > > If I understand correctly,

Re: [Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

Hi Ryoma, a good way to investigate this would be to make the change and see if anything breaks. If I understand correctly, your suggest is: -return getattr(self.get_queryset(), name)(*args, **kwargs) +return method(*args, **kwargs) In that case, running the

[Question] Why BaseManager._get_queryset_methods need use getattr(self.get_queryset(), name) in create_method

I've been reading through the Django source code the last few days. When I was reading the BaseManager source code I saw a method like this: ```python @classmethod def _get_queryset_methods(cls, queryset_class): def create_method(name, method): @wraps(method)

Synchronizing HttpRequest.headers on HttpRequest.META mutation

I bumped into this old WONTFIX. And I agree with the decision not fix it in the way proposed by OP. But the current behaviour can be very confusing: https://code.djangoproject.com/ticket/32023#comment:3 That `del ` I propose would be free if nothing has accessed `headers` yet or nothing will

Re: Deprecate CICharField, CIEmailField, CITextField

True, not the end of the world. Just ... another dependency. The NPM world has traumatized me. Many thanks for creating that. If there's nothing that can be done, it's time to move on. But worth asking. (Interestingly, even with the deprecation, historical migration fields still need to be

Re: Deprecate CICharField, CIEmailField, CITextField

I just say it: The decision certainly had good intentions, but maybe wasn't fully informed. It happens. But since we don't really have a processed to revert a deprecation, I would recommend using the django-citext package. It's a drop-in replacement with the same license as Django and a corporate

Re: Deprecate CICharField, CIEmailField, CITextField

Coming in again now that I've looked at upgrading. @Adam: your post was useful. But can you actually say you prefer the new approach? But I'm going to be honest, this is a lot of hoops and gotchas. What did we actually gain by deprecating this? I'm seeing maybe 15-20 lines of code that will

Re: Fellow Reports - February 2024

Week ending February 18 *Triaged:* https://code.djangoproject.com/ticket/35181 - behaviour of makemessage dont follow documentation (needsinfo) https://code.djangoproject.com/ticket/35185 - Daphne: websocket works locally with ws protocol, but it connects and quickly disconnects in

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

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

Re: New feature request - Run only a random subset of tests.

agreed about this is a unittest/pytest specific focus, not django. This is pretty straightforward to do with pytest, can have a custom flag and then randomize the test collection. With unittest, not sure. On Monday, February 12, 2024 at 11:36:57 AM UTC-5 Jörg Breitbart wrote: > I also think

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,

Fellow Reports - February 2024

Week ending February 11 * Triaged:* https://code.djangoproject.com/ticket/35166 - Return python-memcached support (wontfix) https://code.djangoproject.com/ticket/35168 - Problem with templates and the tag (worksforme) https://code.djangoproject.com/ticket/34917 - Links in the Django admin

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

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

Re: Testing Unmanaged Models - Using the SchemaEditor to create db tables

Hi Adam, Thanks for your response! I understand your point about unmanaged models being a niche use case of Django. I've decided to proceed with creating a package and see how it goes. The new enterContext() and other methods in unittest seem interesting. I'll definitely be using them more

Re: New feature request - Run only a random subset of tests.

I also think that your requirements are too specific to be added to django. You are prolly better suited by creating your own test picking abstraction for this, e.g. by writing custom test suite aggregates or using unittest.TestLoader.discover and going into tests of interest by your own logic

Re: New feature request - Run only a random subset of tests.

I’d be against this. I think this approach would be counterproductive in most cases due to the high probability of a false positive. Including it as a core feature is not necessary when it can be added through a third party package. On Mon, Feb 12, 2024, at 2:22 PM, אורי wrote: > Hi, > > Also,

Re: New feature request - Run only a random subset of tests.

Hi, Also, sometimes I just want to see how many tests are in a specific module, without running them. So I can just run `./tests_manage_all_sites_with_all_warnings.sh test speedy.net --test-only 0 --test-all-languages` which gives me the number of tests in speedy.net, or any module I need. There

Re: New feature request - Run only a random subset of tests.

Hi Jörg, All our tests are tested anyway with GitHub Actions. The idea is to run a subset of tests locally to catch 90% of the problems before I commit and wait 40 minutes for all the tests to run. It works most of the time. Of course the whole tests should be run before deploying to production,

Re: New feature request - Run only a random subset of tests.

Adding to my last comment: If you are looking for a more tailored unit testing with low test pressure and still high reliability - maybe coverage.py can give you enough code insights to build a tailored test index db to only run affected tests from current code changes. I am not aware of test

Re: New feature request - Run only a random subset of tests.

@Uri May I ask, whats the idea behind running a random subset of tests only? Wouldn't a Monte Carlo approach be highly unreliable, e.g. lure ppl into thinking everything is ok, but in reality the random test selection did not catch affected code paths? I mean for tests - its all about

New feature request - Run only a random subset of tests.

Django developers, I created https://code.djangoproject.com/ticket/35183 and was asked to start a discussion on the DevelopersMailingList. I'm requesting a new feature request - Run only a random subset of tests. tests - add a new argument "--test-only" (int, >=0) and If run with this argument,

Re: Testing Unmanaged Models - Using the SchemaEditor to create db tables

Hi Emmanuel Most activity from this mailing list has moved to Django Internals category on the forum: https://forum.djangoproject.com/c/internals/5 . Better to post there in future, or you could even duplicate this post. I think your approach is worth sharing in a blog post, or even a package,

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

Re: Fellow Reports - January 2024

Week ending February 4 *Triaged:* https://code.djangoproject.com/ticket/35153 - FORMAT_MODULE_PATH not acting as I expected. (accepted) https://code.djangoproject.com/ticket/35154 - QuerySet implements `contains` but not `__contains__` (wontfix)

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

Re: Fellow Reports - January 2024

Week ending January 28 *Triaged:* https://code.djangoproject.com/ticket/35132 - Django admin dark mode leaves the main container light. (worksforme) https://code.djangoproject.com/ticket/35134 - "Select all" checkbox in admin model view doesn't work in Django 5.0.1 (worksforme)

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,

Testing Unmanaged Models - Using the SchemaEditor to create db tables

Hi everyone! I'd like to get your thoughts on something. Unmanaged models mean that Django no longer handles creating and managing schema at the database level (hence the name). When running tests, this means these tables aren't created, and we can't run queries against that model. The general

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

Re: Fellow Reports - January 2024

Week ending January 21 *Triaged:* https://code.djangoproject.com/ticket/35113 - Adding urls.py file while creating new app using startapp command (duplicate) https://code.djangoproject.com/ticket/35114 - Create a tests directory instead of tests.py when a new app is created (wontfix)

Re: Transition Docs to Inline

Hi Moshe, Just so you know there are a lot more discussions about Django these days on the Django Forum than this mailing list. There are also no such things as Django lords or a governing board :) The project is consensus-driven, so doesn’t require any

Fellow Reports - January 2024

Week ending January 7 Released Django 4.2.9 and 5.0.1. *Triaged: * https://code.djangoproject.com/ticket/35073 - models.SET's callable is called when there are no objects to update. (accepted) https://code.djangoproject.com/ticket/35077 - Quering with int that has bigint in database no longer

Re: Transition Docs to Inline

I agree that the official Python docs are well maintained and achieve a tough goal - the right balance of just replaying basic interface facts on one side, or being overly prosaic on the other side. Nope, they are well balanced giving enough of both extremes to get you going, place repo code

Re: Transition Docs to Inline

On 1/11/2024 12:01 AM, Moshe Dicker wrote: I should not that I'm only being critical to improve. The docs are well written, it's just disorganized. Something I've learned over the past 47 years of reading computer documentation is that _no_ documentation is "perfect" - especially not for

Re: Transition Docs to Inline

I should not that I'm only being critical to improve. The docs are well written, it's just disorganized. I mean no disrespect, we stand on the shoulders of giant, but that doesn't mean we should stop trying to improve. On Wednesday, January 10, 2024 at 11:57:40 PM UTC-5 Mariusz Felisiak wrote:

Re: Transition Docs to Inline

Agreed with Tim. > *I'll argue that right now we don't have documentation. We just have a mix of docs and reference, resulting in a convoluted manual that doesn't fit either need.* This is a really unfair opinion (not the only one in your comment). Hundreds of folks have put a lot of effort

Re: Transition Docs to Inline

I'll argue that right now we don't have documentation. We just have a mix of docs and reference, resulting in a convoluted manual that doesn't fit either need. Django isn't some fly-by-night framework whose documentation will devolve if we move the technical reference and documentation into

Re: Transition Docs to Inline

I don't think moving docs inline is a good idea. Quoting Aymeric from 2013 regarding django.contrib.admindocs [1] summarizes my feelings: """ 1) It's called the "documentation generator", but it only operates on docstrings. This promotes the idea that docstrings are appropriate documentation,

Re: Transition Docs to Inline

Ah interesting that you mentioned django-stubs. I had good to mediocre success applying it to my own django apps. It gets the job mostly done for high level interfaces, but shows rough stub edges as soon as you have to touch lower interfaces (can only speak for the ORM section in this regard,

Re: Transition Docs to Inline

Django uses a lot of bootstrap/runtime patching under the hood, from custom metaclasses, explicit injection pattern up to proxies at various ends. I understand this is true on low level APIs and on classes we implement ourselves (Like passing the correct arguments when creating a django

Re: Transition Docs to Inline

+1 on the idea for better inline docs, would be some relief for IDEs figuring out a proper interface story boosting dev speed for rarely used aspects, where currently one would have to search through the prosaic online docs or end up browsing the django source. On the other hand I am not

Re: Transition Docs to Inline

Django’s API Reference is more like a guide than an actual Reference at this point. I’m proposing as follows: 1. We take any part of the reference that is short and to the point and put it in a docstring. I think going the FastAPI route on this would be best, A guide and a

Re: Transition Docs to Inline

I will address each part of your questions. Why is consulting the online documentation insufficient? I think most developers build Django projects while referencing the online documentation rather than while reading Django’s source code. Having documentation available within the IDE really

Re: Transition Docs to Inline

Hi Moshe, Why is consulting the online documentation insufficient? I think most developers build Django projects while referencing the online documentation rather than while reading Django's source code. What sort of documentation would be inlined? Would this require a large amount of

Transition Docs to Inline

Due to the dynamic nature of Python, features aren’t obvious. Developers don’t know what features a class has unless they dig through the convoluted source code themselves or going online to check the documentation. For example when implementing a `forms.ModelForm` hovering over it reveals

Re: Fellow Reports - December 2023

Week ending December 31 *Triaged:*https://code.djangoproject.com/ticket/35062 - Update csrf.py to check request.POST if request.method is not GET (invalid) https://code.djangoproject.com/ticket/35059 - ASGI server leaves stale DB connections (needsinfo)

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

Re: Fellow Reports - December 2023

Week ending December 24 *Triaged:* https://code.djangoproject.com/ticket/35046 - BlankChoiceIterator causes AttributeError for some existing packages and projects (invalid) https://code.djangoproject.com/ticket/35050 - Issue filtering on FilteredRelation with F object (accepted)

Re: Deprecate CICharField, CIEmailField, CITextField

I only started trying to move to collations instead of citext recently, and it broke the regex validation as as non deterministic collation can't support regex validator, like what, why are we replacing something with an alternative that actually cant do the job as a replacement On Thu, 21 Dec

Re: Deprecate CICharField, CIEmailField, CITextField

This breaks search_fields. I can annotate a deterministic collation for simple fields. I don't understand why I have to do workarounds to get builtin stuff to work. There's no workaround I can figure out across joins though. I have `search_fields = ['owners__email']`. Using an annotated field

Re: Add a PersistedTemporaryFileUploadHandler for file upload

My first reflex to this is -1 for a simple reason: the persistence layer in django is meant to be db-driven. The upload logic is transient for that reason, and nothing stops you from creating a better controlled file upload handling with a model holding those files before entering your real

Fellow Reports - December 2023

Week ending December 10 Released Django 4.2.8. *Triaged: * https://code.djangoproject.com/ticket/35008 - Minifiers break django contrib admins UI (accepted) https://code.djangoproject.com/ticket/35009 - set_language doesn't work with prefix_default_language=False (duplicate)

Add a PersistedTemporaryFileUploadHandler for file upload

*Description:* Using the *PersistedTemporaryFileUploadHandler* upload handler, Django will write the uploaded file to a temporary file stored in your system's temporary directory, as the *TemporaryFileUploadHandler* already do. However, the file this time will not be suppressed after your first

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

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

Re: Fellow Reports - November 2023

Week ending November 26 *Triaged:* https://code.djangoproject.com/ticket/34977 - Turn link to change password form in admin user change form into a button (accepted) https://code.djangoproject.com/ticket/34978 - Annotating through an aggregate with RawSQL() raises 1056 "Can't group on"

Re: Looking for a code that separates fields while applying migrations

On 28 Nov 2023, at 13:00, Remy Lukoo Hangi wrote: > > Fais-moi le setup.exe de python django suis débutant > Hi Remy, You found the developers email list for Django. Actually the email lists are not really used anymore, and you should use the ‘forums’ instead —>

Re: Looking for a code that separates fields while applying migrations

Fais-moi le setup.exe de python django suis débutant Le mardi 3 octobre 2023 à 06:41:12 UTC+2, Akash Sen a écrit : > This one worked : SQL: > https://github.com/django/django/blob/f4e72e6523e6968d9628dfbff914ab57dbf19e6b/django/db/models/fields/__init__.py#L142 > . > Thank you Adam. > > On

Fellow Reports - November 2023

Week ending November 12 I was in Zanzibar and participated in the DjangoCon Africa conference. * Triaged:* https://code.djangoproject.com/ticket/34946 - Adding a field with default and db_default drops database level DEFAULT (accepted) https://code.djangoproject.com/ticket/34950 - Translate

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

Re: Fellow Reports - October 2023

Week ending November 3 Released Django 4.2.7, 4.1.13, and 3.2.23. *Triaged:* https://code.djangoproject.com/ticket/34941 - db_default with decimal.Decimal() doesn't return Decimal instances on Oracle. (created) https://code.djangoproject.com/ticket/34943 - Support passing database

Re: Fellow Reports - October 2023

Week ending October 29 *Triaged:* https://code.djangoproject.com/ticket/34923 - MESSAGE_TAGS ignored in 5.0a1 (accepted) https://code.djangoproject.com/ticket/34924 - Example for squashmigration not working properly (duplicate) https://code.djangoproject.com/ticket/34919 - Missing

Re: How do you set the python path for django-admin?

Hi tobias. The django-admin command has a `--pythonpath` option for this (docs ). So, for example in a 3rd party package using the src layout (example ) where the module

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

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

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

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

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

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()`

Re: Question about support dates

As the maintainer of several Django-related packages and a contributor to many more, I see the policy as fair. Most maintainers have little capacity, and anything to reduce that burden is welcome. Third-party packages typically test with a matrix of Python versions against Django versions.

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

  1   2   3   4   5   6   7   8   9   10   >