ClairvoyantGivesBack – How do we know we have a great team?



While we usually talk about technology here, today we would like to take the opportunity to thank all the employees at Clairvoyant who participated in a team charity event at FMSC on Tuesday. This is one of the posts that will give a small glimpse into our culture and team spirit we strive for at Clairvoyant.

Our team of volunteers gave an hour of their time to help pack food for the most needy kids in the world. A small Clairvoyant team of 15 members, along with few other volunteers helped pack one meal for nearly 11,000 kids at FMSC. It is a sad fact that nearly 6200 kids die of starvation everday worldwide. While this used to be a much higher number till not too long ago, efforts by various organizations have reduced this number significantly. We are just glad to contribute in our own way.


While we know we have a great team at Clairvoyant, it is amazing to see how much they care about giving back to the community. We reserved 15 volunteer slots at FMSC and in one day we pretty much filled all spots. We feel very fortunate to have such a great team that is willing to take some time from their busy lives to support a great cause.

Our days are all packed and busy, whether it is building awesome software, working on constantly improving our skill sets and more importantly balancing time with family. But taking some time out of our packed schedules and using that to improve the world we live in is a great feeling. At Clairvoyant we are doing our best to help our employees adopt a better (healthier) life style, better care for them and their families and making it truly a great place to work and learn. It is great to see our employees are happy to think beyond just themselves, and give a hand to make this world a better place.

Earlier this year – we conducted a weight loss competition internally to promote a healthier lifestyle – you can see some great tips from the winner here. On similar lines we requested all of our employees to skip their sodas this month donate that money towards charity. To show their appreciation, our management matched whatever donations employees contributed towards this cause. We were hoping to collect a few hundred dollars, but, just like they do in their professional life, our employees exceeded all of our expectations and collected nearly $1000 in less than a month. Overall, Clairvoyant as an organization donated enough money to provide for nearly 10,000 nutritious meals as part of this drive. We are very proud of #teamclairvoyant. Go Team!!


As an organization we are very committed to giving back to our community. If you have ideas or would like to request our volunteers for a specific cause feel free to drop us a line


Elasticsearch implementation in Django using Haystack

Haystack for Django framework provides a powerful but easy way to integrate common search backends like Elasticsearch, Solr, Whoosh and more. It’s API closely mirrors the Django APIs making it easy for developers to get started. Haystack can be setup with multiple search backends in the same app enabling it to call any backend for indexing or querying.


Install the django haystack package using: pip install django-haystack and add ‘haystack’ to INSTALLED_APPS in the settings file. At this point, we are ready to plugin a search backend of our choice. Assuming, Elasticsearch is already installed, we will add it to the required ‘HAYSTACK_SETTINGS’.

 ‘default’: {
 ‘ENGINE’: ‘haystack.backends.elasticsearch_backend.ElasticsearchSearchEngine’,
 ‘URL’: ‘’,
 ‘INDEX_NAME’: ‘myindex’, 

Let’s dissect the above settings: ‘default’ is the name given to the backend. If multiple backends are used, one of them must to be named default to tell Haystack which backend to use if not explicitly specified. You can use the ‘using’ clause to explicitly specify the backend.

sqs = SearchQuerySet().all().using('solr')

‘ENGINE’ specifies the path to the package with the default backend settings file. In the above example, we are pointing to the default Elasticsearch backend settings file provided in the Haystack package. This file contains out of the box Elasticsearch specific settings for most common uses. The default file can be extended to use a custom backend.
‘URL’ as the name suggests is the server URL of the search backend. The URL can be parameterized for different environments.
‘INDEX_NAME’ is the name of the Elasticsearch search index where all the indexed data is stored on disc.

Handling Data

Haystack determines what data should be placed in the search index. To specify the models that need to be indexed we need to subclass indexes.SearchIndex and indexes.Indexable. Within the class we can specify the individual fields to be indexed.

        class UserIndex(indexes.searchIndex, indexes.Indexable):
            text = indexes.charField(document=True, use_template=True)
            name = indexes.charField(model_attr = ‘name’)
            created_date = indexes.DateTimeField(model_attr=’created_date’)

        def get_model(self):
            return User

Every SearchIndex requires that only one field be marked with document=True. The field is named ‘text’ to follow Haystack naming convention. It can be modified but not recommended. Document = True tells haystack to use the ‘text’ field as the primary field for searching within. Specifying ‘use_template=True’ enables us to use a data template rather than a single field to build the document that the searchindex will index.

To create a data template, we need to create a new template inside the templates directory (../templates/user_text.txt) and place the following lines inside:

    {{ object.description }}
    {{ object.notes }}

description and notes are the fields that will be used as primary fields for searching in. The name and created_date fields specified in the search index can be used for filtering data while searching. The data can then be indexed using the ‘rebuild_index’ command. In the above example I have shown a simple and quick setup to get started. The search backend is highly customizable and can be modified for any use cases.

I mentioned above that the ElasticSearch backend settings file can be extended to use a custom one. That enables us to specify custom analyzers, tokenizers and filters for indexing or querying. In my next blog post I will talk more in detail about extending the backend to use custom settings.