Allow Func Expressions to be used as Transforms

[Josh Smeaton]

I can't seem to find a ticket mentioning this, though we have discussed it before. Please close if you can find a related ticket.

Func Expressions and Transforms are extremely similar in API, but not enough to be interchangeable. Transforms are 1-arity (usually - postgres.array.IndexTransform is a notable exception) Functions with special behaviour.

Instead of implementing a Length Func and a Length Transform, we should be able to implement a Length Func and register that same class as a Transform. That's not currently possible because of the slight differences in API and behaviour. We should resolve this ASAP.

[Josh Smeaton]

Experiment PR: ​https://github.com/django/django/pull/4482

[Josh Smeaton]

​https://github.com/django/django/pull/5090 is the newest PR to tackle this patch. It still needs some tidying up, docs, and maybe some tests. But I'm happier with the approach used here than the previous couple we've thrown together.

There's no bridge/compat layer here. Instead, Transforms are now handled independently from Lookups, allowing Transform to be removed and replaced with Func. A nice side effect of converting Transforms to expressions is that the RHS of lookups can now be an expression, paving the way for an object based filtering pattern similar to:

Model.objects.filter(StartsWith(F('field'), Lower(Value('my_value')))

This trivial example isn't as nice as the traditional string based filtering, but it's easy to imagine situations where you're passing around objects that can be used as annotations or filters, and just dumping them straight in unaltered.

[Josh Smeaton]

The PR attached may also fix https://code.djangoproject.com/ticket/22288

[Tim Graham]

Seems to be ready for more review as tests are now passing.

[Josh Smeaton <josh.smeaton@…>]

In 534aaf5:

Fixed #24629 -- Unified Transform and Expression APIs