I think there is a place for a client-side query hierarchy. It would be
nice if you could build a Lucene Query and the Solr client would
serialize it for you. If there were a general-purpose query
serialization library then you could support a similar programming model
for Lucene-only and with Solr. It would be useful for all kinds of
things, since you wouldn't be tied to the query parser zoo. The XML QP
is a possible starting place for a serialization format, but I think
ultimately to do this, Query would have to add support for some kind of
generic representation (eg a map of children which could be primitives
or queries).
-Mike
On 11/14/13 4:35 AM, Alexandre Rafalovitch wrote:
Hello,
I am trying to imagine what would a new, fresh, Solr client library look
like. There has been a number of features added to Solr recently, so some
of the older libraries do not necessarily support them as well (e.g.
multi-collections, soft commits, multiple handler end-points, schema
auto-discovery, etc).
If one were to write a new client, what would a useful version 1 would
look like for modern Solr? At the moment, I am not talking of a specific
implementation language. Stil, if you have any thoughts on that, they are
welcome too.
My own thought center around two directions that a library would need to
support:
1) Indexing on the backend
2) Middle-layers between the website and Solr doing some sort of query
security, enhancement, normalization, etc
Any thoughts?
Regards,
Alex.
Personal website: http://www.outerthoughts.com/
LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch
- Time is the quality of nature that keeps events from happening all at
once. Lately, it doesn't seem to be working. (Anonymous - via GTD book)