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, but
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(
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.
> >
> >
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 throu
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 i
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 traction.
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 to
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
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.
> https://github.com
> 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 returning the ``get_
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
> i
> 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 given, which has the
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
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, Andre
> 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 to disable a middleware.
>
> I definitely agree with this c
> 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”, I would require
> raising Middleware
+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 No
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 appro
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
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, *
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 wrot
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
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
> https://github.com/
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 to
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 <
cur...
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 s
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 least,
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 b
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 forms, *with or without
29 matches
Mail list logo
