Re: CSRF middleware conflicts with request.upload_handlers

Yeah... good name for it... https://github.com/django/django/pull/5688 -- Curtis On Tuesday, 17 November 2015 00:45:27 UTC+11, Collin Anderson wrote: > > Maybe @csrf_check_header_only? I usually put the token in POST for my ajax > calls. > > On Monday, November 16, 2015 at 12:51:18 AM UTC-5,

Re: Form field labels change proposal

I'd like to see the admin's CSS updated under the assumption that this change moves forward to better understand the extent of changes that would be required from Django users to maintain the current behavior. On Thursday, November 19, 2015 at 4:52:57 PM UTC-5, Sergei Maertens wrote: > > Yes,

Re: Form field labels change proposal

Yes, I've thought about a setting as well briefly but quickly discarded it because it would be 'yet another setting'. But this one would ofcourse be temporarily, and if that's been applied successfully in the past, then that's probably the best way to tackle this. I'd be happy to write the

Re: Form field labels change proposal

The best solution I can think of at the moment would be a setting allowing users to opt-in to the new behavior which would then silence the warning. That leaves you with a defunct setting once the deprecation period completes. That's basically how SessionAuthenticationMiddleware worked when we

Re: [Question] Many-To-Many query where only pk is returned

In the meanwhile you can directly query the intermediate model instead: Author.books.through.objects.filter(author_id=author.id).values_list('book_id') Le jeudi 19 novembre 2015 16:05:11 UTC-5, Cristiano Coelho a écrit : > > You are right. I believe an optimization like this would probably help

Re: Form field labels change proposal

Good catch. I'm not sure, haven't there been similar cases in the past? First thing I can think of is using naive datetimes when timezone-support is enabled, and then you get a warning for each naive datetime you use, but that's of course different then a DeprecationWarning. It's probably not

Re: [Question] Many-To-Many query where only pk is returned

You are right. I believe an optimization like this would probably help just a few people, as only fetching data from the intermediary table is a rare thing. But if it is an easy change, which improves performance, why not? However I think the change is quite complicated. El jueves, 19 de

Re: [Question] Many-To-Many query where only pk is returned

I think you didn't understand the query. You would filter by the intermediate table directly, and filter by Usuario (as you want all Especialidad from one Usuario), yielding 2 results as it should with a single select from one table. Right now django translates it into a more complicated

Re: Ask for help

Please write to django-users (as I see you already did), this mailing list is for the development of Django itself. On Thursday, November 19, 2015 at 12:26:34 PM UTC-5, Cision Lee wrote: > > *I meet some errors when I migrate database, and the error code is > following:* > > Operations to

Re: Form field labels change proposal

How would a developer acknowledge/silence that deprecation warning? It seems to me that if it's emitted for every form field in a project that's not really going to be helpful. On Wednesday, November 11, 2015 at 11:47:46 AM UTC-5, Sergei Maertens wrote: > > I think I would start with locally

Ask for help

*I meet some errors when I migrate database, and the error code is following:* > Operations to perform: > Synchronize unmigrated apps: staticfiles, messages > Apply all migrations: admin, contenttypes, api, auth, sessions > Synchronizing apps without migrations: > Creating tables... >

Re: [Question] Many-To-Many query where only pk is returned

Hi Cristiano, If I get it correctly you'd like m2m querying to start with the intermediary (FROM) table and JOIN the referenced one only if more fields than the primary key are selected. class Book(models.Model): name = models.CharField(max_length=100) class Author(models.Model):

Re: "Project" vs "App"

What's a sitecustomize.py? :) I think apps _can_/_may_ be reusable. I have plenty of non-reusable apps. Why should they be reusable? I think apps _should_ not depend on a project. On Thu, Nov 19, 2015 at 4:54 AM, guettli wrote: > I created a ticket to find a

Re: [Question] Many-To-Many query where only pk is returned

I guess that Cristiano may be right. Making the query only on the Intermediate table would be enough for this case, because the two columns that we need for the query are on this table, and looks like Django is using a JOIN only to get the "id" of Especialidad. *Here's an example:* *GIven the

Re: Oracle GIS update

As noted by some of you managed to get it done. Most problematic thing seems to be "Texas" geometry which causes problems in Oracle and sometimes with SpatiaLite as well. I'll try to investigate if that data could be improved to create more consistent test results. On 10.11.2015 21:23, Tim

Re: manage.py test and uninstalled apps

2015-11-19 8:27 GMT+01:00 Claude Paroz : > To be clear, I don't contest in any way that design choice. I understand > and approve it. > I'm just pointing to this unwanted side-effect, wondering if anyone has > ideas how to circumvent it, as I think it's a legitimate use case.

"Project" vs "App"

I created a ticket to find a better definition of "Project" vs "App" https://code.djangoproject.com/ticket/25748 I am happy since Tim Graham accepted it. Here are the current docs: https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applications Here is my view of Project" vs