Re: Vote on Jira as bugtracker

2016-01-08 Thread Andrey Antukh
Hi Joe On Fri, Jan 8, 2016 at 7:16 AM, Joe Tennies wrote: > I'm not a lawyer, but I care about licensing. > > The MIT License would allow you to relicense it, but you must keep the > original copyrights in tact. (From license: Redistribution and use in > source and binary

Re: slow migrations

2016-01-08 Thread Markus Holtermann
Yes, the more relationships your models have the more time expensive migrations become. Adding/Altering/Removing a field (ForeignKey or not) always requires all related models to be recreated. See https://github.com/django/django/blob/master/django/db/migrations/state.py#L53 for the reasoning

Re: re-thinking middleware

2016-01-08 Thread Curtis Maloney
In general, I love it. It's MUCH simpler for people to write and comprehend... requires no classes [but IMHO the callable class is "cleaner"] and allows for configurable middlewares easily... I do wonder, though... how the anti-import-strings factions will react... I'm sure it can, at

Re: re-thinking middleware

2016-01-08 Thread Markus Holtermann
Thank you Florian and Carl for continuing the work on that topic. I like both the DEP as well as the example. I would, however, include the exception handling in the examples provided in section "Specification" as that is an integral part of middlewares, too. Nitpicking, I would also name the

Re: re-thinking middleware

2016-01-08 Thread Florian Apolloner
On Friday, January 8, 2016 at 12:51:25 PM UTC+1, Markus Holtermann wrote: > > Nitpicking, I would also name the settings variable MIDDLEWARES (i.e. > plural) as it is a list of middlewares, not just one. > Yes, my thought too. On January 8, 2016 10:31:49 PM GMT+11:00, Curtis Maloney <

Re: re-thinking middleware

2016-01-08 Thread Florian Apolloner
Mhm, I currently see no easy way to give *get_response* access to the list of middlewares like done in https://github.com/django/django/pull/5591/files#diff-dbd7d9159676b15fc9a096b0adb919e9R122 and following lines. The reason is that providing *get_response* at setup/init time means it has

Re: re-thinking middleware

2016-01-08 Thread Florian Apolloner
I've gone ahead and pushed a new commit to match the spec (not tested yet, but hey :D). On Friday, January 8, 2016 at 3:29:01 PM UTC+1, Florian Apolloner wrote: > > Mhm, > > I currently see no easy way to give *get_response* access to the list of > middlewares like done in >

Re: re-thinking middleware

2016-01-08 Thread Florian Apolloner
Haha, I was so focused on my previous approach that I forgot, that I could just chain them during setup (thanks knbk). So the question remaining now: Do we want to be able to change middlewares per request or not :D I guess I'll submit a second PR with the non-request usage. On Friday, January

Re: re-thinking middleware

2016-01-08 Thread Florian Apolloner
PR1 (allows changing the middlewares during the middleware run): https://github.com/django/django/pull/5591 PR2 (static middleware chain, seems simpler and probably the way to go): https://github.com/django/django/pull/5949/ On Friday, January 8, 2016 at 4:55:08 PM UTC+1, Florian Apolloner

Re: URL dispatching framework: feedback requested

