New Java API
------------
Key: SOLR-344
URL: https://issues.apache.org/jira/browse/SOLR-344
Project: Solr
Issue Type: Improvement
Components: clients - java, search, update
Affects Versions: 1.3
Reporter: Jonathan Woods
The core Solr codebase urgently needs to expose a new Java API designed for use
by Java running in Solr's JVM and ultimately by core Solr code itself. This
API must be (i) object-oriented ('typesafe'), (ii) self-documenting, (iii) at
the right level of granularity, (iv) designed specifically to expose the value
which Solr adds over and above Lucene.
This is an urgent issue for two reasons:
- Java-Solr integrations represent a use-case which is nearly as important as
the core Solr use-case in which non-Java clients interact with Solr over HTTP
- a significant proportion of questions on the mailing lists are clearly from
people who are attempting such integrations right now.
This point in Solr development - some way out from the 1.3 release - might be
the right time to do the development and refactoring necessary to produce this
API. We can do this without breaking any backward compatibility from the point
of view of XML/HTTP and JSON-like clients, and without altering the core Solr
algorithms which make it so efficient. If we do this work now, we can
significantly speed up the spread of Solr.
Eventually, this API should be part of core Solr code, not hived off into some
separate project nor in a non-first-class package space. It should be capable
of forming the foundation of any new Solr development which doesn't need to
delve into low level constructs like DocSet and so on - and any new development
which does need to do just that should be a candidate for incorporation into
the API at the some level. Whether or not it will ever be worth re-writing
existing code is a matter of opinion; but the Java API should be such that if
it had existed before core plug-ins were written, it would have been natural to
use it when writing them.
I've attached a PDF which makes the case for this API. Apologies for
delivering it as an attachment, but I wanted to embed pics and a bit of
formatting.
I'll update this issue in the next few days to give a prototype of this API to
suggest what it might look like at present. This will build on the work
already done in Solrj and SearchComponents
(https://issues.apache.org/jira/browse/SOLR-281), and will be a patch on an
up-to-date revision of Solr trunk.
[PS:
1. Having written most of this, I then properly looked at
SearchComponents/SOLR-281 and read
http://www.nabble.com/forum/ViewPost.jtp?post=11050274&framed=y, which says
much the same thing albeit more quickly! And weeks ago, too. But this
proposal is angled slightly differently:
- it focusses on the value of creating an API not only for internal Solr
consumption, but for local Java clients
- it focusses on designing a Java API without constantly being hobbled by
HTTP-Java
- it's suggesting that the SearchComponents work should result in a Java API
which can be used as much by third party Java as by ResponseBuilder.
2. I've made some attempt to address Hoss's point
(http://www.nabble.com/search-components-%28plugins%29-tf3898040.html#6551097579454875774)
- that an API like this would need to maintain enough state e.g. to allow an
initial search to later be faceted, highlighted etc without going back to the
start each time - but clearly the proof of the pudding will be in the prototype.
3. Again, I've just discovered SOLR-212 (DirectSolrConnection). I think all
my comments about Solrj apply to this, useful though it clearly is.]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
