if your index is read-only in production, can you add mapping
unique_id-Lucene docId in your kv store and and build filters externally?
That would make unique Key obsolete in your production index, as you would
work at lucene doc id level.
That way, you offline the problem to update/optimize phase
> I was actually thinking of some kind of custom Lucene/Solr component that
> would for example take a query parameter such as &lookitUp=123 and the
> component might do a JDBC query against a database or kv store and return
> results in some form that would be efficient for Solr/Lucene to process.
> You could even
>generalize the hell out of it so the SQL itself could be specified at
>request time...
> q=solr&fq={!sql}SELECT ID FROM USER_MAP WHERE USER=1234 ORDER BY ID ASC
I think that's missing the need for an argument for what field in the solr
index to require to be within the values
Or an alternate simpler solution requiring the client to do more work, but
getting around the inefficienty and limit on clauses of a whole lot of OR
clauses: provide a qparser that accepts an "in" query.
&fq={!in field=id}100,150,201,304,etc.
Could, it seems from Hoss et al's suggestions, be p
The CHANGES.txt file in branch_3x says that the javabin format has
changed in Solr 3.1, so you need to update SolrJ as well as Solr. Is
the SolrJ included in 3.1 compatible with both 3.1 and 1.4.1? If not,
that's going to make a graceful upgrade of my replicated distributed
installation a li
Please add a JIRA requesting support for both formats from SolrJ.
On Sat, Oct 16, 2010 at 12:02 PM, Shawn Heisey wrote:
> The CHANGES.txt file in branch_3x says that the javabin format has changed
> in Solr 3.1, so you need to update SolrJ as well as Solr. Is the SolrJ
> included in 3.1 compati