2016-01-08 Thread Marten Kenbeek
The first argument to Constraint.construct() is a URL helper object which allows you to set the scheme, host, path, querystring and fragment separately. So reversing a domain constraint is as simple as this: class DomainConstraint(Constraint): ... def construct(self, url_object, *args,

Re: re-thinking middleware

2016-01-08 Thread Carl Meyer
Hi Curtis, On 01/08/2016 04:31 AM, Curtis Maloney wrote: > In general, I love it. Great! > It's MUCH simpler for people to write and comprehend... requires no > classes [but IMHO the callable class is "cleaner"] and allows for > configurable middlewares easily... > > I do wonder, though... how

Re: delegating our static file serving

2016-01-08 Thread David Evans
I've just pushed a simple middleware wrapper that lets you install WhiteNoise by adding: MIDDLEWARE_CLASSES = ( ... 'whitenoise.middleware.StaticFilesMiddleware', ... ) See: https://github.com/evansd/whitenoise/blob/master/whitenoise/middleware.py No messing with wsgi.py! This

Re: re-thinking middleware

2016-01-08 Thread Aymeric Augustin
+1 Great work. The only (and minor) concern I have is about allowing function-based middleware factories to return None. In the spirit of “there should be only one way to do it”, I would require raising MiddlewareNotUsed explicitly to disable a middleware. A middleware factory that returns

Re: re-thinking middleware

2016-01-08 Thread Ryan Hiebert
> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin > wrote: > > +1 > > Great work. > > The only (and minor) concern I have is about allowing function-based > middleware factories to return None. > > In the spirit of “there should be only one way to do it”,

Re: re-thinking middleware

2016-01-08 Thread Ryan Hiebert
> On Jan 8, 2016, at 11:57 AM, Ryan Hiebert wrote: > >> On Jan 8, 2016, at 11:35 AM, Aymeric Augustin >> wrote: >> >> In the spirit of “there should be only one way to do it”, I would require >> raising MiddlewareNotUsed explicitly

Re: Vote on Jira as bugtracker

2016-01-08 Thread Joe Tennies
No problem. Don't forget the documentation too. That was called out in the original license. For instance, I'd put it right on the README.md on the correct project(s) on GitHub under the license section. OTOH, I'm now interested in checking it out, so thanks. On Fri, Jan 8, 2016 at 3:42 AM,

Re: re-thinking middleware

2016-01-08 Thread Carl Meyer
Thanks everyone for the reviews. I've pushed a new commit addressing most of the issues raised: https://github.com/django/deps/commit/62b0ee351727cb0e7ef41ba6dd2f3f7280a219de More comments and replies (to various people in the thread) below: On 01/08/2016 09:01 AM, Florian Apolloner wrote: > PR1

Re: re-thinking middleware

2016-01-08 Thread Ryan Hiebert
> On Jan 8, 2016, at 12:38 PM, Carl Meyer wrote: > > Yes, you and Ryan are absolutely right, allowing `None` was a mistake > and I've removed it from the spec. For function-based middleware, > there's also the option to simply return the ``get_response`` callable > you were

Re: re-thinking middleware

2016-01-08 Thread Carl Meyer
Hi Ryan, On 01/08/2016 11:48 AM, Ryan Hiebert wrote: > I hadn't considered the option of just returning ``get_response``. > I really like it, because it avoids both raising an exception and > importing a common symbol. > > While class-based middleware factories couldn't just do the same thing >

Re: re-thinking middleware

2016-01-08 Thread Ryan Hiebert
> On Jan 8, 2016, at 12:53 PM, Carl Meyer wrote: > > On 01/08/2016 11:48 AM, Ryan Hiebert wrote: >> >> While class-based middleware factories couldn't just do the same thing >> in the __init__ method, they could do that in a __new__ method instead, >> and then we could make

Re: re-thinking middleware

2016-01-08 Thread Carl Meyer
On 01/08/2016 11:38 AM, Carl Meyer wrote: > On 01/08/2016 04:51 AM, Markus Holtermann wrote: >> Nitpicking, I would also name the settings variable MIDDLEWARES >> (i.e.plural) as it is a list of middlewares, not just one. > > Well, this is a matter of some debate :-) See e.g. >

Lazy operations refactor regression with abstract models #25858

2016-01-08 Thread charettes
During the refactor of lazy operations[1] abstract models stopped resolving their related field model reference by themselves[2][3] in order to prevent pending lookup pollution. This was necessary in order to warn the users about unresolved relationships in a reliable way. This change introduced

Re: Lazy operations refactor regression with abstract models #25858

2016-01-08 Thread Markus Holtermann
That's a nice one, Simon. tl;dr: I favor 2; am OK with 1 but against 3. I was favoring 1) as well. But then thought that app relative relationships actually make sense and the current behavior adds a nice new API feature. This way a 3rd party app can provide an abstract model and require you

PostGres 9.5 Upsert

2016-01-08 Thread bliyanage
Hey Guys, Postgres 9.5 has added the functionality for UPSERT aka update or insert. Any interest in aligning UPSERT on the db layer with the get_or_create or update_or_create functionality in django? Sounds like my company would be interested in doing the work if the PR will get the

Re: PostGres 9.5 Upsert

2016-01-08 Thread Florian Apolloner
Absolutely! On Saturday, January 9, 2016 at 1:13:26 AM UTC+1, bliy...@rentlytics.com wrote: > > Hey Guys, > > Postgres 9.5 has added the functionality for UPSERT aka update or insert. > Any interest in aligning UPSERT on the db layer with the get_or_create or > update_or_create functionality

Re: Vote on Jira as bugtracker

2016-01-08 Thread Hugo Osvaldo Barrera
On Wednesday, January 6, 2016 at 10:09:08 AM UTC-3, Victor Sosa wrote: > > HI, > > I felt like lost using trac; it is kind of messy. I just don't feel > comfortable > with it. > I see so many open source project using Jira that is just natural. Search > is easy, categorize is easy, look

Re: slow migrations

2016-01-08 Thread 'Hugo Osvaldo Barrera' via Django developers (Contributions to Django itself)
On Thu, Jan 7, 2016, at 19:12, Carl Meyer wrote: > On 01/07/2016 03:03 PM, Aymeric Augustin wrote: > > As far as I understand, the CPU cost comes from generating a full set of > > model classes for each step of the migration history. That’s consistent > > with the profile sent by Florian. > > >

group-by promotion

2016-01-08 Thread Curtis Maloney
Hey all, I'm trying to write a PR for adding Postgres9.4's "FILTER" syntax for aggregates, but I've hit a bug I can't figure how to fix [and nobody's awake on IRC :)] https://github.com/django/django/pull/5956 Basically, for the query: qset = FilterAggParentModel.objects.annotate(

Re: Vote on Jira as bugtracker

2016-01-08 Thread Curtis Maloney
On 09/01/16 13:08, Hugo Osvaldo Barrera wrote: Not an actual django developer (I'm a user lurking here really), but I'd still like to chime in: Doesn't make your input any less valid... in fact, perhaps makes it more valuable :) * Jira is too complex. Devs may end up understanding it,