#27732: django.contrib.postgres.search SearchRank doesn't handle
SearchVectorField
references
----------------------------------+--------------------------------------
Reporter: Matt Hoskins | Owner: (none)
Type: Bug | Status: new
Component: contrib.postgres | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
----------------------------------+--------------------------------------
Comment (by Matt Hoskins):
After further musing and taking into account:
* The documentation describes passing in a vector and a query into
SearchRank
* The example included with the above shows passing in SearchVector and
a SearchQuery objects only (and not strings)
* Marc's point "I think supporting the simple string version in both
cases (when it is or is not a SearchVector) already is somewhat confusing
personally"
* My feeling that the intuitive way to reference a SearchVectorField as
the first argument to SearchRank would be to pass in a string (given other
functions, like the DateTime ones, accept a string if you want to
reference a field of the correct type, although I note that they do list
their first argument as "expression").
* The DateTime functions use resolve_expression to validate the type
that their first argument resolves into
* It's possible in postgresql to have a column of type tsquery - I can't
think why anyone would ever want to (no use case seems likely), but there
would be some logical consistency in allowing the second argument of
SearchRank to be a reference to a related query column via the potential
to implement SearchQueryField
... then one course of action that springs to mind is to deprecate passing
in strings to SearchRank except where a string for vector resolves into a
SearchVectorField:
* Perhaps apply my patch in a point release (although it's possible, as
Marc suggested, to work around using "F()" for now)
* In the next version (minor/major) use my patch but also emit a
deprecation warning if the resolving of the vector argument doesn't result
in a SearchVectorField type result and also emit a deprecation warning if
the query argument isn't a SearchQuery
* For the documentation of SearchVectorField perhaps mention that a
string can be passed in to reference one in SearchRank to make it clear
that's how to do it
* Once deprecation is complete perhaps check the types of what the
vector and query arguments resolve into and, like with the DateTime
functions, raise ValueError if they don't resolve into the correct type.
There may be good reasons for adopting a different approach of course
(such as the simplest case of just documenting Marc's "work around" as the
official way to reference a SearchVectorField as the vector argument to
SearchRank), these are just my musings!
--
Ticket URL: <https://code.djangoproject.com/ticket/27732#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/070.8184bcb611bd6a0f6bdd4f43abbb94ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
