Solr Post Search Overview

We added Solr Searching to NixMash Spring Posts, with both Quick and Full Search functions. With Quick Search all terms must appear in either Post Title or Body or in combination. Full Search supports all Lucene Syntax options. Quick Search is on the sidebar of all Post Stream pages, Full Search has its own page.

We blogged a LOT about Solr on NixMash, almost 40 posts! Here we’ll do a general overview of the components of Solr Post Searching on NixMash Spring.

Quick Search

The Quick Search form with its “search” <input /> field is present on the sidebar.

The <submit /> element is hidden with CSS, so the query is sent to /posts as a String on [Enter]. The PostsController method for /posts with the “search” parameter is shown next. It’s important to remember that all post streams, including search are generated by an Ajax call to PostsRestController. Both Quick and Full Search are designed similarly, where the query is saved as a Session Attribute in the PostsController then retrieved in PostsRestController to generate the search results. We’ll look at the REST result creation logic with Full Search.

Full Search

The design of Full Search is very similar to Quick Search. The main difference you’ll see is that we’re using a PostQueryDTO object for the form rather than a simple String.

Client Side REST Search Processing

Here’s the REST endpoint for creating the Full Search results. Notice we’re retrieving the PostQueryDTO Session Attribute and performing our search for Solr PostDoc objects. We’re returning an HTML Post Stream so if no posts are found we return a FreeMarker “No Results” HTML template message. (We’re being lazy and returning the same message for errors as well.) We retrieve a PostDoc Page Slice of the search results and convert those PostDocs into Posts for display as a Post Stream.

Creating an AND Criteria Search

This is interesting, creating an AND Criteria Search with Spring Solr JPA. As I mentioned, with Quick Search the search terms must be present in the post title or body. ALL TERMS must be present for more relevant results–as opposed to OR searching.

Building Solr Search Criteria can be tricky, but fun! Below is the Criteria created for the Quick Search “bootstrap carousel.” The thing to remember is that each criteria element is wrapped in its own set of parentheses. That’s why criteria = criteria.and is an important Criteria Construct.

Solr Schema

Here are the Post Document fields in the NixmashSpring Solr Collection’s schema.xml. Doctype is important to separate the object types in the collection (PRODUCT, BOOK, etc. listed in the opening comments.) Author and title are existing generic Solr fields. Body is our TEXT Post Content field used for searching. Posttype is LINK or POST, with source being the origin domain of Links, like “” Fields added to common searching (Solr CopyField-to-Text) and searched by default are title, body, author and tag. Notice the simple labeling of the fields, “post_title” instead of “title” for instance. “Title” works, and saves conversion coding for queries.

Populating the Solr Index with Posts

It dawned on me that we’ll need to add an Administrative function in the Web App to repopulate the Solr Index with Posts before pushing v0.4.3 to GitHub, but in the meantime we’re using the Solr Module to clear and populate the Index with Posts. This is primarily of interest to developers using NixMash Spring, but it’s also cool using Spring Boot and Gradle to whip up a JAR and run at the terminal in a bash script to perform Solr data processes.

Source Code Notes for this Post

All source code discussed in this post can be found in my NixMash Spring GitHub repo and viewed online here.