Fix: Merge conflicts

Author: GitauHarrison

search/implement_elasticseach.md

@@ -84,11 +84,11 @@ We are going to search data generated by users in an app. We, therefore, need to
 ![Sample project](/images/elasticsearch/sample_project.png)
 
 The key things that your application will need to have are:
-- A model or models used to store user data (`Post` model has been used in the sample project)
+- A model or models used to store user data (the `Post` model has been used in the sample project)
 - A form that allows users to post something
 - A page that displays all the data users posted in the app
 
-Your navigation bar does not necessarily need to have a search form as seen in the image above. In a subsequent section below, we will learn how to add one such that it will available across all web pages of the app.
+Your navigation bar does not necessarily need to have a search form as seen in the image above. In a subsequent section below, we will learn how to add one such that it will be available across all web pages of the app.
 
 
 ## Understanding Elasticsearch
@@ -255,7 +255,7 @@ def add_to_index(index, model):
         return
     payload = {}
     # Add the fields to be searched to a payload after looping through 
-    # the selected fields of the model
+    # The selected fields of the model
     for field in model.__searchable__:
         payload[field] = getattr(model, field)
     app.elasticsearch.index(index=index, id=model.id, body=payload)
@@ -419,12 +419,13 @@ class SearchableMixin(object):
         session._changes = None
 ```
 
-Just before a session is committed, the `before_commit()` handler will allow us to check what object has been added, modified, or deleted through `session.new`, `session.dirty` and `session.delete` respectively. These objects are not going to be available anymore after a commit is made. `session._changes` dictionary allows us to save the objects and have them survive a commit since we shall be using them to update the Elasticsearch index. 
+Just before a session is committed, the `before_commit()` handler will allow us to check what object has been added, modified or deleted through `session.new`, `session.dirty` and `session.delete` respectively. These objects are not going to be available anymore after a commit is made. `session._changes` dictionary allows us to save the objects and have them survive a commit since we shall be using them to update the Elasticsearch index. 
 
-As soon as a session has been successfully committed, this is the proper time to make changes on the Elasticsearch side of things using `after_commit()`. We begin by iterating over what has been added, modified, or deleted and make corresponding calls to the indexing functions in the `search` module for objects with `SearchableMixin`.
+As soon as a session has been successfully committed, this is the proper time to make changes on the Elasticsearch side of things using `after_commit()`. We begin by iterating over what has been added, modified or deleted and make corresponding calls to the indexing functions in the `search` module for objects with `SearchableMixin`.
 
 We can include a simple `reindex()` helper method that can allow us to refresh an index with all the data on the relational side. You may experience instances where you have to manually update the Elasticsearch index to ensure the latest changes are applied. 
 
+
 ```python
 class SearchabelMixin(object):
     # ...
@@ -435,6 +436,7 @@ class SearchabelMixin(object):
             add_to_index(cls.__tablename__, obj)
 ```
 
+
 Given that `reindex` is a class method, you can run `Model.reindex()` to update the Elasticsearch index. Finally, to ensure that SQLAlchemy listens to database change events, we can call the function `db.event.listen()` from SQLAlchemy. This function serves to call `before_commit` and `after_commit` methods before and after each commit respectively. 
 
 ```python
@@ -456,7 +458,8 @@ class Post(SearchableMixin, db.Model):
     # ...
 ```
 
-With this minor change to the `Post` model, we can maintain a full text search for posts. Let us begin by initializing all the indexes from the posts currently in the database:
+With this minor change to the `Post` model, we can maintain a full text-search for posts. Let us begin by initializing all the index from the posts currently in the database:
+
 
 ```python
 >>> Post.reindex()
@@ -643,4 +646,4 @@ Pagination is cleverly handled using the number of pages available depending on
 
 You should see this:
 
-![Search results](/images/elasticsearch/search_results.png)
+![Search results](/images/elasticsearch/search_results.png)