Django

Code

Ticket #6261 (closed: fixed)

Opened 1 year ago

Last modified 10 months ago

Add support for customized WhereNode's and QUERY_TERMS.

Reported by: jbronn Assigned to: mtredinnick
Milestone: Component: Database layer (models, ORM)
Version: queryset-refactor Keywords: qs-rf where wherenode query terms gis
Cc: Triage Stage: Accepted
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

In order to get GeoDjango working with the queryset-refactor branch, a few modifications were needed to the Query class. Specifically, the GeoQuery subclass of Query needs to the GeoWhereNode instead of the regular WhereNode for the construction of spatial SQL. Moreover, QUERY_TERMS are still hard-coded in the Query class, which also needs to be extended so that geographic lookup types (e.g., within, intersects) are recognized.

This patch adds the where keyword (which sets a where_class attribute of the Query class) to Query.__init__ as well as a get_terms function, both of which may be used and/or overloaded by subclasses. I'm open to suggestions for improvement.

Attachments

query_wherenode.diff (5.0 kB) - added by jbronn on 12/21/07 15:15:52.
Patch adding customization options to the Query class.

Change History

12/21/07 15:15:52 changed by jbronn

  • attachment query_wherenode.diff added.

Patch adding customization options to the Query class.

12/21/07 19:15:43 changed by mtredinnick

  • needs_better_patch changed.
  • stage changed from Unreviewed to Accepted.
  • needs_tests changed.
  • needs_docs changed.

I've been thinking along the same lines, particularly after discussions with you and Jeremy in Lawrence. I think it's probably worth making the WhereNode? a class attribute, rather than something to pass to __init__, since then you set it up once and that's done.

Adding extra lookup terms could be done via an attribute or an __init__ parameter. I want to test that and think about which API works easiest (speed is really important in Query and function calls are more expensive than attribute lookups).

I'm guessing you need the WhereNode subclass so that you can override make_atom()? Jeremy and I talked about adding a hook in there for extra lookup types -- would that make that work a bit easier? You wouldn't have to override make_atom() entirely, but, instead, add a new method that is called when none of the standard lookups are matched in the normal processing path. You'd probably still need to subclass (and no reason not to, I guess), but that would make adding new lookup types work.

I'll try to land something in the next couple of days so that we can all work with the same API. I'm also working on spreading the new Query support throughout the rest of core so the branch will be runnable, which might help you a bit, too. That's the over-Christmas project.

12/21/07 19:16:37 changed by mtredinnick

  • version changed from other branch to queryset-refactor.
  • summary changed from queryset-refactor: Add support for customized WhereNode's and QUERY_TERMS. to Add support for customized WhereNode's and QUERY_TERMS..

01/27/08 05:23:49 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

Fixed in [7031].

Add/Change #6261 (Add support for customized WhereNode's and QUERY_TERMS.)




Change Properties
Action