Week 14 - IDB3

Hey,

It's Easter Sunday, and it's the day before the second to last week of classes. I know I should be talking more about the previous week, and I will, but I thought it might be nice to put this post into some temporal context. I'd like to detail here an overview of the process one specific feature that my team worked on to give a bit of insight of working on this project. If you are interested in learning more about the process, I believe we will be posting our technical report on our site in the future. Check it out -> http://blooming-shelf-7492.herokuapp.com/

This past Thursday, the third and final iteration of our latest project, SBIDB, was turned in. The turnin for this project gave us the first major Heroku issue that we have had thus far, and therefore we were unable to turn it in as a working project on time. My team, thank them mucho, met up on Friday to debug what the issue was. As it turns out, we were able to turn in our project from our last commit on the due date and still get graded from that point due to an obvious bug in our Heroku deployment. After all of the commits and headbanging, it is really confusing as to why the build did not work out from the start, but I am very glad that it is up and running and looking as we hoped it would. 

For this iteration, we were to implement a search functionality to our site to search through the contents of our database, and return contextualized relevant information via the search. At first, we attempted to use an add-on to Heroku, SearchBox Elasticsearch. To use this with Django, you use a modular search package called Haystack. Well, long story short, we had a bear of a time trying to get these to work together, with our code, and deploy correctly on Heroku, and in the end we scrapped it. We searched for another method of implementing this beyond using the ORM of Django for ourselves. 

We found another package called django-watson to search, and found this to work very simply out of the box for a simple search. Upon testing this search, however, we realized that this module, while its documentation described some functionality that we desired, did not seem to offer what we were looking for in terms of searching for ForeignKey relations in our Django models, and therefore our SQL database. This, along with creating search results that display multi-word OR results gave us some added trouble when needing to fulfill our requirements and get this project turned in. So, we modified the search to offer us both single results of each word searched as well as the built-in ANDed results from django-watson.

To take this part of the story back to the beginning, we also added a highlight function to our search to highlight the search terms on the search results page using a custom Django template filter. When implementing this functionality, we originally placed the code within the django-watson package, and realized that later, this would probably cause some issues with Heroku when rebuilding the virtual environment, so we moved the code into its own pseudo-package. Well, when we were at the final point of realizing that we had a problem with our turnin, we thought that this move, and implementation completely, is what caused our errors on the server. This last ditch effort was very frustrating as a team, and left many of us feeling pretty poorly about our final product. But at this point, again, I think this finally turned out to be just about exactly what we expected. 

All right, I'm out of here for this week. My team has a presentation to hammer out, and a test to start studying for.

See ya next time,

Sophie