Experimental APIs DEP

Hi everyone, One of the results of discussions at Django Under The Hood was support for the idea of marking APIs "experimental" - that is, document them and include them in mainline Django releases, but away from the standard Django deprecation cycle while still not hiding them under the

Re: Adding model managers to migrations

As I've said before, I like this idea, and the opt-in thing is even better and gets rid of a lot of the compatibility headaches I was worried about. The review looks good overall - have left a couple of notes, only really the one change I want to see (the operational dependency stuff). Andrew

Re: Should annotations allow model field constraints?

Hi Josh, > This is similar to what Ansii thinks the behaviour should be. But we don't > know if a user has provided the field, or if the field is being repurposed > from the underlying field (for F() expressions), or if it was derived > internally. > I was thinking you'd instantiate the

Re: Should annotations allow model field constraints?

Thanks for all the comments. I'll address the relevant bits below. > So, if the user explicitly asks for max_digits=3 in the output_field > argument, then we should enforce that. Or, alternatively we should > disallow setting max_digits for explicit output_field in expressions. > I don't

Re: delegating our static file serving

On 12/04/2014 10:33 PM, Collin Anderson wrote: > Hi All, > > I'm pretty interested in getting secure and _somewhat_ efficient static > file serving in Django. > > Quick history: > 2005 - Jacob commits #428: a "static pages" view. Note that this view > should only be used for testing!" > 2010

Re: Should annotations allow model field constraints?

On 12/04/2014 11:15 PM, Anssi Kääriäinen wrote: > On Thu, 2014-12-04 at 18:04 -0800, Josh Smeaton wrote: > >> >> I've implemented https://github.com/django/django/pull/3655/ which >> effectively ignores the max_digits and decimal_places arguments in the >> base expression class. Subclasses are

Re: Adding model managers to migrations

Hi Markus, On 12/05/2014 11:22 AM, Markus Holtermann wrote: > Ticket: https://code.djangoproject.com/ticket/23822 > Pull Request: https://github.com/django/django/pull/3687 > > Hey folks, > > As of now migrations don't expose the model managers to models. Thus it is > "impossible" to use e.g.

Adding model managers to migrations

Ticket: https://code.djangoproject.com/ticket/23822 Pull Request: https://github.com/django/django/pull/3687 Hey folks, As of now migrations don't expose the model managers to models. Thus it is "impossible" to use e.g. `create_superuser` in a `RunPython` operation. I opened ticket #23822 to

Re: delegating our static file serving

+1 to this: I'm all in favour of supporting production-adequate static file handling in core. A couple of small points: We already have the views, api, and logic around for finding and serving > the correct files. One question that needs to be thought through is the role of `collectstatic` and

Re: delegating our static file serving

Requiring fewer moving parts for small sites is definitely an improvement. +1 to Collin's plan. Regards, Michael Manfre On Fri, Dec 5, 2014 at 2:02 AM, Loïc Bistuer wrote: > I'm +1 on this plan, "native" support for wsgi.file_wrapper makes a lot of > sense. > > -- >

Re: delegating our static file serving

I'm +1 on this plan, "native" support for wsgi.file_wrapper makes a lot of sense. -- Loïc > On Dec 5, 2014, at 12:33 PM, Collin Anderson wrote: > > Hi All, > > I'm pretty interested in getting secure and _somewhat_ efficient static file > serving in Django. > > Quick

Re: Should annotations allow model field constraints?

First, thanks for all your hard work in this area Josh. >From a quick look at the code, my understanding is that output_field can be None, in which case the ORM will use the model's field type, or it can be specified explicitly in the query. I think that if specified explicitly, any

Re: Should annotations allow model field constraints?

I think this should be an error personally - I'm not sure how we check that effectively and efficiently. It reminds me of asking postgres to cast a certain type to another one - it will throw an error if any record it tries to cast can't be done. Is it possible with say a CharField to not have a

Re: delegating our static file serving

Yes, I support this plan. "Serve your files with nginx!" doesn't fly in the age of PaaS. Serving static files with Django and having a CDN cache them is a reasonable setup as far as I know. I don't know if the "probably insecure" argument still holds. Are there some specific security risks in