> Trying it would be really, really valuable. The current situation is
> such that the main ORM lookups are converted, and there is one trivial
> test lookup in examples. This doesn't tell at all how the lookup
> system will work in real world usage.
I went ahead and converted django-hstore [
https://github.com/jordanm/
django-hstore] to use the current version of custom lookups code
(against commit
https://github.com/akaariai/django/commit/842727b324717f5b36d647e6b6433c4664b2143f).
I was able to convert the hstore code so that it passes all tests, and
in addition some new features were added:
query one key:
hstorefield__somekey__lt='someval' (where lt can be replaced by
any lookup supported by CharField).
SQL generated:
hstorefield -> somekey < 'someval'.
query one key, converted as date:
hstorefield__somekey__asdate__lt=date.now() (again, any lookup
supported by DateField will do).
SQL generated:
(hstorefield -> somekey)::DATE < '2013-01-24'
query one key, convert to date, extract year from the date:
hstorefield__somekey__asdate__year__lt=2013 (again, any lookup
supported by DateField will do).
SQL:
(EXTRACT YEAR FROM (hstorefield -> somekey)::DATE) < '2013-01-24'
query if one key is in another queryset:
hstorefield__somekey__in=SomeModel.objects.values_list('somecharfield')
SQL:
hstorefield -> somekey IN (SELECT ... FROM somemodel ...)
It seems that aiming for 100% backwards compatibility for all current
custom lookups isn't a sane goal. django-hstore plays with WhereNode
internals and there is zero chance to make that work. So, aiming for
support of simple existing lookups is a good goal, and aiming for
somewhat easy upgrade path where it is possible to create code that
works both on 1.5 and 1.6 is a good idea (the changed django-hstore
does work on 1.5, too).
The django-hstore changes can be found from
https://github.com/akaariai/django-hstore/compare/custom_lookups.
Other notes:
- Better inbuilt support for nested lookups is needed. The code is
currently non-DRY.
- I want to do queries like:
qs.order_by('hstorefield__somekey__asdate') (or aggregate, annotate,
maybe values_list and values, F())
- Better support for extension registration in database backends. I
think the following hooks/signals would be useful for db backends:
on_module_init(), on_db_create(), on_connect(). Signals seem to be a
good way to do this, though on_module_init() might be sent too
early... maybe pre_first_connect()?.
I think the experiment shows that the custom lookup code is powerful
enough. Nested XML/JSON queries should be possible. For me it is
really hard to say if the API is intuitive enough...
I really wish for testing of the current code. Now is an excellent
time to check that the code will work for your use case! I am very
happy to help in testing (#django-dev is a good channel to contact me,
or just email my akaariai gmail address). Unfortunately I haven't yet
written any docs, but will try to do so soon.
- Anssi