lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Woods (JIRA)" <>
Subject [jira] Updated: (SOLR-344) New Java API
Date Tue, 28 Aug 2007 09:19:30 GMT


Jonathan Woods updated SOLR-344:

    Attachment: New Java API for Solr.pdf

> New Java API
> ------------
>                 Key: SOLR-344
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java, search, update
>    Affects Versions: 1.3
>            Reporter: Jonathan Woods
>         Attachments: New Java API for Solr.pdf
> 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 (, 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, which says much
the same thing albeit more quickly!  And weeks ago, too.  But this proposal is angled slightly
> - 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 (
- 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.

View raw message