Taken By {{ result.object.taken_by }}
No results found.
{% endfor %} An improved version might look like:: {% for result in page.object_list %} {% if result.content_type == "blog.post" %} {% include "search/includes/blog/post.html" %} {% endif %} {% if result.content_type == "media.photo" %} {% include "search/includes/media/photo.html" %} {% endif %} {% empty %}No results found.
{% endfor %} Those include files might look like:: # search/includes/blog/post.html{{ result.object.tease }}
Taken By {{ result.object.taken_by }}
No results found.
{% endfor %} Real-Time Search ================ If your site sees heavy search traffic and up-to-date information is very important, Haystack provides a way to constantly keep your index up to date. You can enable the ``RealtimeSignalProcessor`` within your settings, which will allow Haystack to automatically update the index whenever a model is saved/deleted. You can find more information within the :doc:`signal_processors` documentation. Use Of A Queue For A Better User Experience =========================================== By default, you have to manually reindex content, Haystack immediately tries to merge it into the search index. If you have a write-heavy site, this could mean your search engine may spend most of its time churning on constant merges. If you can afford a small delay between when a model is saved and when it appears in the search results, queuing these merges is a good idea. You gain a snappier interface for users as updates go into a queue (a fast operation) and then typical processing continues. You also get a lower churn rate, as most search engines deal with batches of updates better than many single updates. You can also use this to distribute load, as the queue consumer could live on a completely separate server from your webservers, allowing you to tune more efficiently. Implementing this is relatively simple. There are two parts, creating a new ``QueuedSignalProcessor`` class and creating a queue processing script to handle the actual updates. For the ``QueuedSignalProcessor``, you should inherit from ``haystack.signals.BaseSignalProcessor``, then alter the ``setup/teardown`` methods to call an enqueuing method instead of directly calling ``handle_save/handle_delete``. For example:: from haystack import signals class QueuedSignalProcessor(signals.BaseSignalProcessor): # Override the built-in. def setup(self): models.signals.post_save.connect(self.enqueue_save) models.signals.post_delete.connect(self.enqueue_delete) # Override the built-in. def teardown(self): models.signals.post_save.disconnect(self.enqueue_save) models.signals.post_delete.disconnect(self.enqueue_delete) # Add on a queuing method. def enqueue_save(self, sender, instance, **kwargs): # Push the save & information onto queue du jour here... # Add on a queuing method. def enqueue_delete(self, sender, instance, **kwargs): # Push the delete & information onto queue du jour here... For the consumer, this is much more specific to the queue used and your desired setup. At a minimum, you will need to periodically consume the queue, fetch the correct index from the ``SearchSite`` for your application, load the model from the message and pass that model to the ``update_object`` or ``remove_object`` methods on the ``SearchIndex``. Proper grouping, batching and intelligent handling are all additional things that could be applied on top to further improve performance. django-haystack-2.4.1/docs/boost.rst 0000644 0000765 0000024 00000007267 12533701133 017762 0 ustar cadams staff 0000000 0000000 .. _ref-boost: ===== Boost ===== Scoring is a critical component of good search. Normal full-text searches automatically score a document based on how well it matches the query provided. However, sometimes you want certain documents to score better than they otherwise would. Boosting is a way to achieve this. There are three types of boost: * Term Boost * Document Boost * Field Boost .. note:: Document & Field boost support was added in Haystack 1.1. Despite all being types of boost, they take place at different times and have slightly different effects on scoring. Term boost happens at query time (when the search query is run) and is based around increasing the score if a certain word/phrase is seen. On the other hand, document & field boosts take place at indexing time (when the document is being added to the index). Document boost causes the relevance of the entire result to go up, where field boost causes only searches within that field to do better. .. warning:: Be warned that boost is very, very sensitive & can hurt overall search quality if over-zealously applied. Even very small adjustments can affect relevance in a big way. Term Boost ========== Term boosting is achieved by using ``SearchQuerySet.boost``. You provide it the term you want to boost on & a floating point value (based around ``1.0`` as 100% - no boost). Example:: # Slight increase in relevance for documents that include "banana". sqs = SearchQuerySet().boost('banana', 1.1) # Big decrease in relevance for documents that include "blueberry". sqs = SearchQuerySet().boost('blueberry', 0.8) See the :doc:`searchqueryset_api` docs for more details on using this method. Document Boost ============== Document boosting is done by adding a ``boost`` field to the prepared data ``SearchIndex`` creates. The best way to do this is to override ``SearchIndex.prepare``:: from haystack import indexes from notes.models import Note class NoteSearchIndex(indexes.SearchIndex, indexes.Indexable): # Your regular fields here then... def prepare(self, obj): data = super(NoteSearchIndex, self).prepare(obj) data['boost'] = 1.1 return data Another approach might be to add a new field called ``boost``. However, this can skew your schema and is not encouraged. Field Boost =========== Field boosting is enabled by setting the ``boost`` kwarg on the desired field. An example of this might be increasing the significance of a ``title``:: from haystack import indexes from notes.models import Note class NoteSearchIndex(indexes.SearchIndex, indexes.Indexable): text = indexes.CharField(document=True, use_template=True) title = indexes.CharField(model_attr='title', boost=1.125) def get_model(self): return Note .. note:: Field boosting only has an effect when the SearchQuerySet filters on the field which has been boosted. If you are using a default search view or form you will need override the search method or other include the field in your search query. This example CustomSearchForm searches the automatic ``content`` field and the ``title`` field which has been boosted:: from haystack.forms import SearchForm class CustomSearchForm(SearchForm): def search(self): if not self.is_valid(): return self.no_query_found() if not self.cleaned_data.get('q'): return self.no_query_found() q = self.cleaned_data['q'] sqs = self.searchqueryset.filter(SQ(content=AutoQuery(q)) | SQ(title=AutoQuery(q))) if self.load_all: sqs = sqs.load_all() return sqs.highlight() django-haystack-2.4.1/docs/conf.py 0000644 0000765 0000024 00000015133 12614423122 017367 0 ustar cadams staff 0000000 0000000 # -*- coding: utf-8 -*- # # Haystack documentation build configuration file, created by # sphinx-quickstart on Wed Apr 15 08:50:46 2009. # # This file is execfile()d with the current directory set to its containing dir. # # Note that not all possible configuration values are present in this # autogenerated file. # # All configuration values have a default; values that are commented out # serve to show the default. from __future__ import absolute_import, division, print_function, unicode_literals import os import sys # If extensions (or modules to document with autodoc) are in another directory, # add these directories to sys.path here. If the directory is relative to the # documentation root, use os.path.abspath to make it absolute, like shown here. #sys.path.append(os.path.abspath('.')) # -- General configuration ----------------------------------------------------- # Add any Sphinx extension module names here, as strings. They can be extensions # coming with Sphinx (named 'sphinx.ext.*') or your custom ones. extensions = [] # Add any paths that contain templates here, relative to this directory. templates_path = ['_templates'] # The suffix of source filenames. source_suffix = '.rst' # The encoding of source files. #source_encoding = 'utf-8' # The master toctree document. master_doc = 'toc' # General information about the project. project = u'Haystack' copyright = u'2009-2015, Daniel Lindsley' # The version info for the project you're documenting, acts as replacement for # |version| and |release|, also used in various other places throughout the # built documents. # The short X.Y version. version = '2.4' # The full version, including alpha/beta/rc tags. release = '2.4.1' # The language for content autogenerated by Sphinx. Refer to documentation # for a list of supported languages. #language = None # There are two options for replacing |today|: either, you set today to some # non-false value, then it is used: #today = '' # Else, today_fmt is used as the format for a strftime call. #today_fmt = '%B %d, %Y' # List of documents that shouldn't be included in the build. #unused_docs = [] # List of directories, relative to source directory, that shouldn't be searched # for source files. exclude_trees = ['_build'] # The reST default role (used for this markup: `text`) to use for all documents. #default_role = None # If true, '()' will be appended to :func: etc. cross-reference text. #add_function_parentheses = True # If true, the current module name will be prepended to all description # unit titles (such as .. function::). #add_module_names = True # If true, sectionauthor and moduleauthor directives will be shown in the # output. They are ignored by default. #show_authors = False # The name of the Pygments (syntax highlighting) style to use. pygments_style = 'sphinx' # A list of ignored prefixes for module index sorting. #modindex_common_prefix = [] # -- Options for HTML output --------------------------------------------------- # The theme to use for HTML and HTML Help pages. Major themes that come with # Sphinx are currently 'default' and 'sphinxdoc'. # html_theme = 'haystack_theme' # Theme options are theme-specific and customize the look and feel of a theme # further. For a list of options available for each theme, see the # documentation. # html_theme_options = { # "rightsidebar": "true", # "bodyfont": "'Helvetica Neue', Arial, sans-serif", # "sidebarbgcolor": "#303c0c", # "sidebartextcolor": "#effbcb", # "sidebarlinkcolor": "#eef7ab", # "relbarbgcolor": "#caecff", # "relbartextcolor": "#262511", # "relbarlinkcolor": "#262511", # "footerbgcolor": "#262511", # } # Add any paths that contain custom themes here, relative to this directory. html_theme_path = ['.'] # The name for this set of Sphinx documents. If None, it defaults to # "No author facets.
{% endif %}{{ result.object.body|truncatewords:80 }}
Sorry, no results found.
{% endfor %} {% endif %} Displaying the facets is a matter of looping through the facets you want and providing the UI to suit. The ``author.0`` is the facet text from the backend and the ``author.1`` is the facet count. 4. Narrowing The Search ----------------------- We've also set ourselves up for the last bit, the drill-down aspect. By appending on the ``selected_facets`` to the URLs, we're informing the ``FacetedSearchForm`` that we want to narrow our results to only those containing the author we provided. For a concrete example, if the facets on author come back as:: { 'dates': {}, 'fields': { 'author': [ ('john', 4), ('daniel', 2), ('sally', 1), ('terry', 1), ], }, 'queries': {} } You should present a list similar to:: .. warning:: Haystack can automatically handle most details around faceting. However, since ``selected_facets`` is passed directly to narrow, it must use the duplicated field name. Improvements to this are planned but incomplete. This is simply the default behavior but it is possible to override or provide your own form which does additional processing. You could also write your own faceted ``SearchView``, which could provide additional/different facets based on facets chosen. There is a wide range of possibilities available to help the user navigate your content. django-haystack-2.4.1/docs/faq.rst 0000644 0000765 0000024 00000011424 12022511244 017364 0 ustar cadams staff 0000000 0000000 .. _ref-frequently-asked-questions: ============================== (In)Frequently Asked Questions ============================== What is Haystack? ================= Haystack is meant to be a portable interface to a search engine of your choice. Some might call it a search framework, an abstraction layer or what have you. The idea is that you write your search code once and should be able to freely switch between backends as your situation necessitates. Why should I consider using Haystack? ===================================== Haystack is targeted at the following use cases: * If you want to feature search on your site and search solutions like Google or Yahoo search don't fit your needs. * If you want to be able to customize your search and search on more than just the main content. * If you want to have features like drill-down (faceting) or "More Like This". * If you want a interface that is non-search engine specific, allowing you to change your mind later without much rewriting. When should I not be using Haystack? ==================================== * Non-Model-based data. If you just want to index random data (flat files, alternate sources, etc.), Haystack isn't a good solution. Haystack is very ``Model``-based and doesn't work well outside of that use case. * Ultra-high volume. Because of the very nature of Haystack (abstraction layer), there's more overhead involved. This makes it portable, but as with all abstraction layers, you lose a little performance. You also can't take full advantage of the exact feature-set of your search engine. This is the price of pluggable backends. Why was Haystack created when there are so many other search options? ===================================================================== The proliferation of search options in Django is a relatively recent development and is actually one of the reasons for Haystack's existence. There are too many options that are only partial solutions or are too engine specific. Further, most use an unfamiliar API and documentation is lacking in most cases. Haystack is an attempt to unify these efforts into one solution. That's not to say there should be no alternatives, but Haystack should provide a good solution to 80%+ of the search use cases out there. What's the history behind Haystack? =================================== Haystack started because of my frustration with the lack of good search options (before many other apps came out) and as the result of extensive use of Djangosearch. Djangosearch was a decent solution but had a number of shortcomings, such as: * Tied to the models.py, so you'd have to modify the source of third-party ( or django.contrib) apps in order to effectively use it. * All or nothing approach to indexes. So all indexes appear on all sites and in all places. * Lack of tests. * Lack of documentation. * Uneven backend implementations. The initial idea was to simply fork Djangosearch and improve on these (and other issues). However, after stepping back, I decided to overhaul the entire API (and most of the underlying code) to be more representative of what I would want as an end-user. The result was starting afresh and reusing concepts (and some code) from Djangosearch as needed. As a result of this heritage, you can actually still find some portions of Djangosearch present in Haystack (especially in the ``SearchIndex`` and ``SearchBackend`` classes) where it made sense. The original authors of Djangosearch are aware of this and thus far have seemed to be fine with this reuse. Why doesn'tModular search for Django
{{ object.content }}
And finally, in ``search/search.html``:: ... {% for result in page.object_list %}| {% trans 'Query' %} | {% trans 'Backend Alias' %} | {% trans 'Timeline' %} | {% trans 'Time' %} (ms) | {% trans 'Kwargs' %} |
|---|---|---|---|---|
|
{{ query.query_string|safe }}
|
{{ query.alias }} | {{ query.time }} |
{% for key, value in query.additional_kwargs.items %}
'{{ key }}': {{ value|stringformat:"r" }} {% endfor %} |