I assume that we already have an instance of our arts core running. You can use the instance defined in Chapter 7, Working with Multiple Entities, Multicores, and Distributed Search, or you can start from the basic schema in /SolrStarterBook/solr-app/appendixes/arts and run it in the usual way.
- But say we don't want to use an external Solr application, and simply want to put the core Solr functionality inside an existing Java application. In this case, we will use an embedded Solr, which means we are actually using the Solr API directly as a framework, without passing through its services. It will be up to us to start a core with the correct configuration, post or query data, optimize the core, or release it when the application shuts down. As you can imagine, this is a very particular use case, and I expect you to not do this in most of the cases, but only in some very specific scenarios (for example, if we need to create a single web application, or a desktop one, including Solr capabilities as well).
- A really basic example can be similar to the following one:
System.setProperty("solr.solr.home", "solr-home"); CoreContainer container = new CoreContainer(); container.load(); EmbeddedSolrServer server = new EmbeddedSolrServer(container, "arts"); // delete all documents server.deleteByQuery("*:*"); Artist doc = new Artist("http://TEST/Leonardo_da_Vinci","Leonardo Da Vinci", "Vinci", "Florence"); server.addBean(doc); server.commit(); QueryResponse response = server.query(new SolrQuery("leonardo"), METHOD.GET); for (SolrDocument d : response.getResults()) { for (String field : d.getFieldNames()) { System.out.printf("%s = %s ", field, d.getFieldValue(field)); } } server.shutdown(); - Here, we start a server with a specific configuration and then index a specific custom data type. As we are writing code in Java, we can also use one of the most adopted Java conventions for describing our data and creating a Java bean, which represents an instance on our domain (in this case, only few fields are used for readability, just to give an idea).
public class Artist { @Field final URI uri; @Field final String artist; @Field("city") final String[] cities; public Artist(final String uri, final String artist, final String... cities) { this.uri = URI.create(uri); this.artist = artist; this.cities = cities; } }
Note that the Solr API provides us with some Java annotations to be used on beans that simplify both the process of indexing data and returning it from a query. Obviously, the example is designed only to give you a skeleton for starting your own experimentation. If you study the API, you'll find several other useful methods that you can use for your convenience.
The base for interacting with Solr from the Java code is obtaining a valid server instance. In this first case, we are using an EmbeddedSolrServer instance, so we also need to load the configuration and start the server if not already started. Our server instance, in particular, can be seen as a wrapper for core functionalities. We have to expect it to expose methods for indexing, searching, and removing SolrDocuments.
The first step will be instantiating a CoreContainer instance. This will be the object that will actually load and parse our configuration from the filesystem. In this case, we have adopted as little code as possible, so we have defined a default solr.solr.home location by overwriting a system property. This helps us to avoid passing too many parameters and focus on more interesting steps. The load() method here is used not only to load the configurations in memory, but also to actually start a multicore server instance on our configurations.
The second step will be the instantiation of the server instance by itself. This is created, starting from the container (imagine it handling our solr.xml file) and providing the name of the specific core configuration we want to access.
If we are able to use JavaBeans for transporting data inside our application, for example, by assembling data from a query on a database, we can index them using the server.addBean() method that will internally look for annotations, parsing the field with an appropriate type if possible.
The server instance also exposes methods to delete documents (we use it to clear the current index for repeating our tests), trigger a commit when needed, and shut down the Solr instance when the application ends.
Constructing a basic query is simple, and we can easily obtain a collection of results using the getResults() method of a QueryResponse object. Note that this object is the same one that was seen before when we briefly inspected the VelocityResponseWriter code, and the method used to inspect looks similar to the one we used from JavaScript in the update chain. You won't miss the METHOD.GET value passed to the QueryResponse object, suggesting that queries are treated the same way by an embedded or by an external server instance.