date:20121219

[jira] [Updated] (SOLR-4143) setRequestHandler - option to not set qt parameter

2012-12-19 Thread Shawn Heisey (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn Heisey updated SOLR-4143:
---

Attachment: SOLR-4143-alternate.patch

Deleted the most recent trunk and 4x alternate patches.  Adding a new alternate 
patch, updated to latest trunk and including an incomplete addition to 
CHANGES.txt that will need final tweaking before commit.

> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex - 
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143-alternate.patch, SOLR-4143-alternate.patch, 
> SOLR-4143-alternate-testsfailing.patch, SOLR-4143.patch, SOLR-4143.patch, 
> SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the 
> URL path from /select to the String argument.  It is however doing something 
> that I did not expect, which is setting the qt parameter on the query as 
> well.  Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0 
> servers.  I am not including the whole exception, because this issue is for 
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the 
> PingRequestHandler recursively
> at 
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method 
> that includes a boolean option deciding whether or not to also set the qt 
> parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4143) setRequestHandler - option to not set qt parameter

2012-12-19 Thread Shawn Heisey (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn Heisey updated SOLR-4143:
---

Attachment: (was: SOLR-4143-alternate-trunk.patch)

> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex - 
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143-alternate.patch, 
> SOLR-4143-alternate-testsfailing.patch, SOLR-4143.patch, SOLR-4143.patch, 
> SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the 
> URL path from /select to the String argument.  It is however doing something 
> that I did not expect, which is setting the qt parameter on the query as 
> well.  Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0 
> servers.  I am not including the whole exception, because this issue is for 
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the 
> PingRequestHandler recursively
> at 
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method 
> that includes a boolean option deciding whether or not to also set the qt 
> parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Updated] (SOLR-4143) setRequestHandler - option to not set qt parameter

2012-12-19 Thread Shawn Heisey (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-4143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Shawn Heisey updated SOLR-4143:
---

Attachment: (was: SOLR-4143-alternate-4x.patch)

> setRequestHandler - option to not set qt parameter
> --
>
> Key: SOLR-4143
> URL: https://issues.apache.org/jira/browse/SOLR-4143
> Project: Solr
>  Issue Type: Improvement
>  Components: clients - java
>Affects Versions: 4.0
> Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex - 
> 2012-12-03 12:54:38
>Reporter: Shawn Heisey
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4143-alternate.patch, 
> SOLR-4143-alternate-testsfailing.patch, SOLR-4143.patch, SOLR-4143.patch, 
> SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch
>
>
> The setRequestHandler method does what I expect in one way - it changes the 
> URL path from /select to the String argument.  It is however doing something 
> that I did not expect, which is setting the qt parameter on the query as 
> well.  Here is the code:
> private static final String PING_HANDLER = "/admin/ping";
> query.setRequestHandler(PING_HANDLER);
> This is resulting in the following exception being logged in my Solr 3.5.0 
> servers.  I am not including the whole exception, because this issue is for 
> SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
> {code}
> Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
> SEVERE: org.apache.solr.common.SolrException: Cannot execute the 
> PingRequestHandler recursively
> at 
> org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
> at 
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
> {code}
> I believe it would be useful to include an alternate setRequestHandler method 
> that includes a boolean option deciding whether or not to also set the qt 
> parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-1337) Spans and Payloads Query Support

2012-12-19 Thread Dmitry Kan (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536838#comment-13536838
 ] 

Dmitry Kan commented on SOLR-1337:
--

