Apache Lucene and Solr 4.6.0 are out!
From the announcement:
Lucene can be downloaded from http://lucene.apache.org/core/mirrors-core-latest-redir.html and Solr can be downloaded from http://lucene.apache.org/solr/mirrors-solr-latest-redir.html.
Both releases contain a number of bug fixes.
See the Lucene CHANGES.txt and Solr CHANGES.txt files included with the release for a full list of details.
While it is fair to say that “Both releases contain a number of bug fixes.” I think that gives the wrong impression.
The Lucene 4.6.0 release has 23 new features versus 5 bugs and Solr 4.6.0 has 17 new features versus 14 bug fixes. Closer but 40 new features total versus 22 bug fixes sounds good to me! 😉
Just to whet your appetite for looking at the detailed change lists:
LUCENE-5294 Suggester Dictionary implementation that takes expressions as term weights
From the description:
It could be an extension of the existing DocumentDictionary (which takes terms, weights and (optionally) payloads from the stored documents in the index). The only exception being that instead of taking the weights for the terms from the specified weight fields, it could compute the weights using an user-defn expression, that uses one or more NumicDocValuesField from the document.
Example:
let the document have
- product_id
- product_name
- product_popularity
- product_profit
Then this implementation could be used with an expression of “0.2*product_popularity + 0.8*product_profit” to determine the weights of the terms for the corresponding documents (optionally along with a payload (product_id))
You may remember I pointed out Mike McCandless’ blog post on this issue.
SOLR-5374 Support user configured doc-centric versioning rules
From the description:
The existing optimistic concurrency features of Solr can be very handy for ensuring that you are only updating/replacing the version of the doc you think you are updating/replacing, w/o the risk of someone else adding/removing the doc in the mean time – but I’ve recently encountered some situations where I really wanted to be able to let the client specify an arbitrary version, on a per document basis, (ie: generated by an external system, or perhaps a timestamp of when a file was last modified) and ensure that the corresponding document update was processed only if the “new” version is greater then the “old” version – w/o needing to check exactly which version is currently in Solr. (ie: If a client wants to index version 101 of a doc, that update should fail if version 102 is already in the index, but succeed if the currently indexed version is 99 – w/o the client needing to ask Solr what the current version)