There are times when you want to optimize your Solr index. But what is optimize and why do I care? Optimize is similar to when you defragment your hard drive. Solr will create a new index removing any deleted documents. It is simply house keeping at its best. I usually do a commit from the Admin UI, going to the overview tab. However, sometimes we might want to do it programatically, a good example being when you have a spell checker configured to build the dictionary on optimize. The url to optimize is very simple, here is an example with my localhost, just replace with your Solr http://localhost:8983/solr/yourcore/update?stream.body=<optimize><query>*:*</query></optimize> Notice how the # is removed from all REST calls vs when the Admin UI loads. Happy optimizing!
Many times have I stopped and restarted Solr to reload a core, yes it is kind of a rookie way as you can always go to the Admin UI, Core Admin and reload Core. But what if you wanted to have a really fast way of reloading your core? Just do it via the admin handler! http://{SOLR IP}:{SOLR PORT}/solr/admin/cores?action=RELOAD&core={CORE NAME} You can even add it to your code and make a simple call or better yet use SolrNet via the admin functionality found below: https://github.com/mausch/SolrNet/blob/master/Documentation/Core-admin.md
There are a couple of ways to trigger a commit command in Solr. The easiest way is via a URL: http://localhost:8983/solr/collection1/update?commit=true (Replace localhost:8983 with your Solr url and ) But you can also commit using the Documents option from the Admin UI. Simply navigate to Documents, using this URL: http://localhost:8983/solr/collection1/documents And select Solr Command (raw XML orJSON), adding the command <commit> true </commit> Submit Document! It just works. And if you are using SolrCloud, the command goes to everyone.
I had an issue raised because of a mismatch between my document results and my facet counts. The issue is basically that there is a field that is not required and in most cases, the field is added with an empty string – which is ok as empty has a meaning. However in a few cases, the field is not added at all and this is not the expected scenario. So I needed to find out why did this happen, which means finding the document id so that it can be reviewed during indexing. Oh well..I was tired so I ran a *:* query and got all results… too much text. Query for all: q=*:* Added only the two fields that I needed in the fl field so that only those fields that I needed were shown and number of rows to see them all. This was kind of slow and inconvenient. Query for all with only required fields and all rows: q=*:*&fl=title myfacet&rows=1600 So now I remembered query for missing fields! Just use the – operator on a field name. Query for documents with missing fields: q=-myfacet:* Problem solved. Easy as pie!
I am preparing for a presentation this month on Solr and SolrNet for the Atlanta .NET User Group. Solr 5 is already out but I will be running my demos using Solr 4.10. Now that I am starting the preparation process, it really feels so good to know that starting a local Solr is SO EASY. Check out the steps which couldn’t be easier: – Assuming you already downloaded Solr (here if you haven’t: http://lucene.apache.org/solr/downloads.html) – Just extract into a folder. Mine is called AtlantaSolr – Make sure you have Java running. If unsure just type java -version – Now navigate to your Solr folder, in my case C:\Dropbox\Public Speaking\AtlantaSolrSolrNet – Type the magic words java -jar start.jar and let it load. – Voila! Navigate to localhost:8983/solr It couldn’t be easier!
I am working in a project that sounds like heaven to me. Big company, hundreds of developers, latest technology all around, totally agile and the search is done with Solr and a REST API in C# which of course uses SolrNet (who would think otherwise?) In any case, spellcheck was enabled and this wreaked havoc whenever servers were rebooted. It seems like SolrCloud has an issue with spellchecking . The problem is that setting spellcheck in /select request handler makes Solr spin its wheels for a long time while starting, and it has been tracked inhttps://issues.apache.org/jira/browse/SOLR-6679. The recommended workaround is to have spell check set up in a different request handler. But here is the problem. In SolrNet you can’t easily explicitly specify the request handler. It basically uses /select. The request handler is specified via the Handler property in ISolrQueryExecuter. You can see it in action here: https://github.com/mausch/SolrNet/blob/master/SolrNet/Impl/SolrQueryExecuter.cs I checked through many forums and threads to try to get to a solution and here are some of the threads I found: Changing Handler endpoint in SolrQueryExecuter? https://groups.google.com/forum/?fromgroups=#!searchin/solrnet/handler/solrnet/Kqxn68pU0uo/uG50WSxu_swJ How can I perform solrnet query in two different request handler? https://groups.google.com/forum/#!topic/solrnet/ZA-bv9dkh_0 Different request handler https://groups.google.com/forum/#!topic/solrnet/SP14XmifcrY Calling Custom Request Handler https://groups.google.com/forum/#!topic/solrnet/THX-ADS5CLQ http://stackoverflow.com/questions/13393700/how-we-changes-standard-query-handler […]
I was asked today if it makes sense to change the name of the default id field in Solr to something else? Let me explain. You download your Solr, you get it up and running and you start modifying fields in Schema.xml. Currently the uniquekey is called id and it is defined as uniquekey. No harm done in leaving as is. It looks something like what I have below. <field name=”id” type=”string” indexed=”true” stored=”true” required=”true” multiValued=”false” /> …. <uniqueKey>id</uniqueKey> At first it may seem like it doesn’t matter what it is actually called, however if you think about it a little bit more it may make sense to change it. Why? Simple. Because id, by being the default value may be used in other locations, even in sample code and it may have been used for specific purposes or in ways that you are not aware of. So by changing it, you are forcing yourself to be aware of where the id field is being used. It is not a huge difference, but the devil is in the details. Something as easy as changing it to look like this is more than enough. <field name=”itemid” type=”string” indexed=”true” stored=”true” required=”true” multiValued=”false” […]
