d I should just switch the order of the
operations. If I'm missing something, please let me know.
Tim
On Tuesday, 3 October 2017 21:57:35 UTC+1, Tim Martin wrote:
>
> Hi all,
>
> I've been looking at bug #28542, in which a migration can be played
> forwards but not reve
Hi all,
I've been looking at bug #28542, in which a migration can be played
forwards but not reversed. I think I can see what's happening, but I'm
not 100% sure what the right resolution is, so I wanted to get some
input.
The migration in question looks something like this:
# Start out with
I don't have any objection to removing this. However, the thought occurs
that my patch to the handling of undefined variables could enhance this to
make it more useful. I think we could log in the case where a conditional
expression actually depends on an undefined variable. I haven't thought
a
On Wednesday, 1 March 2017 19:52:22 UTC, Luke Plant wrote:
>
>
> This is a really big backwards incompatibility, as far as I can see. It
> means that any filter may now get passed `UndefinedVariable` instead of
> being passed `None` or string_if_invalid. So for example, the following
> templat
On Monday, 27 February 2017 10:43:02 UTC, Luke Plant wrote:
>
>
>
> On 05/01/17 02:39, Tim Martin wrote:
>
> 2) There appears to be an inconsistency in the default_if_none
>modifier. If I have a template with
>
>x|default_if_none:y = {{x|default_if_none:y}}
>
On Tuesday, 28 February 2017 13:39:21 UTC, Luke Plant wrote:
>
>
>
> On 28/02/17 15:24, Marten Kenbeek wrote:
>
> What about adding a filter |defined that returns True if a variable is
> defined, False otherwise? It may not solve any problems when it's left
> implicit, but at least it allows us
Actually, I can imagine that the option might be worth keeping permanently.
I think both the "exception on use of undefined" and "treat undefined as
different from all other objects" would both be valid modes. Treating
undefined as None is probably only justifiable for backward compatibility,
t
On Friday, 6 January 2017 10:15:22 UTC, Alasdair Nicol wrote:
>
> Hi,
>
> On Thursday, 5 January 2017 17:51:39 UTC, Tim Martin wrote:
>>
>>
>>
>> On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote:
>>>
>>> Hi Tim,
>>>
>>
On Thursday, 5 January 2017 04:15:31 UTC, Carl Meyer wrote:
>
> Hi Tim,
>
> On 01/04/2017 03:39 PM, Tim Martin wrote:
>
> > 1) There are test cases where we have templates that should treat "x
> >is y" as True where x and y are both undefined.
&
Hi all,
I've been looking at bug #24977 (Template variables with a value of
None are considered to be == to non-existent properties). The problem
is that in a template:
{% if user.pk == some_object.invalid_property %}
... this gets rendered when the user is logged out
{% endif %}
This is because
On Monday, 16 June 2014 01:25:45 UTC+1, Josh Smeaton wrote:
>
> Nice work, I think that's a lot better. The only thing that now worries me
> is that order_by doesn't accept sql parameters for some reason. I'm not
> sure how many expressions produce sql_params and if they'd be useful in an
> orde
On Wednesday, 11 June 2014 12:28:20 UTC+1, Josh Smeaton wrote:
>
> > Model.objects.filter(...).order_by( F('fld_a').desc(),
> F('fld_b')).asc() )
> > Model.objects.filter(...).order_by( (F('fld_a')+F('fld_b')).desc() )
>
> I actually really like this. It's simple, clear, and gets around the
>
On Tuesday, 10 June 2014 00:48:14 UTC+1, Josh Smeaton wrote:
>
> > However, I think having some special case code in filter(), annotate()
> and anything else that takes expressions would be OK
>
> I strongly disagree with this. Expressions are context insensitive at the
> moment, which means they
On Monday, 9 June 2014 21:28:51 UTC+1, Tim Martin wrote:
>
>
> On Monday, 9 June 2014 20:44:08 UTC+1, Tim Martin wrote:
>>
>>
>> I'll go ahead and try to implement this using __neg__() to invert the
>> ordering.
>>
>>
> It's still pr
On Monday, 9 June 2014 20:44:08 UTC+1, Tim Martin wrote:
>
>
> I'll go ahead and try to implement this using __neg__() to invert the
> ordering.
>
>
It's still pretty rough, but there's some code in
https://github.com/timmartin/django/tree/order_by_expr
My concern about the filter(foobar_lt=-F('baz')) issue is that it violates
the principle of least surprise: it will be accepted silently and do
something that nobody could expect unless they know a bit about the
internals. However, I think having some special case code in filter(),
annotate() a
On Sunday, 8 June 2014 13:24:01 UTC+1, Josh Smeaton wrote:
>
> I've thought about this previously, and what I had in mind was:
>
> - Expressions should support an ordering parameter of some kind in the
> constructor, and save it to an ordering property. Default to ASC
> - If we go with Marc's sug
es in the ORDER BY compilation logic
(possibly quite substantial), or we can support:
Article.objects.order_by(Desc(LowerCase('title'))
The latter is a lot easier to implement, and strikes me as a nicer API.
However, it's a significant step away from the ordering API we have at th
Funnily enough, I'd already seen that patch but I hadn't figured out the
full significance of it. I attempted to solve #22288
(https://code.djangoproject.com/ticket/22288), but spotted that your patch
would possibly solve the problem entirely, and at the very least breaks my
attempt to solve th
Hi all,
I was looking at implementing the behaviour proposed in #13006
(https://code.djangoproject.com/ticket/13006). In short, the idea is to
allow decorating fields in order_by() with a LowerCase() modifier to apply
LOWER() in SQL before ordering:
Articles.objects.all().order_by(LowerCase
20 matches
Mail list logo
