brittballard · December 16, 2015 20:10 · Apr 30, 2013 · Apr 30, 2013
diff --git a/blue sky pg search b/blue sky pg search
@@ -6,4 +6,10 @@ Once the decision had been made to use a gem the question of which gem was the n
 
 Using pg_search does have one unfortunate limitation. As it's currently implemented there is no way to limit search to specific accounts. Because of the way this gem is written the model associated with the pg_search_documents table lives within in the gem, so unlike other gems that introduce models into your app (Clearance, Devise, etc) we don't control the model the gem does. If we were able to modify the model we could have just added a new before_create filter that set an account_id attribute we created on the model. Unfortunatly this wasn't an option. This left us with two choices:
   1. Don't add the account_id column to the pg_search_documents table and write custom sql that left joins all the tabels we want to search content for to the pg_search_documents table and use their account_id columns.
-  2. Add the account_id column to the pg_search_documents table and introduce a monkey patch the PgSearch::Document model that lives in the pg_search gem (
+
+  2. Add the account_id column to the pg_search_documents table and introduce a monkey patch the PgSearch::Document model that lives in the pg_search gem (https://github.com/Casecommons/pg_search/blob/master/lib/pg_search/document.rb.)
+
+We chose option two and here is why:
+  1. If we went with the custom query route we would have had to left join every table that we wanted to be searchable. This would have been a huge query and left joins are not performant.
+  2. The query would need to be maintained. If you ever wanted to add a new searchable entity you would have to update a large unweidly query and that large unweildy query would get less performant.
+  3. In addition to the poorly performing 
diff --git a/blue sky pg search b/blue sky pg search
@@ -0,0 +1,9 @@
+Why did we monkey patch PgSearch::Document?
+
+After reseraching potential solutions it was obvious our best course of action was to use Postgresql's built in full text search indexing to accomodate BlueSky's search needs. After coming to this decision we had to make the decision would we rather build our own custom solution, or use one of several gems available. While I'm typically a fan of custom builds when possible, after reviewing some of the source of two gems (pg_search and textacular) it was easy to do a cost benefit analysis and decide that using a gem in this case was the best course of action.
+
+Once the decision had been made to use a gem the question of which gem was the next in line. After doing some research pg_search was the winner because of the internationalization and more complex requirements we like the additional flexability and features pg_search provides (many of which are outlined here https://github.com/Casecommons/pg_search#searching-using-different-search-features.) 
+
+Using pg_search does have one unfortunate limitation. As it's currently implemented there is no way to limit search to specific accounts. Because of the way this gem is written the model associated with the pg_search_documents table lives within in the gem, so unlike other gems that introduce models into your app (Clearance, Devise, etc) we don't control the model the gem does. If we were able to modify the model we could have just added a new before_create filter that set an account_id attribute we created on the model. Unfortunatly this wasn't an option. This left us with two choices:
+  1. Don't add the account_id column to the pg_search_documents table and write custom sql that left joins all the tabels we want to search content for to the pg_search_documents table and use their account_id columns.
+  2. Add the account_id column to the pg_search_documents table and introduce a monkey patch the PgSearch::Document model that lives in the pg_search gem (