[Jan Høydahl] at Lucene query parser level. New token FUZZY_SLOP_SHARP (name 
isn't probably the best sound, but can be changed) has been introduced in the 
QueryParser.jj and supportive code implemented. The syntax is same as that of ~ 
operator, i.e. "term1 term2 ... termn" #slope.

> Spans and Payloads Query Support
> 
>
> Key: SOLR-1337
> URL: https://issues.apache.org/jira/browse/SOLR-1337
> Project: Solr
>  Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
> Fix For: 4.1
>
>
> It would be really nice to have query side support for: Spans and Payloads.  
> The main ingredient missing at this point is QueryParser support and a output 
> format for the spans and the payload spans.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Override fq via local params?

2012-12-19 Thread Dawid Weiss

Attention Solr developers :) Is this something that should be possible
(and doesn't work) or is there a misconception somewhere? Thanks for
your help in advance; quoting:

I have tested on a range of SOLR releases from 1.6.0 to 3.6.0 and all
exhibit the same behavior, which is:

If I add a default filter query to the search hander, in this case
Section_Title:description


   
 
   explicit
   10
   DRECONTENT
   Section_Title:description
 

 Then I am not able to override this default with LocalParams, for
example the request to filter query on a different field is ignored

{!fq=Section_Title:summary}space

However, the same filer query does work if I put it in the URL

http://localhost:8983/solr/select/?q={!fq%3DSection_Title%3Asummary}space&version=2.2&start=0&rows=10&indent=on&fq=Section_Title:summary

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

[jira] [Commented] (LUCENE-4639) Improving _TestUtil.getTempDir

2012-12-19 Thread Shai Erera (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13536829#comment-13536829
 ] 

Shai Erera commented on LUCENE-4639:


Here's a test which reproduces the Access is denied exception on Windows, if 
run with the same seed (pick any seed, I used: )

{code}
  @Test
  public void testAccessDenied() throws Exception {
_TestUtil.getTempDir("testAccessDenied");
fail("msg");
  }
{code}

I cannot actually commit that test, but if you run it twice on Windows (w/ the 
same seed), you will hit the Access is denied.
However it passes with the changes to getTempDir (calling mkdir()). I will 
verify that no test breaks b/c getTempDir now creates the directory.

> Improving _TestUtil.getTempDir
> --
>
> Key: LUCENE-4639
> URL: https://issues.apache.org/jira/browse/LUCENE-4639
> Project: Lucene - Core
>  Issue Type: Bug
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
>
> Spinoff from here: 
> http://lucene.472066.n3.nabble.com/TestUtil-getTempFile-may-fail-on-quot-Access-Denied-quot-td4028048.html.
> _TestUtil.getTempDir uses createTempFile and then deletes the file. While 
> this usually works, if someone runs tests by multiple JVMs and does not 
> ensure each JVM gets an isolated temp.dir to work in, that my result in two 
> JVMs sharing the same directory.
> Also, on Windows, if you call getTempDir on an existing directory, you get an 
> "Access is denied" exception.
> Dawid proposed a simple solution to just call mkdirs() continuously until 
> success. I'd like to try that.
> Also, I think that genTempFile could use some house cleaning, e.g.:
> * tempFileLocker can be just an Object instance? Why do we need a class?
> * If we initialize counter and counterBase in a static clause, we can avoid 
> checking if counter==0 as well as passing Random to genTempFile (that will 
> remove any suspicion that it does anything randomly)
> ** Also, instead of synchronizing on tempFileLocker, can we just use 
> AtomicInteger for the counter?
> I'll modify getTempDir first. It documents "does not create the directory", I 
> want to make sure no test fails due that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Created] (LUCENE-4639) Improving _TestUtil.getTempDir

2012-12-19 Thread Shai Erera (JIRA)

Shai Erera created LUCENE-4639:
--

Summary: Improving _TestUtil.getTempDir
Key: LUCENE-4639
URL: https://issues.apache.org/jira/browse/LUCENE-4639
Project: Lucene - Core
Issue Type: Bug
Reporter: Shai Erera
Assignee: Shai Erera
Priority: Minor

Spinoff from here:
http://lucene.472066.n3.nabble.com/TestUtil-getTempFile-may-fail-on-quot-Access-Denied-quot-td4028048.html.

_TestUtil.getTempDir uses createTempFile and then deletes the file. While this
usually works, if someone runs tests by multiple JVMs and does not ensure each
JVM gets an isolated temp.dir to work in, that my result in two JVMs sharing
the same directory.

Also, on Windows, if you call getTempDir on an existing directory, you get an
"Access is denied" exception.

Dawid proposed a simple solution to just call mkdirs() continuously until
success. I'd like to try that.

Also, I think that genTempFile could use some house cleaning, e.g.:
* tempFileLocker can be just an Object instance? Why do we need a class?
* If we initialize counter and counterBase in a static clause, we can avoid
checking if counter==0 as well as passing Random to genTempFile (that will
remove any suspicion that it does anything randomly)
** Also, instead of synchronizing on tempFileLocker, can we just use
AtomicInteger for the counter?

I'll modify getTempDir first. It documents "does not create the directory", I
want to make sure no test fails due that.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

1 2 >

1 - 100 of 132 matches

Mail list logo