SearchQuerySet / spelling_query oddity

[Chris Adams]

Does anyone know the history of spelling_query support? I need to pass an alternate text query through so spelling suggestions can run against it rather than my raw AltParser dismax query. I'm either badly confused (it is Friday) or does the lower-level spelling_query support not have a corresponding interface which you could use on a SearchQuerySet?

If nobody else is working on this, I was thinking about adding a `spelling_query()` method to SearchQuerySet and add some tests.

Chris

[Daniel Lindsley]

Chris,

That’s a certifiable antique. It landed in https://github.com/toastdriven/django-haystack/commit/167030ae1e34e8e4ab5f765b5c4fcd62e6c7ad69. Prior to that commit, spelling suggestions were made off the *generated* query, which could frequently give you a nonsense suggestion. This allows you to specify a different string to generate the suggestions based on. The common usage is ``SearchQuerySet().spelling_suggestion(‘whatevre’)``, which passes it along until it gets to the low-level backend. Is this what you’re talking about?

I have no problems with further improvements to the spelling support regardless, so I’m really hoping you just ran with the idea anyhow.

Daniel

--
You received this message because you are subscribed to the Google Groups "Haystack Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-haystack...@googlegroups.com.
To post to this group, send email to django-ha...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-haystack-dev.
For more options, visit https://groups.google.com/groups/opt_out.

[Chris Adams]

Okay, we should make a decision about this. There's an argument that for Solr passing "spellcheck.q" would avoid a separate request and allow you to use spelling suggestions with complicated queries, altparser, etc. We could set some sort of method to set the spelling suggestion text without executing the query and perhaps even have auto_query call that implicitly.

The other possibility is to say this is a little too magic, update the documentation to recommend .spelling_suggestion(query) because that interface is standard across backends and it also avoids the confusion which comes in where sqs.filter(…simple query…).spelling_suggestion() works but sqs.filter(…complicated query / altparser…).spelling_suggestion() does not. This does have the appeal of allowing us to remove more code and generally pushing things in the direction of making

I like the idea of not conflating two different types of query but want to think about this more.

Chris