Re: Query identity operation

if we're going to document this as > "official behavior": > > 1. This also appears to be true for filter. Would the same clarification > be appropriate there? > > 2. I don't see any tests validating the behavior for either Q or filter, > should there be? >

Re: Multi theme support for admin

Ramez - one can switch themes on a per-site basis already by overriding AdminSite.each_context() to add style control variables, and overriding the "admin/base_site.html" template (and other templates) to conditionally include different CSS or elements. I know that such a solution is unlikely to al

Re: collectstatic command should output minified files

django-compressor is also popular: https://pypi.org/project/django-compressor/ IMO we should not include anything in Django since JavaScript is a separate language, and they have much better tools for minification and bundling, and these tools can move faster than and orthogonally to Django. And t

Re: collectstatic command should output minified files

er trouble, not everyone wants to carry node.js subsystem with it's >> huge list of packages in their Python / Django project. >> But there are changes that transpiling would not be required in the >> future at all, after IE11 would fade to the past: >> >> https://

Re: collectstatic command should output minified files

For those who want more information on getting Django to serve your frontend assets, Aymeric wrote some good react-focussed blog posts: https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/ On Tue, 22 Dec 2020 at 12:43, Adam Johnson wrote: > > > Add

Re: Proposal: Permit __file__-less migrations packages

