I don't think we need split-to-subq support for Lookups before we make
them expressions. Lookups as expressions are usable outside .filter(),
and we need the split-to-subq support only in .filter(expression).
- Anssi
On Wed, Sep 30, 2015 at 8:46 AM, Josh Smeaton wrote:
> I'm mixing my versions,
I'm mixing my versions, sorry to those following along. 1.9 has just
reached alpha. Lookups as Expressions should be doable for 1.10 which
master is currently tracking.
Cheers
On Wednesday, 30 September 2015 15:31:24 UTC+10, Josh Smeaton wrote:
>
> The alpha for 1.10 has already been cut, and I
The alpha for 1.10 has already been cut, and I'm not sure that the kinds of
changes needed here are appropriate to add now that the alpha is out. One
could *maybe* make the argument that changing Lookup to an Expression now
rather than later is the right move considering Transforms just underwen
On the core ORM side we need to make
.exclude(LessThan(F('friends__age'), 30)) do a subquery. This way
.exclude(friends__age__lt=30) does the same thing as the expression
version. This isn't that easy to do. If we just use
resolve_expression, then the friends relation will generate a join,
and the
Thanks Marc& Shai for taking the time to look at this. Apologies for the
late response as I was busy.
Yes, I agree that decorators can be used to tag urls, however I think that
the way that the URL rework code applies decorators can be improved.
The reason I've called the decorators approach 'hea
1. Lookups should become Expressions, just as Transforms have become
Expressions. This will let us process Lookup arguments as Expressions all
the way the way through. I think this should be a major goal for version
1.11.
2. Chaining transforms is now possible since they are just Func
expressi
Here is a list of issues to solve to support explicit transforms and
lookups by filter (and exclude) methods.
1. Make Lookup.__init__ signature to support initialization with F objects
or string path (e.g. GreaterThan(F('user__id'), 10) or
GreaterThan('user__id', 10)), not sure it's possible to
In DAL we mostly moved autocomplete_light/__init__.py to
autocomplete_light/shortcuts.py, and we're trying to make a fuss about
it on internet so that users using google before opening issues find
it :D
It would be great if other libraries used the same renaming for the
sake of consistencies betwe
