Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Some minor docs fixes #660

Merged
merged 1 commit into from

2 participants

Lorenzo Franceschini Justin Caratzas
Lorenzo Franceschini

No description provided.

Justin Caratzas bigjust merged commit 761d4ac into from
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Oct 4, 2012
  1. Lorenzo Franceschini

    Fixed a few typos in docs.

    seldon authored
This page is out of date. Refresh to see the latest.
2  docs/boost.rst
View
@@ -23,7 +23,7 @@ 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 is a certain word/phrase is seen.
+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
2  docs/faceting.rst
View
@@ -8,7 +8,7 @@ What Is Faceting?
-----------------
Faceting is a way to provide users with feedback about the number of documents
-which match terms they may be interested in. At it's simplest, it gives
+which match terms they may be interested in. At its simplest, it gives
document counts based on words in the corpus, date ranges, numeric ranges or
even advanced queries.
2  docs/glossary.rst
View
@@ -4,7 +4,7 @@
Glossary
========
-Search is a domain full of it's own jargon and definitions. As this may be an
+Search is a domain full of its own jargon and definitions. As this may be an
unfamiliar territory to many developers, what follows are some commonly used
terms and what they mean.
4 docs/inputtypes.rst
View
@@ -125,7 +125,7 @@ Example::
.. class:: haystack.inputs.AltParser
-``AltParser`` let's you specify that a portion of the query should use a
+``AltParser`` lets you specify that a portion of the query should use a
separate parser in the search engine. This is search-engine-specific, so it may
decrease the portability of your app.
@@ -153,7 +153,7 @@ The ``prepare`` method lets you alter the query the user provided before it
becomes of the main query. It is lazy, called as late as possible, right before
the final query is built & shipped to the engine.
-A full, if somewhat silly, example look like::
+A full, if somewhat silly, example looks like::
from haystack.inputs import Clean
2  docs/installing_search_engines.rst
View
@@ -74,7 +74,7 @@ Something like the following is suggested::
suggestions = indexes.FacetCharField()
def prepare(self, obj):
- prepared_data = super(NoteIndex, self).prepare(obj)
+ prepared_data = super(MySearchIndex, self).prepare(obj)
prepared_data['suggestions'] = prepared_data['text']
return prepared_data
2  docs/searchbackend_api.rst
View
@@ -58,7 +58,7 @@ specific to each one.
.. method:: SearchBackend.search(self, query_string, sort_by=None, start_offset=0, end_offset=None, fields='', highlight=False, facets=None, date_facets=None, query_facets=None, narrow_queries=None, spelling_query=None, limit_to_registered_models=None, result_class=None, **kwargs)
-Takes a query to search on and returns dictionary.
+Takes a query to search on and returns a dictionary.
The query should be a string that is appropriate syntax for the backend.
6 docs/searchfield_api.rst
View
@@ -6,7 +6,7 @@
.. class:: SearchField
-The ``SearchField`` and it's subclasses provides a way to declare what data
+The ``SearchField`` and its subclasses provides a way to declare what data
you're interested in indexing. They are used with ``SearchIndexes``, much like
``forms.*Field`` are used within forms or ``models.*Field`` within models.
@@ -108,7 +108,7 @@ to be the primary field for searching within. Default is ``False``.
.. attribute:: SearchField.indexed
-A boolean flag for indicating whether or not the the data from this field will
+A boolean flag for indicating whether or not the data from this field will
be searchable within the index. Default is ``True``.
The companion of this option is ``stored``.
@@ -162,7 +162,7 @@ not to contain any data. Default is ``False``.
Unlike Django's database layer, which injects a ``NULL`` into the database
when a field is marked nullable, ``null=True`` will actually exclude that
- field from being included with the document. This more efficient for the
+ field from being included with the document. This is more efficient for the
search engine to deal with.
``stored``
6 docs/searchindex_api.rst
View
@@ -107,7 +107,7 @@ However, this can also hit the database quite heavily (think
``.get(pk=result.id)`` per object). If your search is popular, this can lead
to a big performance hit. There are two ways to prevent this. The first way is
``SearchQuerySet.load_all``, which tries to group all similar objects and pull
-them though one query instead of many. This still hits the DB and incurs a
+them through one query instead of many. This still hits the DB and incurs a
performance penalty.
The other option is to leverage stored fields. By default, all fields in
@@ -159,7 +159,7 @@ see, the churn rate of your data and what concerns are important to you
The conventional method is to use ``SearchIndex`` in combination with cron
jobs. Running a ``./manage.py update_index`` every couple hours will keep your
data in sync within that timeframe and will handle the updates in a very
-efficient batch. Additionally, Whoosh (and to a lesser extent Xapian) behave
+efficient batch. Additionally, Whoosh (and to a lesser extent Xapian) behaves
better when using this approach.
Another option is to use ``RealTimeSearchIndex``, which uses Django's signals
@@ -236,7 +236,7 @@ you might write the following code::
return "%s <%s>" % (obj.user.get_full_name(), obj.user.email)
This method should return a single value (or list/tuple/dict) to populate that
-fields data upon indexing. Note that this method takes priority over whatever
+field's data upon indexing. Note that this method takes priority over whatever
data may come from the field itself.
Just like ``Form.clean_FOO``, the field's ``prepare`` runs before the
6 docs/searchquery_api.rst
View
@@ -8,7 +8,7 @@
The ``SearchQuery`` class acts as an intermediary between ``SearchQuerySet``'s
abstraction and ``SearchBackend``'s actual search. Given the metadata provided
-by ``SearchQuerySet``, ``SearchQuery`` build the actual query and interacts
+by ``SearchQuerySet``, ``SearchQuery`` builds the actual query and interacts
with the ``SearchBackend`` on ``SearchQuerySet``'s behalf.
This class must be at least partially implemented on a per-backend basis, as portions
@@ -236,8 +236,8 @@ Adds a boosted term and the amount to boost it to the query.
Runs a raw query (no parsing) against the backend.
-This method causes the SearchQuery to ignore the standard query
-generating facilities, running only what was provided instead.
+This method causes the ``SearchQuery`` to ignore the standard query-generating
+facilities, running only what was provided instead.
Note that any kwargs passed along will override anything provided
to the rest of the ``SearchQuerySet``.
6 docs/searchqueryset_api.rst
View
@@ -1,4 +1,4 @@
-_ref-searchqueryset-api:
+.. _ref-searchqueryset-api:
======================
``SearchQuerySet`` API
@@ -303,7 +303,7 @@ amount of time between gaps as ``gap_by`` (one of ``'year'``, ``'month'``,
You can also optionally provide a ``gap_amount`` to specify a different
increment than ``1``. For example, specifying gaps by week (every seven days)
-would would be ``gap_by='day', gap_amount=7``).
+would be ``gap_by='day', gap_amount=7``).
In the search results you get back, facet counts will be populated in the
``SearchResult`` object. You can access them via the ``facet_counts`` method.
@@ -505,7 +505,7 @@ for similar results. The instance you pass in should be an indexed object.
Previously called methods will have an effect on the provided results.
It will evaluate its own backend-specific query and populate the
-`SearchQuerySet`` in the same manner as other methods.
+``SearchQuerySet`` in the same manner as other methods.
Example::
4 docs/utils.rst
View
@@ -12,7 +12,7 @@ Included here are some of the general use bits included with Haystack.
.. function:: get_identifier(obj_or_string)
-Get an unique identifier for the object or a string representing the
+Gets an unique identifier for the object or a string representing the
object.
-If not overridden, uses <app_label>.<object_name>.<pk>.
+If not overridden, uses ``<app_label>.<object_name>.<pk>``.
Something went wrong with that request. Please try again.