I've hit several problems with PEP-420 namespace packages in the last few months, which inspired me to create flake8-no-pep420: https://pypi.org/project/flake8-no-pep420/ . In summary, I found pep-420 namespace packages are not checked by Django's test runner, coverage.py, or mypy (with its bonus f

Re: Integrating migrations with the check framework

Hi Tom, I love this idea and would like to help developers write safe migrations too. You didn't mention this pre-existing project: https://github.com/3YOURMIND/django-migration-linter . It might be worth checking how that works. I'm not sure what any public API could look like here. In django-l

Re: Configurable landing page in admin site

You can do this already by changing where the login redirects to in your custom AdminSite class def login(self, *args, **kwargs): response = super().login(*args, **kwargs) if isinstance(response, HttpResponseRedirect): response = HttpResponseRedirect("/custom-page/")

Re: Configurable landing page in admin site

ng a landing page? > > Best, > Gagan Deep > > On Wednesday, December 23, 2020 at 8:37:22 PM UTC+5:30 Adam Johnson wrote: > >> You can do this already by changing where the login redirects to in your >> custom AdminSite class >> >> def login(self, *args

Re: Getting Started.

Hi Vamshi!, Did you check out the contributing guide? https://docs.djangoproject.com/en/3.1/internals/contributing/ It should have all you need to know to get going. Thanks, Adam On Sat, 26 Dec 2020 at 19:35, Vincent TOSSOU < tossouvincentsonag...@gmail.com> wrote: > Hi, I'm Web Front develop

Re: Add decorator django.utils.functional.cached_classproperty

There's no need for such a decorator - a class-level cached property can already be achieved with @classproperty and @lru_cache: In [1]: from functools import lru_cache In [2]: from django.utils.functional import classproperty In [3]: class Thing: ...: @classproperty ...: @lru_cach

Re: This should be taken in consideration : ordering variable in ListView Class

Hi Please don't use this post for support. See https://docs.djangoproject.com/en/3.1/faq/help/ Thanks, Adam On Sun, 3 Jan 2021 at 16:38, AMINE ART wrote: > Can get you every post if you fill it > I comment it to get only the user posts > > class UserPostsListView(ListView): > model = Post > t

Re: Proposal: Drop dependency on pytz in favor of zoneinfo

I'm also +1 on Aymeric's suggestion. On Wed, 6 Jan 2021 at 15:44, Carlton Gibson wrote: > Hey Nick, > > Super, no problem. 4.0 is fine. (And Aymeric's option does sound better > yes.) > > Thanks! > C > > On Wednesday, 6 January 2021 at 16:12:32 UTC+1 Nick Pope wrote: > >> Hi Carlton, >> >> Sorry

Re: Technical Board Decision Needed: Admin append_slash behaviour.

I agree with James, this is going down something of a rabbit hole of micro security holes within the trusted area of the admin. There is also lower hanging fruit in the realm of admin security. For instance geodjango's admin extensions rely on external scripts and are not compatible with a strict

Re: Technical Board Decision Needed: Admin append_slash behaviour.

I don't think we should mark the ticket as closed since we want to merge part of the open PR, the catch-all view. On Fri, 8 Jan 2021 at 17:24, Markus Holtermann wrote: > Thanks you for bringing this up, Carlton. And thanks Jon for tackling the > issues. > > I concur with what has been said so fa

Re: Repository

Akaksha - do you mean the git repo at https://github.com/django/django/ ? For more info see https://docs.djangoproject.com/en/stable/internals/contributing/ On Sat, 9 Jan 2021 at 15:41, Harsh Panday wrote: > How can help you? > > On Sat, 9 Jan, 2021, 9:08 pm Akanksha Shah, > wrote: > >> Hello

Re: New Here !

Welcome! There are many different ways to contribute to Django - the forum, blogging, translating, documenting, writing code, and so on. Our Contributing Guide can help you get started with any of these: https://docs.djangoproject.com/en/stable/internals/contributing/ If you’re looking to work wi

Re: Want to contribute to this amazing open source community

Welcome! There are many different ways to contribute to Django - the forum, blogging, translating, documenting, writing code, and more. Our Contributing Guide can help you get started with many of these: https://docs.djangoproject.com/en/stable/internals/contributing/ If you’re looking to work wi

Re: Humanize duration fields

This seems like a sensible addition, and could possibly reuse the translated strings from within naturaltime. Have you got an example implementation? On Mon, 11 Jan 2021 at 22:52, Yasiel Cabrera wrote: > Hey guys, > > I'm starting this thread to consult if make sense add a new filter > (naturald

Re: Status of 3.2 release blockers.

I think it's worth merging into 3.2. The change is quite small, the potential benefits are quite large, and some users live LTS to LTS so could be left without an option for a long time. I've left some review comments on the PR. On Tue, 12 Jan 2021 at 15:29, Paul Ganssle wrote: > Yeah, sorry I

Re: Adding Origin header checking to CSRF middleware (#16010)

Hi Tim, Thanks for working on this. I've put together some replies to your points here. On #1 - I think it's legitimate to have `CSRF_TRUSTED_ORIGINS` require the schemes. I think the setting should have included them all along, since a scheme is part of the definition of an origin. It's backward

Re: Status of 3.2 release blockers.

I would also lean towards option 3. If someone makes wrappers they might also release them in a third party package. On Wed, 13 Jan 2021 at 17:46, Carlton Gibson wrote: > Hi Paul, > > Thanks for this follow up. To give context, I think there’s enough support > (here and on the PR) to say, OK let

Re: Rethink (?) how we handle security headers.

l handling in > SecurityMiddleware. For example, 'Strict-Transport-Security' is only set if > request.is_secure(). > On Friday, August 21, 2020 at 12:53:33 PM UTC-4 Adam Johnson wrote: > >> A single SECURITY_HEADERS (or perhaps SECURITY) setting sounds good. >>

Re: Rethink (?) how we handle security headers.

> then it seems this won't be the case. > > On Tuesday, January 19, 2021 at 4:39:54 AM UTC-5 Adam Johnson wrote: > >> I'd imagined the setting would be more like a roll-up of the existing >> settings, so no need for parsing: >> >> SECURITY_HEADERS =

Re: final_catch_all_view

I don't see the need for any change - you can insert your custom URL's before the catch-all view with a subclass of AdminSite like so: class MyAdminSite(AdminSite): def get_urls(self): urls = super().get_urls() return urls[:-1] + [ # custom urls ...

Re: Permission to discuss

I don't think that's appropriate to post on either mailing list. These mailing lists have thousands of members so must be kept on topic. The "Show & Tell" section on the forum would be a better place to post this: https://forum.djangoproject.com/c/projects/11 On Tue, 19 Jan 2021 at 21:56, Benny w

Re: deep frontend integration

Hi Christian I don't quite follow what you concretely want here. There are so many ways to build JavaScript dependencies these days, it's hard to keep track of, and Django thus mostly has a policy of "not touching that stuff". The problems you describe in your second email are normally solved by

Re: Snowflake db backend

Yes we would favour a third party backend. Merging the backend straight to core would impose the requirement that all changes to Django core consider Snowflake, which is a fairly steep cost when there's only one organization using it (at current). If you release as a third party package and show so

Re: Beginner in Django

Welcome! There are many different ways to contribute to Django - the forum, blogging, translating, documenting, writing code, and more. Our Contributing Guide can help you get started with many of these: https://docs.djangoproject.com/en/stable/internals/contributing/ If you’re looking to work wi

Re: First time contribution

Welcome! There are many different ways to contribute to Django - the forum, blogging, translating, documenting, writing code, and more. Our Contributing Guide can help you get started with many of these: https://docs.djangoproject.com/en/stable/internals/contributing/ If you’re looking to work wi

Re: Update returning

I think we could do the most logical: QuerySet.objects.update(name="Rob", returning=["id', "name"]) There is a precedent for small backwards incompatible changes like this, for example when "named" was added to "values_list()". However maybe backwards compatibility is worth keeping. We can be bac

Re: Update returning

d a new function just for the sake of a small > backwards compatibility. > > > I'd expect it to return a list of dicts. > > Currently .update returns the number of rows affected I think. This > information should still be there even if returning extra data. > On Tuesday,

Re: Increase default integer keys to 64 bits

64 bits is the default for new projects. See the 3.2 release notes: https://docs.djangoproject.com/en/dev/releases/3.2/ On Fri, 29 Jan 2021 at 17:23, Christophe Pettus wrote: > > > > On Jan 29, 2021, at 07:40, charettes wrote: > > > > As Tom said Django 3.2 supports swapping the default primary

Re: Docs improvement? - MEDIA_URL in templates

There's also the media context processor that will inject MEDIA_URL into every template context, which is very similar to how get_media_prefix works: https://docs.djangoproject.com/en/3.1/ref/templates/api/#django-template-context-processors-media On Sat, 30 Jan 2021 at 22:46, Mike Nicholson wrot

Re: Admin list view counting

+1 from me, I've spent long enough on those COUNT(*) queries at work. Is it worth putting this logic in Paginator so applications can reuse it? On 7 August 2017 at 07:45, Josh Smeaton wrote: > The admin list page performs a count(*) (twice!) when viewing the list > page of a model. One of these

Re: Admin actions.js performance

I've made a ticket here: https://code.djangoproject.com/ticket/28472#ticket . You can follow https://docs.djangoproject.com/en/dev/intro/contributing/ to make a Pull Request on GitHub against this ticket 👌 On 7 August 2017 at 09:19, ecas wrote: > Is there any way to propose this optimization to

Re: [feature request] including HttpResponse(status=204) as an HttpResponse subclasses

ango, unless perhaps, they add some additional functionality > as HttpResponseNoContent does. > > Did you intend to have response subclasses for all 57 values of > http.HTTPStatus? > > On Sunday, August 6, 2017 at 4:17:22 PM UTC-4, Adam Johnson wrote: >> >> I've made a t

Re: Admin list view counting

FYI Django-MySQL supplies an approx_count() method: https://django-mysql.readthedocs.io/en/latest/queryset_extensions.html#django_mysql.models.approx_count . It only works on QuerySets without filters. From what I understand it's possible to get an estimate for filtered queries in MySQL in *some* c

Re: Oracle sequence naming regression - input on approach?

Considering the number of people using Oracle is small, and those using the non-default for use_returning_into should be smaller, and that it sounds like the sequence naming logic doesn't sound super different, and that 1.11 hasn't been out for *that* long, relatively, it sounds like option 1 is th

Re: Automatic prefetching in querysets

I'm biased here, Gordon was my boss for nearly three years, 2014-2016. I'm in favour of adding the auto-prefetching, I've seen it work. It was created around midway through last year and applied to our application's Admin interface, which was covered in tests with *django-perf-rec*. After adding t

Re: Should django File wrapper support .next()?

The next() method is gone from the return value of open() in Python 3 and I don't think it was every necessary. As per the iterator protcool ( https://docs.python.org/2/library/stdtypes.html#iterator-types ), __iter__ is meant to return an iterator over the object, and *that* is what the next() met

Re: Automatic prefetching in querysets

)` queries (that can't use prefetch) > - Could we warn of reverse M2M/ForeignKey at least? > > Adam/Gordon, I'm interested in hearing how these changes led you to > discovering stale prefetches? > > On Wednesday, 16 August 2017 07:30:10 UTC+10, Adam Johnson wrote: >>

Re: Automatic prefetching in querysets

viour is effectively assuming that it's completely *unlikely*. On 15 August 2017 at 23:24, Adam Johnson wrote: > Adam/Gordon, I'm interested in hearing how these changes led you to >> discovering stale prefetches? > > > We removed all the manual prefetches in admin get_q

Re: Automatic prefetching in querysets

> > I wouldn't want is to give free optimisations to non-ORM pros > Something like 99% of django projects are by non-ORM pros, it can be easy to forget that on a mailing list of experts. On 16 August 2017 at 12:27, Josh Smeaton wrote: > It won't affect experienced users. They'll read the releas

Re: Should django File wrapper support .next()?

y open(). > > > El martes, 15 de agosto de 2017, 19:21:08 (UTC-3), Adam Johnson escribió: >> >> The next() method is gone from the return value of open() in Python 3 >> and I don't think it was every necessary. As per the iterator protcool ( >> https://docs.pyth

Re: Optimizing out unused annotations from count queries

I'm not sure how much QuerySet optimization django should really be doing. Databases' optimizers are really good and as we've seen there are a huge number of edge cases in trying to do the work in Djangoland, as QuerySets don't really correspond to the underlying data model. Here's an example in M

Re: Feature request: Allow to process data-migrations after flush

I've always thought flush is a weird command because an empty database is very normally useless, because of data migrations. The docs do even say: If you would rather start from an empty database and re-run all migrations, > you should drop and recreate the database and then run migrate instead.

Re: Default to BigAutoField

I don't think "primary key size" is something that's even within consideration for 99% of django apps. Sure a few more bytes are going to be wasted here, but you could argue the same that the default AutoField was already too big for most models that have 100's of instances and could use even a one

Re: drop support for MySQL 5.5 in Django 2.0?

Collin, it's also not hard to install MySQL 5.6 from Oracle on Ubuntu 14.04 ;) Tim, the commit to clean up MySQL 5.5 isn't very big, especially if you put back in the supports_microsecond_precision code. I'm not sure dropping it "prematurely" is that helpful, considering that GIS is rarely used mo

Re: Default to BigAutoField

eld. Did I miss the discussion about the benefits of the > rename? If we agree to proceed with it, please split it out into a separate > ticket/PR for easier review. > > On Sunday, August 27, 2017 at 5:31:47 AM UTC-4, Adam Johnson wrote: >> >> I don't think "primary ke

Re: Add support for multiple file fields

I agree with Melvyn on the first point. I don't think Django should include model fields that encourage denormalization by default (apart from JSONField etc which are built into the DB). A forms.MultiFileField would make sense but to make storage easy it should somehow translate into multiple rows

Re: Custom Join Conditions

I think filter_related is a good name, it's not that confusing that it sounds like select_related / prefetch_related. The current name is a bit weird because it's an adj + noun, it doesn't really say how it *modifies* the QuerySet, it sounds more declarative. to_attr is also better, as it aligns w

Re: Custom Join Conditions

The annotate(foo=FilteredRelation(...)) API LGTM too, and yes I agree on the rationale on alias over to_attr. On 4 September 2017 at 10:25, Anssi Kääriäinen wrote: > I really like the .annotate() version. The way this feature works with > .annotate() is easy to understand if you understand how e

Re: Custom Join Conditions

eredRelation ? > From its current location ? > > from django.db.models.query import FilteredRelation > > or from its parent module ? > > from django.db.models import FilteredRelation > > as it seems to be the django way. > > Best, > Nicolas > > On 04/09/20

Re: Easy pickings are not that easy for a new contributor

There are also some other repos in the Django organization on GitHub that could do with some love: https://github.com/django . For example localflavor and formtools, which were removed from Django core, still have some users and you might something to work on there. On 5 September 2017 at 15:06, D

Re: Having a MongoDB connector for Django

I agree, I think forcing Django's ORM to work on MongoDB is not a great idea. Django relies heavily on transactions and other relational goodness. Have you tried storing JSON in your Postgres/MySQL database? Django can work with that with contrib.postgres/django-mysql 😉 On 8 September 2017 at 16:

Re: Having a MongoDB connector for Django

> > That's a bit ridiculous, because now I have to reinvent Django ORM, > contrib packages and everything under the sun. > Django can work with DBs that support or don't support transactions. I don't know where you get the impression that Django can work with transactionless DB's from. Many of

Re: Deprecating CachedStaticFilesStorage in Django 2.0

(For some reason GMail is clipping your message before any content, I only saw '... [Message clipped]' and had to click to see it all) I'm not that familiar with the static file storages, but it seems to me like it's not going to be that controversial deprecate it in order to save this duplication

Re: ConnectionResetError in test_closes_connection_without_content_length

Hi Zhiqiang It's hard to tell what the problem is with more details. From your traceback it looks like you're running Python3.4 on MacOS but there's no indication of your database or other settings. If you run the tests on the 1.11 branch, does it pass? If so, you can bisect to find the regressio

Re: New Feature: Allow password reset token to expire in under a day

Why not just keep PASSWORD_RESET_TIMEOUT_DAYS and allow floats? Then you can just do 1/24 for an hour. On 21 September 2017 at 09:50, Eddy C wrote: > I think Minute, with default value 30 or 60, is the best unit for this > setting. > > 3 minutes (even 1) is short enough for edge case and 720 (12

Re: CONTRIBUTION TO DJANGO

There's a whole documentation page on this: https://docs.djangoproject.com/en/dev/internals/contributing/ There aren't many easy pickings tickets, plus most of the effort right now is being put into features for the 2.0 feature freeze. I'd suggest the biggest contribution you can make right now is

Re: New Feature: Allow password reset token to expire in under a day

>>>> vs. integer seconds. Timedelta has the benefit of readability, but >>>>>> integer >>>>>> has the benefit of simplicity. I think in SETTINGS everything should be >>>>>> as >>>>>> simple as possible, so I think integer

Re: There should be a way to make Templates substitution to raise an exception on error

I've used a solution like the one Emil links to before to great success, though perhaps there's scope to make it a bit less hacky in Django. On 22 September 2017 at 07:10, Emil Stenström wrote: > It as actually possible, just in a very hacky way. Django has a setting > called TEMPLATE_STRING_IF_

Re: about ticket 28588- has_perm hide non-existent permissions

I agree with Shai's comment on the ticket, changing it to raise a DoesNotExist when DEBUG=True. I think it's an acceptable compromise between backwards compat and helping find bugs. On 25 September 2017 at 11:56, Dan Watson wrote: > Seems like maybe it would be more helpful if has_perm logged a

Re: WOULD LIKE TO CONTRIBUTE TO DJANGO

Also you posted this in https://groups.google.com/forum/#!msg/django-developers/r7JP_YHsIhM/jmof68XFBAAJ . Please don't repost, keep the conversation in one place. On 3 October 2017 at 17:00, Aymeric Augustin < aymeric.augus...@polytechnique.org> wrote: > Hello, > > Since I haven't seen positive

Re: PostgreSQL Partial Indexes package

It looks to me that the same trick on Oracle can be used on MySQL/MariaDB - indexing a generated column. There's a comment on https://mariadb.com/kb/en/library/generated-columns/ to that effect. P.S. Drizzle is long dead, the site isn't even up any more :) On 8 October 2017 at 12:38, Tim Allen w

Re: MariaDB, official support

Hi Claude Afraid I haven't made any progress, I don't get to contribute to Django at work these days which has slowed me down :( So the sketchy plan I've had in my mind for some time is: 1) Get testing with all supported MariaDB versions (currently 5.5, 10.0, 10.1, 10.2) into Django CI, and fix

Re: Contributing to Django

https://docs.djangoproject.com/en/dev/internals/contributing/ has a guide on getting starting contributing to Django, whether working on the code, the tickets, or just the community. On 31 October 2017 at 09:28, Harsh vardhan sharma < harshavardhana@gmail.com> wrote: > Hi everyone, > > I am a

Re: Allow SessionStore's to be easily overridden to make dynamic the session cookie age

You linked to the wrong PR, here's the right one: https://github.com/django/django/pull/9318 I think Tim's middleware solution isn't that bad, it has the advantage that you can do a lot more logic there too, like use other attributes of request. Plus it works on current Django releases. That said

Re: Template variable resolution on objects that are no mappings but implement __getitem__

> > there are classes in the Pythoniverse that implement a __getitem__ method > for the sake of syntactical sweetness, but they are no mappings. My understanding of what ducktyping means is that by implementing __getitem__ such objects are declaring they are mappings. I'm -1 on this change becau

Re: Template variable resolution on objects that are no mappings but implement __getitem__

> > so it may only be to be explained that the implementation > of an object that they are using is wrong in regards to the mentioned > PEP 3119. PEP 3119 does say that ABC's are "not the end of ducktyping": https://www.python.org/dev/peps/pep-3119/#abcs-vs-duck-typing . As I understand it, objec

Re: Rate limiting failed login attempts/failed password changes

https://github.com/jsocol/django-ratelimit is good at this, and it's well maintained so you shouldn't have any problems with upgrading. It's already tested on Django 2.0. I agree though that it would be best for security if contrib.auth did it out of the box. But there are lots of reasons why it's

Re: Removing ORM's union restrictions

Afraid I can't say as to whether you're missing anything, but I can say that MySQL/MariaDB support LIMIT/OFFSET it in the combined queries, so if this were implemented it would be nice to not add the SELECT * wrappers for the MySQL backend - there does seem to be a performance impact there, as the

Re: Provide option to chain QuerySet.order_by()

Seems like a good idea to me, I've been in a similar situation before and had to work around this part of QuerySets. On 11 December 2017 at 21:10, Markus Holtermann wrote: > Hi all, > > I'm in the situation where I'd like to join two .order_by() calls on a > QuerySet without losing the ordering

Re: Hello everyone I'm a new member

Link: https://docs.djangoproject.com/en/dev/internals/contributing/ On 13 December 2017 at 06:49, ludovic coues wrote: > There is a chapter in the documentation on how to contribute to django. It > should answer most of your questions. > > On 13 Dec 2017 3:10 am, "Asad Ahmed" wrote: > >> Hello

Re: Provide option to chain QuerySet.order_by()

I would prefer the QuerySet method than documenting parts of Query - QuerySet shouldn't have to make guarantees that its interactions with Query won't change, plus making Query in some way a public API could hamper features. Plus the amount of code is small and contained. Also I think worrying abo

Re: Hello everyone I'm a new member

Please don't do that, as I recall we'll just delete django.utils.six after the minimum recommended django version for third party libraries is 2.0. On 18 December 2017 at 15:05, wrote: > Hello Asad, > > as a first task you can remove the Python2-specifics from > django/utils/six.py , and depreca

Re: Provide option to chain QuerySet.order_by()

, 15 Dec 2017 21:01:39 + > Adam Johnson wrote: > > > I would prefer the QuerySet method than documenting parts of Query - > > QuerySet shouldn't have to make guarantees that its interactions with > > Query won't change, plus making Query in some way a public API c

Re: Provide option to chain QuerySet.order_by()

n 18 December 2017 at 21:33, Shai Berger wrote: > >> On Fri, 15 Dec 2017 21:01:39 + >> Adam Johnson wrote: >> >> > I would prefer the QuerySet method than documenting parts of Query - >> > QuerySet shouldn't have to make guarantees that its interactio

Re: Introduction : Somesh Chaturvedi

Welcome Somesh, There's actually a mailing list dedicated to first time contributors, where you might get a bit more attention: https://groups.google.com/forum/#!forum/ django-core-mentorship I'd suggest having a particular goal in mind where you'd like to contribute - what areas of Django do you

Re: Provide option to chain QuerySet.order_by()

Now you've said it, having both seems reasonable to me too :) On 23 December 2017 at 17:42, Shai Berger wrote: > On Tue, 19 Dec 2017 17:58:35 +0000 > Adam Johnson wrote: > > > Fair. I agree it's more flexible, but it does make "the most common > > case&qu

Re:

This mailing list is for the development of Django itself, not for support. Use the django-users mailing list for that, or IRC #django on freenode, or a site like Stack Overflow. On 26 December 2017 at 00:01, Atef Ouerghi wrote: > I would like to retrieve the value of a field in ModelAdmin in or

Re: Add Request Timeout on API level

There isn't a native request timeout in Django, however you can configure your hosting WSGI server (at least gunicorn and uWSGI) to have a request timeout, and indeed it's recommended. I'm not sure how hard it would be to implement this (reliably, for all cases and platforms) inside Django. On 26

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

1. I don't think the seal API on the QuerySet is enough, there are other ways implicit queries can be triggered without a QuerySet, e.g. Book(author_id=1).author . Shai's suggestion of using a query execution blocker is probably the best approach. If you were really worried you could even implement

Re: UnicodeDecodeError at /manager/procesar_csv/ 'utf8' codec can't decode byte 0xd1 in position 0: invalid continuation byte

This mailing list is for the development of Django itself, not for support. Use the django-users mailing list for that, or IRC #django on freenode, or a site like Stack Overflow. On 4 January 2018 at 16:01, Hernán Darío Zapata Villa wrote: > Good morning everybody > > I have a mistake about the

Re: Change Local Memory Cache to Use LRU #28977

I'm +1 for moving to LRU too, the eviction algorithm has always looked weird to me. And Josh's library shows there are valid uses of local memory caching in applications - perhaps moreso these days than when Django added caching and memcached was the latest thing. > You can also get a very nice b

Re: Database session deletion

Hi George-Cristian, I agree, the 'clearing the session store' paragraph could be more explicit about what conditions sessions do get deleted. I encourage you to check https://docs.djangoproject.com/en/dev/internals/contributing/ , open a ticket, and make a PR with some updated wording :) I also t

Re: Change Local Memory Cache to Use LRU #28977

d and Has patch. I've created a pull request at >>> https://github.com/django/django/pull/9555 Please review when able. >>> >>> Grant >>> >>> Ps. As always the docs are excellent. Even the docs for contributing are >>> extremely helpful! >

Re: Fellow Report — January 12, 2018

🎉🎉🎉 Welcome! 🎉🎉🎉 On 12 January 2018 at 17:04, Jacob Kaplan-Moss wrote: > Hooray, welcome Carlton! Looks like a great first week; glad to have you! > > Jacob > > On Fri, Jan 12, 2018 at 9:01 AM, Carlton Gibson > wrote: > >> Hi all, >> >> With help from Tim, Aymeric and Frank, I got started on t

Re: Should ModelField.choices accept a callable?

I'd be more in favour of opting specific kwargs out of migrations, it keeps the interface simpler for users. There's a barrier to understanding Field(choices=func_that_returns_a_plain_list). As an note, Django-MySQL's EnumField uses the values in choices at the database layer to define an ENUM typ

Re: Ticket #29015

Hi Priyansh, Aborting on creation with an informative message is probably wise. I'd say include as many details as you think relevant in the message, and it can be discussed more in review when there is a concrete message :) Thanks, Adam On 15 January 2018 at 12:50, wrote: > Greetings ! > > I

Re: Ticket #29015

It's a lot easier to review code changes if you submit a pull request, and you'll get much more attention for a pull request with passing tests than pasting a stack trace to the mailing list. Here's the how-to: https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-pat

Re: PR 9583 - Ticket 28643

+1 for adding Left/Right as plain functions right now. Simon's example for a new future is really nice but outside the scope of the ticket. On 18 January 2018 at 22:30, Josh Smeaton wrote: > I think having Left/Right is the right way to go. If there are > opportunities to use slicing syntax, th

Re: Ticket #29015

Please keep the conversation just on the pull request, and don't bug for review after a day. There are many patches to review, and half the work is done by volunteers in their spare time (I am one). Beware that there are 11,195 people subscribed to this mailing list. On 21 January 2018 at 07:56,

Re: select_related() for fetching individual fields

F.objects.select_related('g__n') looks a bit convoluted to me. You can already do something like F.objects.select_related('g').only('g__n', *[f.name for f in F._meta.get_fields()]) and write a small helper function for the list comprehension to avoid typing. Also I'd say it's generally a rare cas

Re: Add slicing notation to F expressions

Actually there was some further discussion in https://groups.google.com/forum/#!msg/django-developers/PsHDk1doTDg/CewZdVMJAQAJ where we settled that the slicing operator need not be implemented in the scope of that ticket. On 28 January 2018 at 17:09, wrote: > Hello ! > > There is a new feature-

Re: Ticket #29066

It's generally best to leave questions like this on the PR than in a separate mailing list thread. I'll answer there ( https://github.com/django/django/pull/9627 ). On 27 January 2018 at 07:02, wrote: > Hello everyone ! > > I have two queries with respect to the ticket #29066 >

Re: Bug in utils.encoding producing invalid JSON for request body

> > the JSON it produces (it does try) > I wouldn't say it "tries", it just calls str on any object that is passed in, which for a simple dict with strings in, looks close to JSON. force_bytes definitely shouldn't be trying to JSON-coerce things. Thus I don't think it's a bug. Bugs are when behav

Re: Bug in utils.encoding producing invalid JSON for request body

is how to pass the kwargs in for > json.dumps to allow custom encoders. Or do we not want this (I think we do)? > > On Mon, Jan 29, 2018 at 4:50 PM Adam Johnson wrote: > >> the JSON it produces (it does try) >>> >> >> I wouldn't say it "tries", it just

Re: Behavior of ModelAdmin.fieldsets with 'classes': ('collapse',) when fieldset name is None.

> > * If you agree that it needs to be fixed, just showing the (Show) link, > would suffice? +1 from me, seems like the straightforward solution On 28 January 2018 at 22:45, Douglas Miranda wrote: > Hello, I don't know if this was debated before, but I think the behavior > of Collapsed fieldse

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