> 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 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
