Django: Ticket Query
https://code.djangoproject.com/query?id=21863%2C22124&order=priority
The Web framework for perfectionists with deadlines.en-USDjangohttps://www.djangoproject.com/s/img/site/hdr_logo.gif
https://code.djangoproject.com/query?id=21863%2C22124&order=priority
Trac 1.0.12
https://code.djangoproject.com/ticket/21863
https://code.djangoproject.com/ticket/21863#21863: Consider adding get_transform() to supplement get_lookup()Thu, 23 Jan 2014 13:32:28 GMTakaariai<p>
Currently the API for get_lookup() is get_lookup(lookup_name). However, there are situations where a field will need more information to decide if it needs to return a lookup or a transform. Consider HStoreField. A candidate API for HStoreField is that:
</p>
<ul><li><tt>hstore_field__exact=val</tt> => exact lookup against the hstore_field
</li><li><tt>hstore_field=val</tt> => also exact lookup against the hstore_field
</li><li><tt>hstore_field__exact__exact=val</tt> => get key exact from hstore, do an exact lookup against that
</li><li><tt>hstore_field__nonlookup=val</tt> => get key nonlookup from hstore, do an exact lookup against that
</li></ul><p>
This is similar to how <tt>fk__exact</tt> and <tt>fk__exact__exact</tt> work currently if the model pointed by fk has field named exact.
</p>
<p>
In addition, we want to support transforms in .values() etc calls in the future. So <tt>hstore_field__exact</tt> should always resolve to transform if used in values().
</p>
<p>
Currently this is impossible to do. The get_lookup() method doesn't know if there are still further lookups in the path. It knows just the current lookup. If we are resolving path <tt>exact__exact</tt> get_lookup() should return transform for the first <tt>exact</tt>, lookup for the second <tt>exact</tt>. If we are resolving just <tt>exact</tt>, then lookup should be returned for the first 'exact'. When resolving <tt>exact</tt> for <tt>.values('hstorefield__exact')</tt> call in later releases, the <tt>exact</tt> should resolve to transform.
</p>
<p>
If we add get_transform() method we could change the lookup resolution code in the ORM to do:
</p>
<ul><li>for non-final lookups: always use get_transform()
</li><li>for final lookup in filter() calls: try get_lookup(lookup_name). If that doesn't return anything, use get_transform(lookup_name) + get_lookup('exact').
</li><li>for any lookup in .values() etc calls: always use get_transform()
</li></ul><p>
The above examples would be resolved as follows:
</p>
<ul><li><tt>hstorefield__exact=val</tt>: get_lookup('exact') -> match, so use exact lookup against hstorefield
</li><li><tt>hstorefield=val</tt>: get_lookup('exact') -> same as above
</li><li><tt>hstorefield__exact__exact=val</tt>: get_transform('exact'), get_lookup('exact') -> match, so use exact lookup against key exact of hstorefield
</li><li><tt>hstorefield__nonlookup=val</tt>: get_lookup('nonlookup') -> no match, so try get_transform('nonlookup') + get_lookup('exact') -> exact lookup against key nonlookup
</li></ul><p>
The values() call will use always get_transform() so <tt>.values('hstorefield__exact</tt>)` will work correctly.
</p>
<p>
There might also be need to add register_transform() method. If we have only register_lookup() but methods get_lookup() and get_transform() it might lead to some confusion.
</p>
<p>
Adding register_transform() will break the API, but that is hopefully OK during alpha.
</p>
Resultshttps://code.djangoproject.com/ticket/21863#changelog
https://code.djangoproject.com/ticket/22124
https://code.djangoproject.com/ticket/22124#22124: Expand the Documentation of Custom Lookups for V1.7Sat, 22 Feb 2014 16:03:21 GMTmzaanen<p>
Custom Lookups look great, however, I find the documentation terse. Example: no explanation what
</p>
<div class="code"><pre>lhs<span class="p">,</span> lhs_params <span class="o">=</span> <span class="bp">self</span><span class="o">.</span>process_lhs<span class="p">(</span>qn<span class="p">,</span> connection<span class="p">)</span>
</pre></div><p>
is exactly.
</p>
<p>
The explanation:
</p>
<blockquote class="citation">
<p>
lhs
The lhs (left-hand side) of a lookup tells us what we are comparing the rhs to. It is an object which implements the query expression API. This is likely to be a field, an aggregate or a subclass of Transform.
</p>
</blockquote>
<p>
does not explain what <tt>lhs_params</tt> might be. Also a search on <tt>process_lhs</tt> on complete Django website only points to this page (no other pages).
</p>
Resultshttps://code.djangoproject.com/ticket/22124#changelog