+1 to not requiring all transforms to handle __underscore__ syntax.
I think what we want to do is allow users choose which syntax they
prefer. The idea is that Django will support both JSONExtract('data',
path=['owner', 'other_pets', 0, 'name']) and
data__owner__other_pets__0__name out of the box.
No, not all Lookups or Transforms are required to handle __underscore__
syntax. The entire point of supporting object based lookups is to handle
cases that get more complex than a single argument transform or a left and
right hand side lookup.
In particular, I think your Decode(utf8) example is
Hi Mark,
I can explain why long string is a bad design (other than anything I
described earlier). In fact it assumes that the additional parameters can
be serialized into alphanumeric string, which apply additional and
unnecessary limitation. In my example above, it's not clear how to pass
"ut
I don't think complex cases need to have __ equivalents, but I also dispute
that long chains like that are necessarily a bad API, I don't find your
option 1 particularly neat compared to option 2. Worth noting though that
you've used a 2-valued function there which is not a lookup in the same
sense
For what it's worth, on my machine `time ./tests/runtests.py` takes about
~40 minutes for the Oracle 11 VM and ~53 minutes for the Oracle 12 VM
(averaged over 3 runs for each).
On Thursday, September 24, 2015 at 8:53:05 PM UTC-4, Shai Berger wrote:
>
> Hi,
>
> On Friday 25 September 2015 00:34:
I'll try to turn lookups into expression (will use master branch).
I also have a question. Meanwhile the old query syntax with underscores is
pretty good for simple queries (like Model.objects.filter(name='Bob'), it
gets really ugly for parametrized calls, a new JSONField is a good example
of th
