Looking at SOLR-2724 and SOLR-3161

[Shawn Heisey <so...@elyograg.org>]

I notice that SOLR-2724 and SOLR-3161 are in the CHANGES.txt for 3.6.0, 
but that they both got reverted on trunk.  Are there plans to put them 
back in trunk in a possibly altered form?  I like the general direction 
that David Smiley is going, as long as the client API keeps up.

If I follow all the recommendations I've seen in relation to these 
issues, I will only have request handlers that start with / and I won't 
be using the qt parameter.  This is fine, except that the only way I've 
found in SolrJ to specify another handler (such as /edgruberman) is by 
using CommonParams.QT ... does this alter the URL path, or just insert a 
qt= parameter?  I suspect that it's the latter, which means that there 
is a possibility that the request could fail with a potentially 
confusing error message, given the requirements in SOLR-3161.

Is there another SolrJ API for specifying a request handler that somehow 
has escaped my attention?

Thanks,
Shawn


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Looking at SOLR-2724 and SOLR-3161

[Shawn Heisey <so...@elyograg.org>]

On 4/19/2012 2:12 PM, Shawn Heisey wrote:
> I notice that SOLR-2724 and SOLR-3161 are in the CHANGES.txt for 
> 3.6.0, but that they both got reverted on trunk.  Are there plans to 
> put them back in trunk in a possibly altered form?  I like the general 
> direction that David Smiley is going, as long as the client API keeps up.

I thought of another potential problem, something that was at least 
touched in the issue comments - distributed search.  The shards.qt 
parameter was discussed.  Since the shards parameter doesn't include the 
request handler URL path, is shards.qt the only way to specify that?  
One comment suggested that with shards.qt=/something, the shard requests 
will change to /something and will not see a qt parameter.  Is that 
actually the case in 3.6 or 4.0?

I think that SolrJ (in trunk at least) needs a new set method 
(constructor?) to change the URL path, and distributed search needs a 
new parameter to replace a deprecated/removed shards.qt.  It might also 
need to default to inheriting the request handler path used on the 
initial request, assuming that wouldn't cause horrible breakage somewhere.

For me personally, I hope to change my configuration to be as compatible 
with 4.0 as possible when I go to 3.6.x, currently on 3.5.0.  It would 
be best if we don't have to make any immediate application changes.  If 
I absolutely have to use something that's deprecated, I will ... but I'd 
rather not.

Thanks,
Shawn


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org