Suggestion: reduce dependency - full text-search / django-haystack

First of all, thanks for sharing such an awesome project! It’s really great.

Regarding this issue / suggestion - it would be great if we can reduce dependency such as django-haystack. It’s another great project, but it appears to be a bit outdated, especially their ElasticsearchSearchEngine implementation. I’m also getting the following warning with SimpleEngine (update_index … even though it says it has indexed it):

haystack/backends/simple_backend.py:41: UserWarning: update is not implemented in this backend
  warn('update is not implemented in this backend')

… which is related to https://github.com/ellmetha/django-machina/issues/85#issuecomment-426107733 … but shows no result on the search.

For simple / small forums, django __search or __icontains is probably good enough? In any case, I will try to see if I can take a stab at it.

[ellmetha]

To add more precision regarding this, I plan to completely rewrite the forum_search application and introduce search backend mechanism that would be built in django-machina. At first we could image releasing something with only two backends: a default one working with all database backends, and another one for PostgreSQL. In the future other backends could be added depending on the needs (elasticsearh, etc). 😉

[BoPeng]

I landed on this thread while looking at the whole machina/haystack issue. It is clear to me that haystack is no longer maintained and should be removed from machina.

The way to move forward, may I suggest, is to develop separate search functions for each search engine. For example, a new machina-search-elasticsearch app that uses django-elasticsearch-dsl could be added for elastic search. Support for other search engines can be added in a similar fashion.

I believe that this is the easiest way to avoid the entire haystack dilemma, namely trying to come up with a “common ground” or “abstract layer” for all search engines (which is a revamped machina-search app for the case of machina) but ends up not supporting any of them well.