In the process of prototyping a Solr-based application I found myself needing a quick-and-dirty database.  Rather than introduce another technology into the prototype, I tried to take advantage of the fact that Solr is effectively a fast key-value data store.  In my application, I’m writing the middleware in Python  using the Solrpy module, but behind the scenes all it’s doing is assembling the URL and handling the plumbing of sending the request and parsing the response.

Assume I’ve added fields called “username” and “admin_datatype” to schema.xml and my collection is called “admin”.

import solr
import uuid
import urllib

class UserManager:
    def __init__(self):
        self.data_collection = "admin"
        self.base_url = "http://localhost:8983/solr/" + self.data_collection

    def GetUserID(self, user_name):
        s = solr.SolrConnection(self.base_url)
        filter_query_username = "username:" + user_name
        filter_query_datatype = "admin_datatype:User"

        response = s.query('*:*', fq=[filter_query_username, filter_query_datatype])
        intCount = len(response.results)
        user_id = ""
        for hit in response.results:
            user_id = hit['id']
            
        return user_id

    def AddUser(self, user_name):

        s = solr.SolrConnection(self.base_url)
        s.add(id=uuid.uuid4(), username=user_name, admin_datatype="User")
        s.commit()

I use the “admin_datatype” field to simulate tables, so we are tagging each row of data with a value that we later filter on.  Solr can facet the data by the unique values in this field which makes the queries even faster.  More complex data usually just means more fields in the add and select queries, and in the case of the code above more parameters passed to the methods.  In application development it’s generally useful to have each object/row of data have a unique identifier, and solr requires this anyway, so you could easily use solr to simulate the basic functionality of a document database like Mongo or even relational tables.

In general, this technique will keep you moving when doing R&D for search-based applications.  I’m not sure I’d want to build the whole app around it.