Overlap between Func and Transform

[Alex Hill]

Hi list,

The thread about reimplementing the date-based lookups[1] reminded me of something that was bugging me a couple of days ago.

There's some overlap between Funcs (of arity 1) and Transforms. They seem to fundamentally do the same thing – wrap an expression in some arbitrary SQL – but with a different interface.

It seems wrong that some functionality can be tied up in a Transform and not available as a Func, and vice-versa. For instance, the built-in Length function isn't available as a transform, and the built-in contrib.postgres Unaccent transform isn't available as a function.

It would be good to be able to easily register functions of arity 1 as transforms, using a decorator for example, to make them available in both contexts.

Can all possible transforms be defined like this? That is, are transforms strictly a special case of functions or can they do more?

Cheers,

Alex

[1] https://groups.google.com/forum/#!topic/django-developers/WYWrQkBJ2hs

[Josh Smeaton]

FWIW I put a rough patch together awhile ago (I can't find it or the discussion unfortunately) that attempted to make Transforms usable as expressions.

They share partial APIs but not the full set which made that first attempt quite messy/hacky. I'm not aware of any reasons that they couldn't be combined

in some way.

Cheers

[Anssi Kääriäinen]

Transforms are just single argument expressions available using lookup strings. The biggest complication is that Transforms have slightly different API to expressions.

I don't see a reason why transforms couldn't be a special case of expression. There are some API incompabilities, but they should be solvable.

[Josh Smeaton]

Also, found the patch I wrote: https://gist.github.com/jarshwah/a541857db195f0486b9e

Instead of multiple subclasses, perhaps Func could take on some of the functionality of transform directly, but that makes no sense for > 1 arity functions. A nice design should be able to be found.