from:"Ryan McKinley"


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

Ryan McKinley resolved SOLR-871.


Resolution: Fixed
  Assignee: Ryan McKinley

 remove dependency on stax-utils.jar 
 

 Key: SOLR-871
 URL: https://issues.apache.org/jira/browse/SOLR-871
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan McKinley
Assignee: Ryan McKinley
 Fix For: 1.4


 Currently we we use a custom library to make a XMLInputFactory -- we can use 
 the standard one.
 {code}
 -inputFactory = BaseXMLInputFactory.newInstance();
 +inputFactory = XMLInputFactory.newInstance();
 {code}
 This will remove a dependency on stax-util.jar and let people running java6 
 package solr without any stax libraries.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-84) Logo Contests


[ 
https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649175#action_12649175
 ] 

Ryan McKinley commented on SOLR-84:
---

Its nice to see a lot of good options coming in.  I like it! thanks everyone!

Danny, any chance we could see:
!https://issues.apache.org/jira/secure/attachment/12394218/solr-solid.png!
with an upper case 'R'?

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_a_blue.jpg, 
 apache_solr_a_red.jpg, apache_solr_b_blue.jpg, apache_solr_b_red.jpg, 
 apache_solr_burning.png, apache_solr_c_blue.jpg, apache_solr_c_red.jpg, 
 apache_solr_contour.png, apache_solr_d_blue.jpg, apache_solr_d_red.jpg, 
 apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, 
 logo-solr-source-files-take2.zip, logo_remake.jpg, logo_remake.svg, 
 solr-84-source-files.zip, solr-circle-grad.png, solr-f.jpg, 
 solr-greyscale.png, solr-logo-20061214.jpg, solr-logo-20061218.JPG, 
 solr-logo-20070124.JPG, solr-logo.jpg, solr-logo.png, solr-nick.gif, 
 solr-solid.png, solr.jpg, solr.png, solr.s1.jpg, solr.s2.jpg, solr.s3.jpg, 
 solr.svg, solr2_maho.png, solr2_maho_impression.png, solr_attempt.jpg, 
 solr_attempt2.jpg, solrlogo.jpg, solrlogo2.jpg, sslogo-solr-70s.png, 
 sslogo-solr-classic.png, sslogo-solr-dance.png, sslogo-solr-fiesta.png, 
 sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-84) Logo Contests


[ 
https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649201#action_12649201
 ] 

Ryan McKinley commented on SOLR-84:
---

So you can see the images next to each other:

!https://issues.apache.org/jira/secure/attachment/12394281/solr2_maho.png!
!http://toastytech.com/guis/sol10logo.png!

not sure

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_a_blue.jpg, 
 apache_solr_a_red.jpg, apache_solr_b_blue.jpg, apache_solr_b_red.jpg, 
 apache_solr_burning.png, apache_solr_c_blue.jpg, apache_solr_c_red.jpg, 
 apache_solr_contour.png, apache_solr_d_blue.jpg, apache_solr_d_red.jpg, 
 apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, 
 logo-solr-source-files-take2.zip, logo_remake.jpg, logo_remake.svg, 
 solr-84-source-files.zip, solr-circle-grad.png, solr-f.jpg, 
 solr-greyscale.png, solr-logo-20061214.jpg, solr-logo-20061218.JPG, 
 solr-logo-20070124.JPG, solr-logo.jpg, solr-logo.png, solr-nick.gif, 
 solr-solid.png, solr.jpg, solr.png, solr.s1.jpg, solr.s2.jpg, solr.s3.jpg, 
 solr.svg, solr2_maho.png, solr2_maho_impression.png, solr3_maho.png, 
 solr_attempt.jpg, solr_attempt2.jpg, solrlogo.jpg, solrlogo2.jpg, 
 sslogo-solr-70s.png, sslogo-solr-classic.png, sslogo-solr-dance.png, 
 sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-84) Logo Contests


[ 
https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649202#action_12649202
 ] 

Ryan McKinley commented on SOLR-84:
---

{quote}
watch splitting the vote with all of those variations. ... Too bad we can't 
vote on families and then the winner from that family...
{quote}

Dooh -- I know we should have discussed this more when setting the rules.  

I think more variations are good -- I think selecting a family, then refining 
that is a good option.  On: http://wiki.apache.org/solr/LogoContest, I grouped 
things into the 'families' that I think should count as the same 'vote'

The one hitch would be that if someone votes for multiple items in the same 
'family' it could skew the stats -- in that case, I suggest we ask the person 
to recast their 'vote' (it is a public ballot after all)

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_a_blue.jpg, 
 apache_solr_a_red.jpg, apache_solr_b_blue.jpg, apache_solr_b_red.jpg, 
 apache_solr_burning.png, apache_solr_c_blue.jpg, apache_solr_c_red.jpg, 
 apache_solr_contour.png, apache_solr_d_blue.jpg, apache_solr_d_red.jpg, 
 apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, 
 logo-solr-source-files-take2.zip, logo_remake.jpg, logo_remake.svg, 
 solr-84-source-files.zip, solr-circle-grad.png, solr-f.jpg, 
 solr-greyscale.png, solr-logo-20061214.jpg, solr-logo-20061218.JPG, 
 solr-logo-20070124.JPG, solr-logo.jpg, solr-logo.png, solr-nick.gif, 
 solr-solid.png, solr.jpg, solr.png, solr.s1.jpg, solr.s2.jpg, solr.s3.jpg, 
 solr.svg, solr2_maho.png, solr2_maho_impression.png, solr3_maho.png, 
 solr_attempt.jpg, solr_attempt2.jpg, solrlogo.jpg, solrlogo2.jpg, 
 sslogo-solr-70s.png, sslogo-solr-classic.png, sslogo-solr-dance.png, 
 sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (SOLR-84) Logo Contests

[
https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12649202#action_12649202
]

ryantxu edited comment on SOLR-84 at 11/19/08 3:11 PM:
-

{quote}
watch splitting the vote with all of those variations. ... Too bad we can't
vote on families and then the winner from that family...
{quote}

Dooh -- I know we should have discussed this more when setting the rules.

I think more variations are good -- I think selecting a family, then refining
that is a good option. On: http://wiki.apache.org/solr/LogoContest, I grouped
things into the 'families' that I think should count as the same 'vote'

The one hitch would be that if someone votes for multiple items in the same
'family' it could skew the stats -- in that case, I suggest we ask the person
to recast their 'vote' (it is a public ballot after all)

In particular, I like the logo:
!https://issues.apache.org/jira/secure/attachment/12391946/apache_solr_burning.png!

but would love to see a different font, with perhaps a different treatment of
apache. Maybe the flame on the R. It would be a shame to discourage that.

was (Author: ryantxu):
{quote}
watch splitting the vote with all of those variations. ... Too bad we can't
vote on families and then the winner from that family...
{quote}

Dooh -- I know we should have discussed this more when setting the rules.

Logo Contests
-

Key: SOLR-84
URL: https://issues.apache.org/jira/browse/SOLR-84
Project: Solr
Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
Attachments: apache-solr-004.png, apache_solr_a_blue.jpg,
apache_solr_a_red.jpg, apache_solr_b_blue.jpg, apache_solr_b_red.jpg,
apache_solr_burning.png, apache_solr_c_blue.jpg, apache_solr_c_red.jpg,
apache_solr_contour.png, apache_solr_d_blue.jpg, apache_solr_d_red.jpg,
apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg,
logo-solr-source-files-take2.zip, logo_remake.jpg, logo_remake.svg,
solr-84-source-files.zip, solr-circle-grad.png, solr-f.jpg,
solr-greyscale.png, solr-logo-20061214.jpg, solr-logo-20061218.JPG,
solr-logo-20070124.JPG, solr-logo.jpg, solr-logo.png, solr-nick.gif,
solr-solid.png, solr.jpg, solr.png, solr.s1.jpg, solr.s2.jpg, solr.s3.jpg,
solr.svg, solr2_maho.png, solr2_maho_impression.png, solr3_maho.png,
solr_attempt.jpg, solr_attempt2.jpg, solrlogo.jpg, solrlogo2.jpg,
sslogo-solr-70s.png, sslogo-solr-classic.png, sslogo-solr-dance.png,
sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png

This issue was original a scratch pad for various ideas for new Logos. It is
now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
Note that many of the images currently attached are not eligible for the
contest since they do not meet the official guidelines for new Apache project
logos (in particular that the full project name Apache Solr must be
included in the Logo). Only eligible attachments will be included in the
official voting.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-871) remove dependency on stax-utils.jar

2008-11-18 Thread Ryan McKinley (JIRA)

remove dependency on stax-utils.jar 


 Key: SOLR-871
 URL: https://issues.apache.org/jira/browse/SOLR-871
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan McKinley
 Fix For: 1.4


Currently we we use a custom library to make a XMLInputFactory -- we can use 
the standard one.
{code}
-inputFactory = BaseXMLInputFactory.newInstance();
+inputFactory = XMLInputFactory.newInstance();
{code}

This will remove a dependency on stax-util.jar and let people running java6 
package solr without any stax libraries.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-867) move EmbeddedSolrServer#getParsedResponse to utility class


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

Ryan McKinley updated SOLR-867:
---

Attachment: SOLR-867-move-getParsedResponse.patch

 move EmbeddedSolrServer#getParsedResponse to utility class
 --

 Key: SOLR-867
 URL: https://issues.apache.org/jira/browse/SOLR-867
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Attachments: SOLR-867-move-getParsedResponse.patch


 The utility function: EmbeddedSolrServer#getParsedResponse should be moved to 
 a utiltiy class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-867) move EmbeddedSolrServer#getParsedResponse to utility class


[ 
https://issues.apache.org/jira/browse/SOLR-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648252#action_12648252
 ] 

Ryan McKinley commented on SOLR-867:


This will let us replace:
{code:java}
 solrResponse.setResponse(new 
EmbeddedSolrServer(request.getCore()).getParsedResponse(request, response));
{code}

with:
{code:java}
 solrResponse.setResponse(ClientUtils.getParsedResponse(request, response));
{code}

 move EmbeddedSolrServer#getParsedResponse to utility class
 --

 Key: SOLR-867
 URL: https://issues.apache.org/jira/browse/SOLR-867
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Attachments: SOLR-867-move-getParsedResponse.patch


 The utility function: EmbeddedSolrServer#getParsedResponse should be moved to 
 a utiltiy class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-867) move EmbeddedSolrServer#getParsedResponse to utility class

move EmbeddedSolrServer#getParsedResponse to utility class
--

 Key: SOLR-867
 URL: https://issues.apache.org/jira/browse/SOLR-867
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor


The utility function: EmbeddedSolrServer#getParsedResponse should be moved to a 
utiltiy class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-868) Prepare solrjs trunk to be integrated into contrib


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

Ryan McKinley reassigned SOLR-868:
--

Assignee: Ryan McKinley

 Prepare solrjs trunk to be integrated into contrib
 --

 Key: SOLR-868
 URL: https://issues.apache.org/jira/browse/SOLR-868
 Project: Solr
  Issue Type: Task
Affects Versions: 1.3.1
Reporter: Matthias Epheser
Assignee: Ryan McKinley
 Fix For: 1.3.1

 Attachments: solrjs.zip


 This patch includes a zipfile snapshot of current solrjs trunk. The folder 
 structure is applied to standard solr layout.  It can be extracted to 
 contrib/javascript.
 it includes a build.xml:
 * ant dist - creates a single js file and a jar that holds velocity 
 templates.
 * ant docs - creates js docs. test in browser: doc/index.html
 * ant example-init - (depends ant dist on solr root) copies the current 
 built of solr.war and solr-velocity.jar to example/testsolr/..
 * ant example-start - starts the testsolr server on port 8983
 * ant example-import - imports 3000 test data rows (requires a started 
 testserver)
 Point your browser to example/testClientside.html 
 ,example/testServerSide.html or test/reuters/index.html to see it working.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-867) move EmbeddedSolrServer#getParsedResponse to utility class


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

Ryan McKinley updated SOLR-867:
---

Attachment: SOLR-867-move-getParsedResponse.patch

my mistake -- this can not go in ClientUtils because it requires SolrCore 
libraries (our package structure is wacked)

this patch moves the utility function to:
BinaryResponseWriter.getParsedResponse(req, rsp);

 move EmbeddedSolrServer#getParsedResponse to utility class
 --

 Key: SOLR-867
 URL: https://issues.apache.org/jira/browse/SOLR-867
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Attachments: SOLR-867-move-getParsedResponse.patch, 
 SOLR-867-move-getParsedResponse.patch


 The utility function: EmbeddedSolrServer#getParsedResponse should be moved to 
 a utiltiy class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-867) move EmbeddedSolrServer#getParsedResponse to utility class


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

Ryan McKinley resolved SOLR-867.


   Resolution: Fixed
Fix Version/s: 1.4

 move EmbeddedSolrServer#getParsedResponse to utility class
 --

 Key: SOLR-867
 URL: https://issues.apache.org/jira/browse/SOLR-867
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-867-move-getParsedResponse.patch, 
 SOLR-867-move-getParsedResponse.patch


 The utility function: EmbeddedSolrServer#getParsedResponse should be moved to 
 a utiltiy class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-868) Prepare solrjs trunk to be integrated into contrib

[
https://issues.apache.org/jira/browse/SOLR-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648388#action_12648388
]

Ryan McKinley commented on SOLR-868:

just noticed that the calendar widget is GPL
http://www.dynarch.com/projects/calendar/

we can't include GPL code in apache

I'm working on the NOTICE.txt now...

Prepare solrjs trunk to be integrated into contrib
--

Key: SOLR-868
URL: https://issues.apache.org/jira/browse/SOLR-868
Project: Solr
Issue Type: Task
Affects Versions: 1.3.1
Reporter: Matthias Epheser
Assignee: Ryan McKinley
Fix For: 1.3.1

Attachments: solrjs.zip

This patch includes a zipfile snapshot of current solrjs trunk. The folder
structure is applied to standard solr layout. It can be extracted to
contrib/javascript.
it includes a build.xml:
* ant dist - creates a single js file and a jar that holds velocity
templates.
* ant docs - creates js docs. test in browser: doc/index.html
* ant example-init - (depends ant dist on solr root) copies the current
built of solr.war and solr-velocity.jar to example/testsolr/..
* ant example-start - starts the testsolr server on port 8983
* ant example-import - imports 3000 test data rows (requires a started
testserver)
Point your browser to example/testClientside.html
,example/testServerSide.html or test/reuters/index.html to see it working.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-868) Prepare solrjs trunk to be integrated into contrib


[ 
https://issues.apache.org/jira/browse/SOLR-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648396#action_12648396
 ] 

Ryan McKinley commented on SOLR-868:


I just commited the majority of this patch.  However I did not commit:
 * the test reuters data
 * the jscalender

Rather then include the large example data in the distribution, we should add a 
script that will download and import it for people who really want to.  If 
there is not a public location for the sample data, we can find a permanent 
location for it on solrstuff.org

 Prepare solrjs trunk to be integrated into contrib
 --

 Key: SOLR-868
 URL: https://issues.apache.org/jira/browse/SOLR-868
 Project: Solr
  Issue Type: Task
Affects Versions: 1.3.1
Reporter: Matthias Epheser
Assignee: Ryan McKinley
 Fix For: 1.3.1

 Attachments: solrjs.zip


 This patch includes a zipfile snapshot of current solrjs trunk. The folder 
 structure is applied to standard solr layout.  It can be extracted to 
 contrib/javascript.
 it includes a build.xml:
 * ant dist - creates a single js file and a jar that holds velocity 
 templates.
 * ant docs - creates js docs. test in browser: doc/index.html
 * ant example-init - (depends ant dist on solr root) copies the current 
 built of solr.war and solr-velocity.jar to example/testsolr/..
 * ant example-start - starts the testsolr server on port 8983
 * ant example-import - imports 3000 test data rows (requires a started 
 testserver)
 Point your browser to example/testClientside.html 
 ,example/testServerSide.html or test/reuters/index.html to see it working.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-867) move EmbeddedSolrServer#getParsedResponse to utility class


[ 
https://issues.apache.org/jira/browse/SOLR-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648485#action_12648485
 ] 

Ryan McKinley commented on SOLR-867:


It has been on the TODO list for a long time  but I have not had the 
time/focus for it yet...

BinaryResponseWriter did not exist when the function first appeared.



 move EmbeddedSolrServer#getParsedResponse to utility class
 --

 Key: SOLR-867
 URL: https://issues.apache.org/jira/browse/SOLR-867
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-867-move-getParsedResponse.patch, 
 SOLR-867-move-getParsedResponse.patch


 The utility function: EmbeddedSolrServer#getParsedResponse should be moved to 
 a utiltiy class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-867) move EmbeddedSolrServer#getParsedResponse to utility class


[ 
https://issues.apache.org/jira/browse/SOLR-867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648489#action_12648489
 ] 

Ryan McKinley commented on SOLR-867:


{panel}
Every other object remains same at both ends of the pipe. 
{panel}
Maybe... there are a few other things that would need to get normalized to have 
the same output.  For example any Map implementation (LinkedHashMap etc) would 
become a HashMap.  

 move EmbeddedSolrServer#getParsedResponse to utility class
 --

 Key: SOLR-867
 URL: https://issues.apache.org/jira/browse/SOLR-867
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-867-move-getParsedResponse.patch, 
 SOLR-867-move-getParsedResponse.patch


 The utility function: EmbeddedSolrServer#getParsedResponse should be moved to 
 a utiltiy class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r714115 - /lucene/solr/trunk/example/solr/lib/

2008-11-14 Thread Ryan McKinley



On Nov 14, 2008, at 2:48 PM, [EMAIL PROTECTED] wrote:


Author: gsingers
Date: Fri Nov 14 11:48:47 2008
New Revision: 714115

URL: http://svn.apache.org/viewvc?rev=714115view=rev
Log:
put in the lib dir, as we're going to have some libs to put in there  
for SOLR-282




will SOLR-282 be a 'contrib' package?

In general we should figure out what we want the 'example' directory  
to be.  Currently each contrib has a full copy of it -- i don't think  
that is ideal.  Perhaps we have a 'minimum' example, and then a  
kitchen sink example...


ryan

Re: svn commit: r714115 - /lucene/solr/trunk/example/solr/lib/

2008-11-14 Thread Ryan McKinley



On Nov 14, 2008, at 5:37 PM, Grant Ingersoll wrote:



On Nov 14, 2008, at 5:11 PM, Ryan McKinley wrote:



On Nov 14, 2008, at 2:48 PM, [EMAIL PROTECTED] wrote:


Author: gsingers
Date: Fri Nov 14 11:48:47 2008
New Revision: 714115

URL: http://svn.apache.org/viewvc?rev=714115view=rev
Log:
put in the lib dir, as we're going to have some libs to put in  
there for SOLR-282




will SOLR-282 be a 'contrib' package?

In general we should figure out what we want the 'example'  
directory to be.  Currently each contrib has a full copy of it -- i  
don't think that is ideal.


Not following.  You mean the conf directory?  For SOLR-282, I hooked  
in a contrib-example target, similar to dist-contrib, that calls  
each contrib and asks it to do what it wants for the example.  In my  
case, I copy in some jars to the main example.




ya -- datainporthandler and velocity each have a duplicate 'conf'  
secion:


http://svn.apache.org/repos/asf/lucene/solr/trunk/contrib/velocity/src/main/solr/
http://svn.apache.org/repos/asf/lucene/solr/trunk/contrib/dataimporthandler/src/test/resources/solr/

short of having solrconfig #include, I'm not sure what the best way  
might be to have the contribs only specify the part relevant to their  
function.   I'm afraid we will have to punt until spring is involved...


ryan

Re: SOLR-139 and SOLR-828

2008-11-11 Thread Ryan McKinley



On Nov 10, 2008, at 3:52 PM, Tricia Williams wrote:


Hi,

  I am just wondering what the status of these issues (SOLR-139 and  
SOLR-828) is for supporting updateable/modifiable documents.
Specifically


  * Is anyone is clinging to an update of the SOLR-139 patch?

(https://issues.apache.org/jira/secure/attachment/12379550/Eriks-ModifiableDocument.patch
from 2008-04-07 doesn't apply cleanly anymore)
  * Where do people think this is at in terms of the completed  
solution?

  * Is SOLR-828 seeking to replace SOLR-139?



If you want something to work now, take the SOLR-828 approach.  (I  
have a working version of 139, but it is really ugly and not something  
I would recommend using)


As for the future of this, I think the basic design needs some  
thought.  I *think* we need to introduce a pluggable  
'storedDocumentLoader'; the default implementation could load the  
document from stored fields other implementations could load from SQL,  
disk or whatever.  Given the concurrency issues, I think this needs to  
be done within the DirectUpdateHandler rather then an UpdateProcessor.


My current work does not require modifiable documents, so I have not  
focused on it much...


ryan

[jira] Resolved: (SOLR-287) set commitMaxTime when adding a document

2008-11-09 Thread Ryan McKinley (JIRA)


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

Ryan McKinley resolved SOLR-287.


   Resolution: Duplicate
Fix Version/s: 1.4

identical to SOLR-793

 set commitMaxTime when adding a document
 

 Key: SOLR-287
 URL: https://issues.apache.org/jira/browse/SOLR-287
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-287-AddCommitMaxTime.patch, 
 SOLR-287-AddCommitMaxTime.patch


 Rather then setting a global autoCommit maxTime, it would be nice to set a 
 maximum time for a single add command.  This patch adds:
 add commitMaxTime=1000
   ...
 /add
 to add the document within 1 sec.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-620) Velocity Response Writer

2008-10-31 Thread Ryan McKinley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12644328#action_12644328
 ] 

Ryan McKinley commented on SOLR-620:


Looks good.

I think you should go ahead and commit it.  It is easier to keep track of the 
changes once it is committed.

 Velocity Response Writer
 

 Key: SOLR-620
 URL: https://issues.apache.org/jira/browse/SOLR-620
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Minor
 Attachments: SOLR-620.patch, SOLR-620.patch, SOLR-620.patch, 
 SOLR-620.patch, SOLR-620.zip, SOLR-620.zip


 Add a Velocity - http://velocity.apache.org - response writer, making it 
 possible to generate a decent search UI straight from Solr itself.  Designed 
 to work standalone or in conjunction with the JSON response writer (or 
 SolrJS) for Ajaxy things.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-620) Velocity Response Writer

2008-10-31 Thread Ryan McKinley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12644379#action_12644379
 ] 

Ryan McKinley commented on SOLR-620:


don't know why, but FF 3.0.3 (on mac) does not display anything unless we 
change:
{code}
Index: contrib/velocity/src/main/solr/conf/velocity/browse.vm
===
--- contrib/velocity/src/main/solr/conf/velocity/browse.vm  (revision 
709500)
+++ contrib/velocity/src/main/solr/conf/velocity/browse.vm  (working copy)
@@ -7,7 +7,7 @@
 head
   title#param('title')/title
   meta http-equiv=content-type content=text/html; charset=UTF-8/
-  script type=text/javascript src=/solr/admin/jquery-1.2.3.min.js/
+  script type=text/javascript 
src=/solr/admin/jquery-1.2.3.min.js/script
   link rel=stylesheet type=text/css 
href=/solr/admin/file?file=/velocity/main.csscontentType=text/css/
 /head
 body
{code}

 Velocity Response Writer
 

 Key: SOLR-620
 URL: https://issues.apache.org/jira/browse/SOLR-620
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Minor
 Attachments: SOLR-620.patch, SOLR-620.patch, SOLR-620.patch, 
 SOLR-620.patch, SOLR-620.zip, SOLR-620.zip


 Add a Velocity - http://velocity.apache.org - response writer, making it 
 possible to generate a decent search UI straight from Solr itself.  Designed 
 to work standalone or in conjunction with the JSON response writer (or 
 SolrJS) for Ajaxy things.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-620) Velocity Response Writer

2008-10-31 Thread Ryan McKinley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12644380#action_12644380
 ] 

Ryan McKinley commented on SOLR-620:


What are your thoughts on what should go in the velocity contrib src/main/solr 
files?

I don't like that it duplicates all the stuff in /trunk/example/solr

In my view (influenced by wicket), it would be great if the velocity templates 
were packaged in the .jar files rather then in the config directory. 

 Velocity Response Writer
 

 Key: SOLR-620
 URL: https://issues.apache.org/jira/browse/SOLR-620
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Minor
 Attachments: SOLR-620.patch, SOLR-620.patch, SOLR-620.patch, 
 SOLR-620.patch, SOLR-620.zip, SOLR-620.zip


 Add a Velocity - http://velocity.apache.org - response writer, making it 
 possible to generate a decent search UI straight from Solr itself.  Designed 
 to work standalone or in conjunction with the JSON response writer (or 
 SolrJS) for Ajaxy things.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Solrj] Problem with Request

2008-10-30 Thread Ryan McKinley

if you are using the standard request handler, : is a keyword...  so  
you are looking for a field called http with value //www.webspawner.com/users/smartbus/ 



either switch to the 'dismax' query parser, or escape the string  
before sending it to solr:


query.setQuery( ClientUtils.escapeQueryChars( queryString ) )



On Oct 30, 2008, at 3:59 PM, Jose Garcia wrote:


Hi,

I use  solrj for my application and  have one problem with the  
SolrQuery. I
create my own query but it don't work. I want to search urls in my  
text
indexed. How can I avoid : in my query? Exists  any method in the  
Solrj

API for this?

Best Regards

QueryString = http://www.webspawner.com/users/smartbus/;
SolrQuery query = new SolrQuery();
   query.setQuery(queryString);

Error:
Caused by: org.apache.solr.common.SolrException:
org.apache.lucene.queryParser.ParseException: Cannot parse 'html:
http://www.webspawner.com/smartbus/user': Encountered : at line 1,  
column
9. Was expecting one of: EOF  AND ... OR ...  
NOT
...   ... - ... ( ... * ... ^ ...  
QUOTED
... TERM ... FUZZY_SLOP ... PREFIXTERM ...  
WILDTERM

... [ ... { ... NUMBER ...
[java] org.apache.lucene.queryParser.ParseException: Cannot parse
'html:http://www.webspawner.com/smartbus/user': Encountered : at  
line 1,

column 9. Was expecting one of: EOF  AND ... OR ...
NOT ...   ... - ... ( ... * ... ^ ...
QUOTED ... TERM ... FUZZY_SLOP ... PREFIXTERM ...
WILDTERM ... [ ... { ... NUMBER ...
[java] request:
http://localhost:8081/apache-solr-1.3-dev/select?q=html:http://www.webspawner.com/smartbus/userwt=javabinversion=2.2
[java] at
org 
.apache 
.solr 
.client 
.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java: 
343)

[java] at
org 
.apache 
.solr 
.client 
.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java: 
183)

[java] at
org 
.apache 
.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90)

[java] ... 3 more

[jira] Assigned: (SOLR-816) deprecate access to SolrConfig from IndexSchema


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

Ryan McKinley reassigned SOLR-816:
--

Assignee: Ryan McKinley

 deprecate access to SolrConfig from IndexSchema
 ---

 Key: SOLR-816
 URL: https://issues.apache.org/jira/browse/SOLR-816
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 1.3
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-816-remove-solrconfg-from-indexschema.patch


 In trying to clean up the configuration mess we have, I notice we have too 
 much access to things we don't really need.
 The IndexSchema does not need to know about how the rest of solr is 
 configured. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-816) deprecate access to SolrConfig from IndexSchema


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

Ryan McKinley resolved SOLR-816.


Resolution: Fixed

 deprecate access to SolrConfig from IndexSchema
 ---

 Key: SOLR-816
 URL: https://issues.apache.org/jira/browse/SOLR-816
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 1.3
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-816-remove-solrconfg-from-indexschema.patch


 In trying to clean up the configuration mess we have, I notice we have too 
 much access to things we don't really need.
 The IndexSchema does not need to know about how the rest of solr is 
 configured. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-816) deprecate access to SolrConfig from IndexSchema


[ 
https://issues.apache.org/jira/browse/SOLR-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12642995#action_12642995
 ] 

Ryan McKinley commented on SOLR-816:


Sorry, my commit message put the wrong issue number.  For changes, see:
http://svn.apache.org/viewvc?view=revrevision=708259

 deprecate access to SolrConfig from IndexSchema
 ---

 Key: SOLR-816
 URL: https://issues.apache.org/jira/browse/SOLR-816
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 1.3
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-816-remove-solrconfg-from-indexschema.patch


 In trying to clean up the configuration mess we have, I notice we have too 
 much access to things we don't really need.
 The IndexSchema does not need to know about how the rest of solr is 
 configured. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-803) CoreAdminRequest.createCore fails because name parameter isn't set


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

Ryan McKinley resolved SOLR-803.


Resolution: Fixed

commited in rev #708266
Thanks Sean!

 CoreAdminRequest.createCore fails because name parameter isn't set
 --

 Key: SOLR-803
 URL: https://issues.apache.org/jira/browse/SOLR-803
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 1.3
Reporter: Hoss Man
Assignee: Ryan McKinley
 Attachments: SOLR-803.patch, SOLR-803.patch


 I have not validated that this is a real bug, but since it doesn't seem to 
 have gotten any comments on hte mailinglist i figured i'd post it so there 
 was a record of it...
 http://www.nabble.com/Create-new-core-by-solrj-API-fails-to19740822.html#a19740822
 {noformat}
 Message-ID: [EMAIL PROTECTED]
 Date: Tue, 30 Sep 2008 05:11:55 -0700 (PDT)
 From: Parisa
 To: solr-dev
 Subject: Create new core by solrj API fails
 Creating new Core By solrj API (CoreAdminRequest.createCore) fails because it
 doesn't set name parameter
 in getParameters method of CoreAdminRequest class
 solr version :1.3
 {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields


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

Ryan McKinley reassigned SOLR-680:
--

Assignee: Ryan McKinley

 StatsComponent - get min, max, sum, qt, avg of number fields
 

 Key: SOLR-680
 URL: https://issues.apache.org/jira/browse/SOLR-680
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Koji Sekiguchi
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-680.patch, SOLR-680.patch, SOLR-680.patch, 
 SOLR-680.patch, SOLR-680.patch, SOLR-680.patch


 StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
 request parameters:
 stats=onstats.field=price
 {code:xml}
 stats
  stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
  /stats_fields
 /stats
 {code}
 WRT stats, the component can output sum and avg, but not sd and var.
 USE CASE:
 StatsComponent can be used to get market price of DocSet e.g. rental 
 housing site, package tour site.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields


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

Ryan McKinley resolved SOLR-680.


Resolution: Fixed

 StatsComponent - get min, max, sum, qt, avg of number fields
 

 Key: SOLR-680
 URL: https://issues.apache.org/jira/browse/SOLR-680
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Koji Sekiguchi
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-680.patch, SOLR-680.patch, SOLR-680.patch, 
 SOLR-680.patch, SOLR-680.patch, SOLR-680.patch


 StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
 request parameters:
 stats=onstats.field=price
 {code:xml}
 stats
  stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
  /stats_fields
 /stats
 {code}
 WRT stats, the component can output sum and avg, but not sd and var.
 USE CASE:
 StatsComponent can be used to get market price of DocSet e.g. rental 
 housing site, package tour site.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Create new core by solrj API fails

2008-10-23 Thread Ryan McKinley


can you open a JIRA issue and attach a diff?

see:
http://wiki.apache.org/solr/HowToContribute

thanks!
ryan


On Oct 22, 2008, at 9:16 PM, SinistralEnigma wrote:



I've fixed the problem below which was preventing SolrJ clients from  
making a
call which would create a new core on a Solr server.  I've also  
overloaded

the createCore() method to allow the user to provide a config file and
schema file if they desire (optional).

Here is what the changed code looks like:
http://pastie.org/298579

There were very few changes in there, so it should be straight- 
forward.  If
there is a better or more organized way to get these changes into  
the SolrJ
code, please let me know.  The bugfix at least seems to be pretty  
essential.

Thanks,
- SinistralEnigma



SinistralEnigma wrote:


I can verify that I have the same problem when trying to use SolrJ's
CoreAdminRequest.createCore() to create a new core.  It looks like  
this is

caused by the request accidentally sending a core parameter for the
parameter that is supposed to be name

For example, to create a core named newCore SolrJ sends a request  
like

this:
http://localhost:8983/solr/admin/cores?action=CREATEcore=newCoreinstanceDir=newcoredirectorywt=javabinversion=2.2
When it should send a request like this:
http://localhost:8983/solr/admin/cores?action=CREATEname=newCoreinstanceDir=newcoredirectorywt=javabinversion=2.2

Also, not to be nit-picky, but it'd be nice to be able to send in the
config and schema parameters to the CoreAdminRequest.createCore()  
method.

- SinistralEnigma


Parisa wrote:


Creating new Core By solrj API (CoreAdminRequest.createCore) fails
because it doesn't set name parameter
in getParameters method of CoreAdminRequest class


solr version :1.3

Parisa






--
View this message in context: 
http://www.nabble.com/Create-new-core-by-solrj-API-fails-tp19740822p20122717.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: Must QueryComponent always be on and other Design Questions

2008-10-21 Thread Ryan McKinley


unrelated to your question, but we should give a better error...
https://issues.apache.org/jira/browse/SOLR-435


On Oct 20, 2008, at 8:01 PM, Grant Ingersoll wrote:


For completeness, here's the NPE:
SEVERE: java.lang.NullPointerException
at org.apache.solr.common.util.StrUtils.splitSmart(StrUtils.java:37)
	at  
org 
.apache.solr.search.OldLuceneQParser.parse(LuceneQParserPlugin.java: 
104)

at org.apache.solr.search.QParser.getQuery(QParser.java:88)
	at  
org 
.apache 
.solr.handler.component.QueryComponent.prepare(QueryComponent.java:82)
	at  
org 
.apache 
.solr 
.handler 
.component.SearchHandler.handleRequestBody(SearchHandler.java:149)
	at  
org 
.apache 
.solr 
.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
	at  
org 
.apache 
.solr 
.handler 
.clustering 
.ClusteringComponentTest.testComponent(ClusteringComponentTest.java: 
70)


Don't worry about the ClusteringComponentTest yet, I haven't posted  
that code yet.


On Oct 20, 2008, at 7:56 PM, Grant Ingersoll wrote:

I've run into this a couple of times now and I feel like it  
warrants a discussion


For both the SpellCheckComponent (SCC) and now for the new  
ClusteringComponent (SOLR-769) I think there are cases where the  
QueryComponent (QC) is not required.  In the SpellCheckComponent  
case it is when building the spelling index.  In the  
ClusteringComponent, it is possible to ask for document clusters  
without running any query (it also will be possible to get clusters  
_with_ a query as well, and it also is distinguished from the  
handling of search results clustering, too).  Thus, it seems really  
weird to have to pass in a dummy query, yet that is what one has to  
do in order to avoid getting an NPE in the QC.


Now, I suppose these pieces could be modeled as something else or  
it's possible to split the two functionalities into separate things  
(1 ReqHandler, 1 SearchComp).  In fact, the said functionality is  
not really search functionality, or SearchComponent  
functionality, yet much of the rest of the functionality in the  
code in question is search functionality and logically belongs as  
a SearchComponent.  In the case of the SCC build, it's akin to an  
indexing operation.  In the clustering case, it's a query, albeit a  
non-traditional one.  In some sense, this kind of document  
clustering is like non-query based faceting which leads to more  
navigation/browsing instead of searching.


The quick fix is to just put in null checks into the QC or pass in  
a dummy query with rows=0, but I'm not sure if there isn't a  
slightly bigger picture here that needs adjusting in terms of  
SearchComponents.  Namely, must the QC always be on?  And, should  
we think a little more about components that don't require a query  
in order to function and how they play in the scheme of things?


Thoughts?  Recommendations?

-Grant

[jira] Updated: (SOLR-435) QParser must validate existance/absense of q parameter

2008-10-21 Thread Ryan McKinley (JIRA)


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

Ryan McKinley updated SOLR-435:
---

Fix Version/s: 1.4

 QParser must validate existance/absense of q parameter
 

 Key: SOLR-435
 URL: https://issues.apache.org/jira/browse/SOLR-435
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.3
Reporter: Ryan McKinley
 Fix For: 1.4


 Each QParser should check if q exists or not.  For some it will be required 
 others not.
 currently it throws a null pointer:
 {code}
 java.lang.NullPointerException
   at org.apache.solr.common.util.StrUtils.splitSmart(StrUtils.java:36)
   at 
 org.apache.solr.search.OldLuceneQParser.parse(LuceneQParserPlugin.java:104)
   at org.apache.solr.search.QParser.getQuery(QParser.java:80)
   at 
 org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:67)
   at 
 org.apache.solr.handler.SearchHandler.handleRequestBody(SearchHandler.java:150)
 ...
 {code}
 see:
 http://www.nabble.com/query-parsing-error-to14124285.html#a14140108

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Must QueryComponent always be on and other Design Questions

2008-10-21 Thread Ryan McKinley



On Oct 21, 2008, at 8:17 AM, Grant Ingersoll wrote:



On Oct 20, 2008, at 11:35 PM, Otis Gospodnetic wrote:

This is related to something I must have only day dreamed (dreamt?)  
about, but not actually mentioned on solr-dev.
My feeling is we are moving Solr in a direction of a more general  
web service that can host various NLP and ML components, and no  
longer only do IR/Lucene.  We see that with a few patches that  
Grant is cooking, I think we'll see that in the Solr+Mahout  
marriage down the road, and so on.


I somewhat agree, but I hesitate to go so far as saying a general  
web service.


I won't suggest that solr is (or should be) a general web service, but  
wt=json/xml/python + RequestHandler makes a pretty nice cross platform  
interface all on its own.



I see Solr as a pretty nice platform for doing things like NLP/ML  
(see the AnalysisRequestHandler, TermVectorComponent,  
ClusteringComponent, LukeReqHandler, FacetingComp., Payloads, etc.),  
but I mostly view them as enhancing search/navigation.   That is,  
things like clustering/faceting (they are closely related), named  
entity recognition, search, etc. all act as organizing components  
for structured and unstructured data.  Expressing my vision for Solr  
(and actually, the Lucene TLP, too, if I put on my PMC hat) it's one  
that aims to bring coherence to (structured and unstructured)  
content.  This starts with search as a foundation, since the  
indexing process creates much of the information that empowers the  
others.  I think once you see the flexible indexing stuff added to  
Lucene Java, we'll see even more opportunity for making Solr even  
more powerful in these regards.




agree.





Is it time to start thinking about Solr sa a server for IR and ML  
and NLP tasks and see how the tightly coupled Lucene can be made  
morepluggable?


Yeah, this is what the Solr 2.0 thread that Yonik started a few  
weeks ago aims to discuss, along with scalability/fault tolerance.   
More important, for me anyway, is the decoupling of the  
configuration.  For instance, I see no reason why IndexSchema needs  
to know anything about an InputStream.


also agree.  The biggest challenge for 2.0 is decoupling configuration

As for Lucene, it's really quite good at serving as the backend  
store/enabler for all these tasks.




I have not messed with it yet, but perhaps also HBase...



At any rate, the question still remains as to how best to handle the  
QueryComponent :-)




aaah, your question!

I see two options:
1.  If no other component needs docList or docSet and the query is  
empty, then skip the QueryComponent
2.  add a 'runQuery' param (or somethign like that) and default to  
true.  It can be turned off when not necessary.


I like option 1 better.

ryan

Re: immediatley commit of docs doesn't work in multiCore case

2008-10-20 Thread Ryan McKinley


Do you have the XmlUpdateRequestHandler mapped to /update?

if that fixes it, we should make a bigger note on:
http://wiki.apache.org/solr/Solrj

ryan



On Oct 20, 2008, at 10:41 AM, Parisa wrote:



Hi,

I want to see the doc that is committed as soon as I commit it in my  
search

result so

I did as you suggest :


solrUrl = http://mySolrServer:8080/solr/core1/;;

CommonsHttpSolrServer server = new CommonsHttpSolrServer(solrUrl);
server.setParser(new XMLResponseParser());

UpdateRequest req = new UpdateRequest();
req.setAction(UpdateRequest.ACTION.COMMIT, false,false);
req.add(solrDoc);
UpdateResponse rsp = req.process(server);


a you see I use multicore config and every thing is ok but when I  
commit it
I can't see this doc in search result unless I restart the solr  
server.


I have also tested it with this code:
 server.add(solrDoc);
server.commit(false,false);

I track the commit method in DirectUpdateHandler2 class  and it is  
called

and works correctly .


Regards,

Parisa








--
View this message in context: 
http://www.nabble.com/immediatley-commit-of-docs-doesn%27t-work-in-multiCore-case-tp20069593p20069593.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: dynamic filtering

2008-10-20 Thread Ryan McKinley


I don't quite follow what you are trying to do
can you give a concrete example?

What is missing from the Filter side?

if you need to modify the lucene Query, a custom SearchComponent is  
the way to go...



On Oct 20, 2008, at 6:13 PM, xibin wrote:



Hi -

I have done some searching and haven't found what I was looking for.  
I hope

this has not been discussed in the forum already.

This is a question as well as looking for design ideas.

I need the ability to dynamically filter out search results as they  
are
being collected. The logic that I am developing cannot be statically  
applied
at indexing time, so the data is NOT available in the indexed form.  
It can
be derived/calculated using one or more of the indexed fields, and  
it's

different for each query. The purpose of this derived field is to
eliminate resulting indexes so only a subset is considered. This is  
very
similar to the Filter concept already in the  
SolrIndexSearcher.QueryCommand.
The difference is that I can't write a Lucene Query to obtain the  
subset of
indices, I need to implement an algorithm involving using some of  
the fields

in the documents.

What I had in mind is the concept of a DyamicFilter. A DynamicFilter  
can be

used in the HitCollectors (in SolrIndexSearcher) to perform dynamic
filtering as results are being collected. DynamicFilters would be  
added into

the SolrSearchIndexer.QueryCommand class so they can be called during
collecting time. I considered writing a SearchComponent or a  
RequestHandler,

and they seem to be a little bit off for the timing that I needed.

The parameters to construct my DynamicFilters are passed in from  
http query

params. I could pick them up and create the DynamicFilters in the
QueryComponent as it creates a QueryCommand. The QueryCommand will  
then use

it during Hit Collection in SolrIndexSearcher.

I hope this captures the detail of what I am trying to do. I am  
looking for
validation/alternative suggestions from an insider (yonik?). I feel  
bad
having to do the intrusive modification here, and am open for  
suggestions. I

would be interested in contributing this work if it turns out to be
valuable.

Thanks for reading.

Xibin
--
View this message in context: 
http://www.nabble.com/dynamic-filtering-tp20079841p20079841.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

Re: dynamic filtering

2008-10-20 Thread Ryan McKinley


check:
https://issues.apache.org/jira/browse/LUCENE-1387

On Oct 20, 2008, at 6:56 PM, xibin wrote:



Thanks for the reply.

Let's say that I have a location code field in the document. Say  
there are

2000 indexed documents that have various location codes. When a user
searches, she specifies her own location, as well as the maximum  
radius that
she wants the distance to be, in addition to other search fields  
that she

may specify.

In order to satisfy this scenario, I am thinking about performing  
the search

using all the other fields normally, but use a distance to dynamically
filter out unwanted results. This way the distance calculation  
performs
filtering, and the relevancy from other search fields does not  
change...


Let me know if this makes sense to you.

Thanks
Xibin


ryantxu wrote:


I don't quite follow what you are trying to do
can you give a concrete example?

What is missing from the Filter side?

if you need to modify the lucene Query, a custom SearchComponent is
the way to go...


On Oct 20, 2008, at 6:13 PM, xibin wrote:



Hi -

I have done some searching and haven't found what I was looking for.
I hope
this has not been discussed in the forum already.

This is a question as well as looking for design ideas.

I need the ability to dynamically filter out search results as they
are
being collected. The logic that I am developing cannot be statically
applied
at indexing time, so the data is NOT available in the indexed form.
It can
be derived/calculated using one or more of the indexed fields, and
it's
different for each query. The purpose of this derived field is to
eliminate resulting indexes so only a subset is considered. This is
very
similar to the Filter concept already in the
SolrIndexSearcher.QueryCommand.
The difference is that I can't write a Lucene Query to obtain the
subset of
indices, I need to implement an algorithm involving using some of
the fields
in the documents.

What I had in mind is the concept of a DyamicFilter. A DynamicFilter
can be
used in the HitCollectors (in SolrIndexSearcher) to perform dynamic
filtering as results are being collected. DynamicFilters would be
added into
the SolrSearchIndexer.QueryCommand class so they can be called  
during

collecting time. I considered writing a SearchComponent or a
RequestHandler,
and they seem to be a little bit off for the timing that I needed.

The parameters to construct my DynamicFilters are passed in from
http query
params. I could pick them up and create the DynamicFilters in the
QueryComponent as it creates a QueryCommand. The QueryCommand will
then use
it during Hit Collection in SolrIndexSearcher.

I hope this captures the detail of what I am trying to do. I am
looking for
validation/alternative suggestions from an insider (yonik?). I feel
bad
having to do the intrusive modification here, and am open for
suggestions. I
would be interested in contributing this work if it turns out to be
valuable.

Thanks for reading.

Xibin
--
View this message in context:
http://www.nabble.com/dynamic-filtering-tp20079841p20079841.html
Sent from the Solr - Dev mailing list archive at Nabble.com.







--
View this message in context: 
http://www.nabble.com/dynamic-filtering-tp20079841p20080481.html
Sent from the Solr - Dev mailing list archive at Nabble.com.

[jira] Resolved: (SOLR-813) Add new DoubleMetaphone Filter and Factory


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

Ryan McKinley resolved SOLR-813.


   Resolution: Fixed
Fix Version/s: 1.4

Added in rev: 705903
Thanks Todd!

 Add new DoubleMetaphone Filter and Factory
 --

 Key: SOLR-813
 URL: https://issues.apache.org/jira/browse/SOLR-813
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: Todd Feak
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-813.patch, SOLR-813.patch, SOLR-813.patch


 The existing PhoneticFilter allows for use of the DoubleMetaphone encoder. 
 However, it doesn't expose the maxCodeLength() setting, and it ignores the 
 alternate encodings that the encoder provides for some words. This new filter 
 is not as generic as the PhoneticFilter, but allows more detailed control 
 over the DoubleMetaphone encoder.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-816) deprecate access to SolrConfig from IndexSchema


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

Ryan McKinley updated SOLR-816:
---

Attachment: SOLR-816-remove-solrconfg-from-indexschema.patch

 deprecate access to SolrConfig from IndexSchema
 ---

 Key: SOLR-816
 URL: https://issues.apache.org/jira/browse/SOLR-816
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 1.3
Reporter: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-816-remove-solrconfg-from-indexschema.patch


 In trying to clean up the configuration mess we have, I notice we have too 
 much access to things we don't really need.
 The IndexSchema does not need to know about how the rest of solr is 
 configured. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-817) Clarify 'Default' Components behavior

Clarify 'Default' Components behavior
-

 Key: SOLR-817
 URL: https://issues.apache.org/jira/browse/SOLR-817
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan McKinley


See: 
http://www.nabble.com/What-is-a-%22Standard%22-SearchComponent---(SOLR-680)-td19768487.html


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-817) Clarify 'Default' Components behavior


[ 
https://issues.apache.org/jira/browse/SOLR-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640801#action_12640801
 ] 

Ryan McKinley commented on SOLR-817:


I propose we have two core RequestHandlers:

StandardSearchHandler (StandardRequestHandler?)
 * load all 'standard' components.
 * 'standard' components will be everything that that does not require extra 
configuration (no spellchecker)
 * can not configure what components are available


SearchHandler
 * deprecate first/last component concept
 * deprecate absent 'components' tag
   * ie. in the future, require explicit configuration of all components for 
SearchHandler



 Clarify 'Default' Components behavior
 -

 Key: SOLR-817
 URL: https://issues.apache.org/jira/browse/SOLR-817
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan McKinley

 See: 
 http://www.nabble.com/What-is-a-%22Standard%22-SearchComponent---(SOLR-680)-td19768487.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields


[ 
https://issues.apache.org/jira/browse/SOLR-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640802#action_12640802
 ] 

Ryan McKinley commented on SOLR-680:


I will go ahead and commit this now... we can sort out the default search 
components issue in SOLR-817.

 StatsComponent - get min, max, sum, qt, avg of number fields
 

 Key: SOLR-680
 URL: https://issues.apache.org/jira/browse/SOLR-680
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Koji Sekiguchi
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-680.patch, SOLR-680.patch, SOLR-680.patch, 
 SOLR-680.patch, SOLR-680.patch, SOLR-680.patch


 StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
 request parameters:
 stats=onstats.field=price
 {code:xml}
 stats
  stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
  /stats_fields
 /stats
 {code}
 WRT stats, the component can output sum and avg, but not sd and var.
 USE CASE:
 StatsComponent can be used to get market price of DocSet e.g. rental 
 housing site, package tour site.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-817) Clarify 'Default' Components behavior


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

Ryan McKinley updated SOLR-817:
---

Attachment: SOLR-817-default-components.patch

 Clarify 'Default' Components behavior
 -

 Key: SOLR-817
 URL: https://issues.apache.org/jira/browse/SOLR-817
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan McKinley
 Attachments: SOLR-817-default-components.patch


 See: 
 http://www.nabble.com/What-is-a-%22Standard%22-SearchComponent---(SOLR-680)-td19768487.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-813) Add new DoubleMetaphone Filter and Factory

2008-10-17 Thread Ryan McKinley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640637#action_12640637
 ] 

Ryan McKinley commented on SOLR-813:


rather then create a new Filter for DoubleMetaphone, why not just extend 
PhoneticFilter to support maxCodeLength?

Here is a quick untested bit that uses reflection to set the maxCodeLength -- 
the advantage is that it would also work for 'Metaphone' (though i'm not sure 
anyone uses that).

Since the reflection only happens once at starup, it is not a big deal.

{code:java}
Index: src/java/org/apache/solr/analysis/PhoneticFilterFactory.java
===
--- src/java/org/apache/solr/analysis/PhoneticFilterFactory.java
(revision 704289)
+++ src/java/org/apache/solr/analysis/PhoneticFilterFactory.java
(working copy)
@@ -17,10 +17,10 @@
 
 package org.apache.solr.analysis;
 
+import java.lang.reflect.Method;
 import java.util.HashMap;
 import java.util.Map;
 
-import org.apache.solr.core.SolrConfig;
 import org.apache.commons.codec.Encoder;
 import org.apache.commons.codec.language.DoubleMetaphone;
 import org.apache.commons.codec.language.Metaphone;
@@ -80,6 +80,13 @@
 
 try {
   encoder = clazz.newInstance();
+  
+  // Try to set the maxCodeLength
+  String v = args.get( maxCodeLength );
+  if( v != null ) {
+Method setter = encoder.getClass().getMethod( setMaxCodeLength, 
Integer.class );
+setter.invoke( encoder, Integer.parseInt( v ) );
+  }
 } 
 catch (Exception e) {
   throw new SolrException( SolrException.ErrorCode.SERVER_ERROR, Error 
initializing: +name + /+clazz, e );

{code}

 Add new DoubleMetaphone Filter and Factory
 --

 Key: SOLR-813
 URL: https://issues.apache.org/jira/browse/SOLR-813
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: Todd Feak
Priority: Minor
 Attachments: SOLR-813.patch


 The existing PhoneticFilter allows for use of the DoubleMetaphone encoder. 
 However, it doesn't expose the maxCodeLength() setting, and it ignores the 
 alternate encodings that the encoder provides for some words. This new filter 
 is not as generic as the PhoneticFilter, but allows more detailed control 
 over the DoubleMetaphone encoder.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-813) Add new DoubleMetaphone Filter and Factory

2008-10-17 Thread Ryan McKinley (JIRA)


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

Ryan McKinley reassigned SOLR-813:
--

Assignee: Ryan McKinley

 Add new DoubleMetaphone Filter and Factory
 --

 Key: SOLR-813
 URL: https://issues.apache.org/jira/browse/SOLR-813
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: Todd Feak
Assignee: Ryan McKinley
Priority: Minor
 Attachments: SOLR-813.patch, SOLR-813.patch


 The existing PhoneticFilter allows for use of the DoubleMetaphone encoder. 
 However, it doesn't expose the maxCodeLength() setting, and it ignores the 
 alternate encodings that the encoder provides for some words. This new filter 
 is not as generic as the PhoneticFilter, but allows more detailed control 
 over the DoubleMetaphone encoder.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-813) Add new DoubleMetaphone Filter and Factory

2008-10-17 Thread Ryan McKinley (JIRA)


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

Ryan McKinley updated SOLR-813:
---

Attachment: SOLR-813.patch

oops, last patch had a bug if the stream ended in a non-phonetic value:

{code:java}
  if( !isPhonetic ) {
t = next(in);
if( t != null ) {
  t.setPositionIncrement( t.getPositionIncrement()+1 ); 
}
return t;
  }
{code}

 Add new DoubleMetaphone Filter and Factory
 --

 Key: SOLR-813
 URL: https://issues.apache.org/jira/browse/SOLR-813
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: Todd Feak
Assignee: Ryan McKinley
Priority: Minor
 Attachments: SOLR-813.patch, SOLR-813.patch, SOLR-813.patch


 The existing PhoneticFilter allows for use of the DoubleMetaphone encoder. 
 However, it doesn't expose the maxCodeLength() setting, and it ignores the 
 alternate encodings that the encoder provides for some words. This new filter 
 is not as generic as the PhoneticFilter, but allows more detailed control 
 over the DoubleMetaphone encoder.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-793) set a commit time bounds in the add command

2008-10-13 Thread Ryan McKinley (JIRA)


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

Ryan McKinley resolved SOLR-793.


   Resolution: Fixed
Fix Version/s: 1.4

Thanks for checking this out Mike.

I changed max time logic to use:
{code:java}
  long ctime = (commitWithin0) ? commitWithin : timeUpperBound;
  if( ctime  0 ) {
scheduleCommitWithin( ctime );
  }
{code}

This way, if you have a timeUpperBound set, it will use the passed in argument 
rather then the minimum of the two times.

 set a commit time bounds in the add command
 -

 Key: SOLR-793
 URL: https://issues.apache.org/jira/browse/SOLR-793
 Project: Solr
  Issue Type: Improvement
  Components: update
Reporter: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-793-commitWithin.patch, SOLR-793-commitWithin.patch


 Currently there are two options for how to handle commiting documents:
 1. the client explicitly starts the commit via commit/
 2. set an auto commit value on the server -- clients can assume all documents 
 will be commited within that time.
 However, this does not help in the case where the clients know what documents 
 need updating quickly and others that could wait.  I suggest adding:
 {code:xml}
  add commitWithin=100...
 {/code:xml} 
 to the update syntax so the client can schedule commits explicitly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-721) DirectSolrConnection is broken - missing CoreContainer initialization


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

Ryan McKinley reassigned SOLR-721:
--

Assignee: Ryan McKinley

 DirectSolrConnection is broken - missing CoreContainer initialization
 -

 Key: SOLR-721
 URL: https://issues.apache.org/jira/browse/SOLR-721
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Henri Biestro
Assignee: Ryan McKinley
 Fix For: 1.4


 It might be initialized in such a way that no core container is created.
 Adding the proper includes  a member:
 {code}
 final CoreContainer cores;
 {code}
 And modifying the constructor:
 {code}
   public DirectSolrConnection( String instanceDir, String dataDir, String 
 loggingPath )
   {
 // If a loggingPath is specified, try using that (this needs to happen 
 first)
 if( loggingPath != null ) {
   File loggingConfig = new File( loggingPath );
   if( !loggingConfig.exists()  instanceDir != null ) {
 loggingConfig = new File( new File(instanceDir), loggingPath  );
   }
   if( loggingConfig.exists() ) {
 System.setProperty(java.util.logging.config.file, 
 loggingConfig.getAbsolutePath() ); 
   }
   else {
 throw new SolrException( SolrException.ErrorCode.SERVER_ERROR, can 
 not find logging file: +loggingConfig );
   }
 }
 
 // Initialize CoreContainer
 try {
   cores = new CoreContainer(new 
 SolrResourceLoader(SolrResourceLoader.locateInstanceDir()));
   SolrConfig solrConfig = new SolrConfig(instanceDir, 
 SolrConfig.DEFAULT_CONF_FILE, null);
   CoreDescriptor dcore = new CoreDescriptor(cores, , 
 solrConfig.getResourceLoader().getInstanceDir());
   IndexSchema indexSchema = new IndexSchema(solrConfig, 
 instanceDir+/conf/schema.xml, null);
   core = new SolrCore( null, dataDir, solrConfig, indexSchema, dcore);
   cores.register(, core, false);
   parser = new SolrRequestParsers( config );
 } 
 catch (Exception ee) {
   throw new RuntimeException(ee);
 }
   }
 {code}
 Should take care of this case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-721) DirectSolrConnection is broken - missing CoreContainer initialization


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

Ryan McKinley resolved SOLR-721.


Resolution: Fixed

fixed in trunk...
thanks Henri!

 DirectSolrConnection is broken - missing CoreContainer initialization
 -

 Key: SOLR-721
 URL: https://issues.apache.org/jira/browse/SOLR-721
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Henri Biestro
Assignee: Ryan McKinley
 Fix For: 1.4


 It might be initialized in such a way that no core container is created.
 Adding the proper includes  a member:
 {code}
 final CoreContainer cores;
 {code}
 And modifying the constructor:
 {code}
   public DirectSolrConnection( String instanceDir, String dataDir, String 
 loggingPath )
   {
 // If a loggingPath is specified, try using that (this needs to happen 
 first)
 if( loggingPath != null ) {
   File loggingConfig = new File( loggingPath );
   if( !loggingConfig.exists()  instanceDir != null ) {
 loggingConfig = new File( new File(instanceDir), loggingPath  );
   }
   if( loggingConfig.exists() ) {
 System.setProperty(java.util.logging.config.file, 
 loggingConfig.getAbsolutePath() ); 
   }
   else {
 throw new SolrException( SolrException.ErrorCode.SERVER_ERROR, can 
 not find logging file: +loggingConfig );
   }
 }
 
 // Initialize CoreContainer
 try {
   cores = new CoreContainer(new 
 SolrResourceLoader(SolrResourceLoader.locateInstanceDir()));
   SolrConfig solrConfig = new SolrConfig(instanceDir, 
 SolrConfig.DEFAULT_CONF_FILE, null);
   CoreDescriptor dcore = new CoreDescriptor(cores, , 
 solrConfig.getResourceLoader().getInstanceDir());
   IndexSchema indexSchema = new IndexSchema(solrConfig, 
 instanceDir+/conf/schema.xml, null);
   core = new SolrCore( null, dataDir, solrConfig, indexSchema, dcore);
   cores.register(, core, false);
   parser = new SolrRequestParsers( config );
 } 
 catch (Exception ee) {
   throw new RuntimeException(ee);
 }
   }
 {code}
 Should take care of this case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-736) SolrCore.getSolrCore() may create a SolrCore without a CoreContainer


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

Ryan McKinley reassigned SOLR-736:
--

Assignee: Ryan McKinley

 SolrCore.getSolrCore() may create a SolrCore without a CoreContainer
 

 Key: SOLR-736
 URL: https://issues.apache.org/jira/browse/SOLR-736
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Henri Biestro
Assignee: Ryan McKinley

 The method is deprecated but one can still initialize  start working this 
 way.
 Potential fix could be:
 {code}
   @Deprecated
   public static SolrCore getSolrCore() {
 synchronized( SolrCore.class ) {
   if( instance == null ) {
 try {
   // sets 'instance' to the latest solr core
   CoreContainer.Initializer init = new CoreContainer.Initializer();
   instance = init.initialize().getCore();
 } catch(Exception xany) {
   throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
   error creating core, xany );
 }
   }
 }
 return instance;
   }
 {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-736) SolrCore.getSolrCore() may create a SolrCore without a CoreContainer


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

Ryan McKinley resolved SOLR-736.


   Resolution: Fixed
Fix Version/s: 1.4

thanks Henri!

 SolrCore.getSolrCore() may create a SolrCore without a CoreContainer
 

 Key: SOLR-736
 URL: https://issues.apache.org/jira/browse/SOLR-736
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Henri Biestro
Assignee: Ryan McKinley
 Fix For: 1.4


 The method is deprecated but one can still initialize  start working this 
 way.
 Potential fix could be:
 {code}
   @Deprecated
   public static SolrCore getSolrCore() {
 synchronized( SolrCore.class ) {
   if( instance == null ) {
 try {
   // sets 'instance' to the latest solr core
   CoreContainer.Initializer init = new CoreContainer.Initializer();
   instance = init.initialize().getCore();
 } catch(Exception xany) {
   throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
   error creating core, xany );
 }
   }
 }
 return instance;
   }
 {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-802) Trivial bug in distributed FacetComponent code that could cause null pointer exception

2008-10-07 Thread Ryan McKinley (JIRA)


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

Ryan McKinley updated SOLR-802:
---

Summary: Trivial bug in distributed FacetComponent code that could cause 
null pointer exception  (was: Trivial bug which could cause null pointer 
exception)

 Trivial bug in distributed FacetComponent code that could cause null pointer 
 exception
 --

 Key: SOLR-802
 URL: https://issues.apache.org/jira/browse/SOLR-802
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.3
Reporter: David Bowen
Assignee: Ryan McKinley
Priority: Minor
 Attachments: patch


 In FacetComponent there's an  which should be a .  Patch to follow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-793) set a commit time bounds in the add command

[
https://issues.apache.org/jira/browse/SOLR-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637114#action_12637114
]

Ryan McKinley commented on SOLR-793:

perhaps it is better to think of it as selectivly enabling the autoCommit
feature.

bq. If I have 10 docs with with a commitWithin=100 This may mean that there
will be 10 commits because each add happened at different time.

assuming the last of the 10 docs were sent to solr within 100ms, then all of
them would be committed at once. The commtWithin time is a *maximum* time, not
a minimum.

This is identical to how autoCommit works now -- the advantage is that various
documents could require different time bounds.

set a commit time bounds in the add command
-

Key: SOLR-793
URL: https://issues.apache.org/jira/browse/SOLR-793
Project: Solr
Issue Type: Improvement
Components: update
Reporter: Ryan McKinley
Priority: Minor
Attachments: SOLR-793-commitWithin.patch, SOLR-793-commitWithin.patch

Currently there are two options for how to handle commiting documents:
1. the client explicitly starts the commit via commit/
2. set an auto commit value on the server -- clients can assume all documents
will be commited within that time.
However, this does not help in the case where the clients know what documents
need updating quickly and others that could wait. I suggest adding:
{code:xml}
add commitWithin=100...
{/code:xml}
to the update syntax so the client can schedule commits explicitly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-793) set a commit time bounds in the add command


[ 
https://issues.apache.org/jira/browse/SOLR-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637175#action_12637175
 ] 

Ryan McKinley commented on SOLR-793:


bq. I feel somewhat reponsible, being the one who inflicted it on everyone

Hey, I claim equal responsibility :)

 set a commit time bounds in the add command
 -

 Key: SOLR-793
 URL: https://issues.apache.org/jira/browse/SOLR-793
 Project: Solr
  Issue Type: Improvement
  Components: update
Reporter: Ryan McKinley
Priority: Minor
 Attachments: SOLR-793-commitWithin.patch, SOLR-793-commitWithin.patch


 Currently there are two options for how to handle commiting documents:
 1. the client explicitly starts the commit via commit/
 2. set an auto commit value on the server -- clients can assume all documents 
 will be commited within that time.
 However, this does not help in the case where the clients know what documents 
 need updating quickly and others that could wait.  I suggest adding:
 {code:xml}
  add commitWithin=100...
 {/code:xml} 
 to the update syntax so the client can schedule commits explicitly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-802) Trivial bug which could cause null pointer exception


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

Ryan McKinley reassigned SOLR-802:
--

Assignee: Ryan McKinley

 Trivial bug which could cause null pointer exception
 

 Key: SOLR-802
 URL: https://issues.apache.org/jira/browse/SOLR-802
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.3
Reporter: David Bowen
Assignee: Ryan McKinley
Priority: Minor
 Attachments: patch


 In FacetComponent there's an  which should be a .  Patch to follow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r702305 - /lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java

2008-10-06 Thread Ryan McKinley


How do we do CHANGES.txt on the 1.3 branch?

should we change the CHANGES.txt file so the top is for release 1.3.1?

If nothing else, a 1.3.1 release is warranted after the official  
lucene release...


ryan


On Oct 6, 2008, at 7:48 PM, [EMAIL PROTECTED] wrote:


Author: ryan
Date: Mon Oct  6 16:48:29 2008
New Revision: 702305

URL: http://svn.apache.org/viewvc?rev=702305view=rev
Log:
SOLR-802 -- fix  =  in facet component

Modified:
   lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/ 
component/FacetComponent.java


Modified: lucene/solr/branches/branch-1.3/src/java/org/apache/solr/ 
handler/component/FacetComponent.java

URL: 
http://svn.apache.org/viewvc/lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java?rev=702305r1=702304r2=702305view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==
--- lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/ 
component/FacetComponent.java (original)
+++ lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/ 
component/FacetComponent.java Mon Oct  6 16:48:29 2008

@@ -100,7 +100,8 @@
// scalability.
for (ShardRequest sreq : rb.outgoing) {
  if ((sreq.purpose  ShardRequest.PURPOSE_GET_FIELDS)!=0
-   sreq.shards != null  sreq.shards.length==1
+   sreq.shards != null
+   sreq.shards.length==1
   sreq.shards[0].equals(shard))
  {
refine = sreq;

[jira] Resolved: (SOLR-802) Trivial bug which could cause null pointer exception


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

Ryan McKinley resolved SOLR-802.


Resolution: Fixed

fixed in 1.3 (for 1.3.1) and 1.4

thanks David!

 Trivial bug which could cause null pointer exception
 

 Key: SOLR-802
 URL: https://issues.apache.org/jira/browse/SOLR-802
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.3
Reporter: David Bowen
Assignee: Ryan McKinley
Priority: Minor
 Attachments: patch


 In FacetComponent there's an  which should be a .  Patch to follow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r702305 - /lucene/solr/branches/branch-1.3/src/java/org/apache/solr/handler/component/FacetComponent.java

2008-10-06 Thread Ryan McKinley



On Oct 6, 2008, at 8:02 PM, Chris Hostetter wrote:



: How do we do CHANGES.txt on the 1.3 branch?

Add a 1.3.1 section on both the trunk (below 1.4) and the branch, keep
them in sync.

FWIW: The method Doug (i think it was Doug) recommend for dealing with
point releases once upon a time (on Lucene-Java) was to commit all bug
fixed to the trunk, mark the bug fixed in Jira, and if you thought it
warranted a point release indicate that in Jira using the Fix  
Version --
but hold off on commiting anything to the branch until a decisison  
is made
to actually do a point release -- then use search the Fix Version  
for

issues and merge their specific commits onto the branch.

the theory is that merging many things to the branch is easier to do  
at

one time then in individual merges, and you'reless likely to run into
problems if an initial bug fix turned out to have it's own bugs.

Plus you don't waste a lot of work if it turns out the point release  
never

actaully happens.




that makes sense -- and easier to deal with!

For 1.3.1 I think there are already other patches on the branch, so  
best if we continue with that and take the lesson for next time
(if there are not changes, then we should just just revert to the  
tagged branch)


We still need to add the existing changes to CHANGES.txt -- i don't  
have time to dig around now to see what they are, so If you added  
something to 1.3 post release, then go ahead and update CHANGES.txt


ryan

Re: svn commit: r702314 - in /lucene/solr/trunk/client/java/solrj: CHANGES.txt src/org/apache/solr/client/solrj/util/ClientUtils.java

2008-10-06 Thread Ryan McKinley


how about keeping one function, but adding:   Character.whiteSpace( c )?

Do you need the function to also escape whitespace?


On Oct 6, 2008, at 8:36 PM, [EMAIL PROTECTED] wrote:


Author: koji
Date: Mon Oct  6 17:36:49 2008
New Revision: 702314

URL: http://svn.apache.org/viewvc?rev=702314view=rev
Log:
SOLR-794: added escape() method to ClientUtils.

Modified:
   lucene/solr/trunk/client/java/solrj/CHANGES.txt
   lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/ 
solrj/util/ClientUtils.java


Modified: lucene/solr/trunk/client/java/solrj/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/lucene/solr/trunk/client/java/solrj/CHANGES.txt?rev=702314r1=702313r2=702314view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==

--- lucene/solr/trunk/client/java/solrj/CHANGES.txt (original)
+++ lucene/solr/trunk/client/java/solrj/CHANGES.txt Mon Oct  6  
17:36:49 2008

@@ -18,6 +18,8 @@
New Features
--

+ 1. SOLR-794: added escape() method to ClientUtils. (koji)
+
Optimizations
--


Modified: lucene/solr/trunk/client/java/solrj/src/org/apache/solr/ 
client/solrj/util/ClientUtils.java

URL: 
http://svn.apache.org/viewvc/lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/solrj/util/ClientUtils.java?rev=702314r1=702313r2=702314view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==
--- lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/ 
solrj/util/ClientUtils.java (original)
+++ lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/ 
solrj/util/ClientUtils.java Mon Oct  6 17:36:49 2008

@@ -191,15 +191,32 @@
  private static final Pattern escapePattern = Pattern.compile( (\ 
\W) );


  /**
-   * See: http://lucene.apache.org/java/docs/queryparsersyntax.html#Escaping 
 Special Characters

+   * Non-word characters are escaped by a preceding code\/code.
   */
  public static String escapeQueryChars( String input )
  {
Matcher matcher = escapePattern.matcher( input );
return matcher.replaceAll( $1 );
  }
-

+  /**
+   * See: http://lucene.apache.org/java/docs/queryparsersyntax.html#Escaping 
 Special Characters

+   */
+  public static String escape(String s) {
+StringBuffer sb = new StringBuffer();
+for (int i = 0; i  s.length(); i++) {
+  char c = s.charAt(i);
+  // These characters are part of the query syntax and must be  
escaped
+  if (c == '\\' || c == '+' || c == '-' || c == '!' || c == '('  
|| c == ')' || c == ':'
+|| c == '^' || c == '[' || c == ']' || c == '\' || c ==  
'{' || c == '}' || c == '~'

+|| c == '*' || c == '?' || c == '|' || c == '') {
+sb.append('\\');
+  }
+  sb.append(c);
+}
+return sb.toString();
+  }
+
  public static String toQueryString( SolrParams params, boolean  
xml ) {

StringBuilder sb = new StringBuilder(128);
try {

Re: svn commit: r702314 - in /lucene/solr/trunk/client/java/solrj: CHANGES.txt src/org/apache/solr/client/solrj/util/ClientUtils.java

2008-10-06 Thread Ryan McKinley

I agree one is better...  as long as the escape functionality is the  
same, i don't think it matters - adding the Character.isWhitespace()  
should make that true.


i say we change it and add a note in CHANGES.txt -- if there are any  
problems (i can't imagine functional ones) then we can change back.



On Oct 6, 2008, at 11:19 PM, Koji Sekiguchi wrote:

I think keeping one function is good. Why I added the new function  
is because
I just didn't want to change runtime behavior of existing public  
method...


Ryan McKinley wrote:
how about keeping one function, but adding:
Character.whiteSpace( c )?


Do you need the function to also escape whitespace?


On Oct 6, 2008, at 8:36 PM, [EMAIL PROTECTED] wrote:


Author: koji
Date: Mon Oct  6 17:36:49 2008
New Revision: 702314

URL: http://svn.apache.org/viewvc?rev=702314view=rev
Log:
SOLR-794: added escape() method to ClientUtils.

Modified:
  lucene/solr/trunk/client/java/solrj/CHANGES.txt
  lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/ 
solrj/util/ClientUtils.java


Modified: lucene/solr/trunk/client/java/solrj/CHANGES.txt
URL: 
http://svn.apache.org/viewvc/lucene/solr/trunk/client/java/solrj/CHANGES.txt?rev=702314r1=702313r2=702314view=diff
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 


--- lucene/solr/trunk/client/java/solrj/CHANGES.txt (original)
+++ lucene/solr/trunk/client/java/solrj/CHANGES.txt Mon Oct  6  
17:36:49 2008

@@ -18,6 +18,8 @@
New Features
--

+ 1. SOLR-794: added escape() method to ClientUtils. (koji)
+
Optimizations
--


Modified: lucene/solr/trunk/client/java/solrj/src/org/apache/solr/ 
client/solrj/util/ClientUtils.java

URL: 
http://svn.apache.org/viewvc/lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/solrj/util/ClientUtils.java?rev=702314r1=702313r2=702314view=diff
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 

--- lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/ 
solrj/util/ClientUtils.java (original)
+++ lucene/solr/trunk/client/java/solrj/src/org/apache/solr/client/ 
solrj/util/ClientUtils.java Mon Oct  6 17:36:49 2008

@@ -191,15 +191,32 @@
 private static final Pattern escapePattern = Pattern.compile( (\ 
\W) );


 /**
-   * See: http://lucene.apache.org/java/docs/queryparsersyntax.html#Escaping 
 Special Characters

+   * Non-word characters are escaped by a preceding code\/code.
  */
 public static String escapeQueryChars( String input )
 {
   Matcher matcher = escapePattern.matcher( input );
   return matcher.replaceAll( $1 );
 }
-

+  /**
+   * See: http://lucene.apache.org/java/docs/queryparsersyntax.html#Escaping 
 Special Characters

+   */
+  public static String escape(String s) {
+StringBuffer sb = new StringBuffer();
+for (int i = 0; i  s.length(); i++) {
+  char c = s.charAt(i);
+  // These characters are part of the query syntax and must  
be escaped
+  if (c == '\\' || c == '+' || c == '-' || c == '!' || c ==  
'(' || c == ')' || c == ':'
+|| c == '^' || c == '[' || c == ']' || c == '\' || c ==  
'{' || c == '}' || c == '~'

+|| c == '*' || c == '?' || c == '|' || c == '') {
+sb.append('\\');
+  }
+  sb.append(c);
+}
+return sb.toString();
+  }
+
 public static String toQueryString( SolrParams params, boolean  
xml ) {

   StringBuilder sb = new StringBuilder(128);
   try {

[jira] Updated: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields

2008-10-04 Thread Ryan McKinley (JIRA)


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

Ryan McKinley updated SOLR-680:
---

Attachment: SOLR-680.patch

Updating patch to handle faceting statistics.  (with tests)
- I have not tested this in distributed environment, but it *should* work

 StatsComponent - get min, max, sum, qt, avg of number fields
 

 Key: SOLR-680
 URL: https://issues.apache.org/jira/browse/SOLR-680
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Koji Sekiguchi
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-680.patch, SOLR-680.patch, SOLR-680.patch, 
 SOLR-680.patch, SOLR-680.patch, SOLR-680.patch


 StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
 request parameters:
 stats=onstats.field=price
 {code:xml}
 stats
  stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
  /stats_fields
 /stats
 {code}
 WRT stats, the component can output sum and avg, but not sd and var.
 USE CASE:
 StatsComponent can be used to get market price of DocSet e.g. rental 
 housing site, package tour site.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-793) set a commit time bounds in the add command

2008-10-04 Thread Ryan McKinley (JIRA)


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

Ryan McKinley updated SOLR-793:
---

Attachment: SOLR-793-commitWithin.patch

no real change, updating for /trunk

I'd like to commit this soon, but would love for someone with better threading 
chops to look it over first :)

 set a commit time bounds in the add command
 -

 Key: SOLR-793
 URL: https://issues.apache.org/jira/browse/SOLR-793
 Project: Solr
  Issue Type: Improvement
  Components: update
Reporter: Ryan McKinley
Priority: Minor
 Attachments: SOLR-793-commitWithin.patch, SOLR-793-commitWithin.patch


 Currently there are two options for how to handle commiting documents:
 1. the client explicitly starts the commit via commit/
 2. set an auto commit value on the server -- clients can assume all documents 
 will be commited within that time.
 However, this does not help in the case where the clients know what documents 
 need updating quickly and others that could wait.  I suggest adding:
 {code:xml}
  add commitWithin=100...
 {/code:xml} 
 to the update syntax so the client can schedule commits explicitly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: update lucene to 2.4.0

2008-10-03 Thread Ryan McKinley



On Oct 3, 2008, at 10:03 AM, Yonik Seeley wrote:

I've been doing some tests on lucene 2.4.0 w/ solr - everything  
looks good.

I'll update soon unless there are objections.

-Yonik


+1

[jira] Assigned: (SOLR-657) Replace deprecated calls with the non-deprecated equivalents

2008-10-03 Thread Ryan McKinley (JIRA)


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

Ryan McKinley reassigned SOLR-657:
--

Assignee: Ryan McKinley

 Replace deprecated calls with the non-deprecated equivalents
 

 Key: SOLR-657
 URL: https://issues.apache.org/jira/browse/SOLR-657
 Project: Solr
  Issue Type: Task
Affects Versions: 1.3
Reporter: Lars Kotthoff
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-657-impl-depr.patch, SOLR-657.patch, 
 SOLR-657.patch, SOLR-657.patch, SOLR-657.patch, SOLR-657.patch


 There are numerous calls to deprecated constructors and methods in the code 
 base. This includes deprecations from Solr itself, Lucene, and Java.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-657) Replace deprecated calls with the non-deprecated equivalents

2008-10-03 Thread Ryan McKinley (JIRA)


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

Ryan McKinley resolved SOLR-657.


Resolution: Fixed

thanks Lars!

 Replace deprecated calls with the non-deprecated equivalents
 

 Key: SOLR-657
 URL: https://issues.apache.org/jira/browse/SOLR-657
 Project: Solr
  Issue Type: Task
Affects Versions: 1.3
Reporter: Lars Kotthoff
Assignee: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-657-impl-depr.patch, SOLR-657.patch, 
 SOLR-657.patch, SOLR-657.patch, SOLR-657.patch, SOLR-657.patch


 There are numerous calls to deprecated constructors and methods in the code 
 base. This includes deprecations from Solr itself, Lucene, and Java.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: LogoContest Process Timeline ... was: Re: [Solr Wiki] Update of LogoContest by HossMan

2008-10-03 Thread Ryan McKinley



On Oct 3, 2008, at 3:47 PM, Lukáš Vlček wrote:


Hi,

After reading the LogoContest rules again I am trying to figure if  
there are

any valid submitions in SOLR-84 right now...



correct -- none are valid submissions


1) None of current submitions in SOLR-84 contain Apache word.2) As  
long as
Solr shold not be spelled in all capitals (SOLR) this could wipe out  
some of

current submitions as well.

Is violation of any of above mentioned rules a reason for exclusion  
of logo

design from entering the voting pool?



correct -- we will only vote on the valid ones.  Before the 20th,  
we'll make it clear what ones will be voted on so that everyone who  
cares can make sure things are in order.


ryan

QueryParsing using SolrCore.getSolrCore()

2008-10-03 Thread Ryan McKinley

I'm trying to make a non-deprecated branch and ran into something a  
little funny..


QueryParsing uses access to SolrCore.getSolrCore() -- this will break  
in a multi-core environment.


  public static FunctionQuery parseFunction(String func, IndexSchema  
schema) throws ParseException {

SolrCore core = SolrCore.getSolrCore();
return (FunctionQuery)(QParser.getParser(func,func,new  
LocalSolrQueryRequest(core,new HashMap())).parse());
// return new FunctionQuery(parseValSource(new StrParser(func),  
schema));

  }


I'm not familiar enough with the query parsing stuff to figure how to  
un-tangle it.  As it, it will just use the query parser from the first  
core it finds (regardless of which core it is called from)


ryan

Re: EmbeddedSolrServer API usage

2008-10-02 Thread Ryan McKinley

You could also use the CoreContainer to create a Core from the  
descriptor:


CoreContainer container = new CoreContainer();
CoreDescriptor descriptor = new CoreDescriptor(container,
core1, /Users/erik/apache-solr-1.3.0/example/solr);
SolrCore core = container.create( descriptor );

if you are using a custom solrconfig name, you would need to call  
setConfigName( path ) on the descriptor.


As for closing...  have you tried core.close()?

ryan


On Oct 2, 2008, at 8:49 AM, Erik Hatcher wrote:

I'm doing some Java experiments to get ready for a solr-ruby  
overhaul such that JRuby comes into play nicely so that  
EmbeddedSolrServer can be used transparently too.  I've not tried  
this since the whole CoreContainer/CoreDescriptor stuff was added,  
and I don't quite understand it all.  Here's what I've got:


 public static void main(String[] args) throws IOException,  
ParserConfigurationException, SAXException, SolrServerException {

   CoreContainer container = new CoreContainer();
   SolrConfig config = new SolrConfig(/Users/erik/apache-solr-1.3.0/ 
example/solr, solrconfig.xml, null);
   CoreDescriptor descriptor = new CoreDescriptor(container,  
core1, /Users/erik/apache-solr-1.3.0/example/solr);
   SolrCore core = new SolrCore(core1, /Users/erik/apache- 
solr-1.3.0/example/solr/data, config, null, descriptor);

   container.register(core1, core, false);
   SolrServer solr = new EmbeddedSolrServer(container, core1);
   SolrQuery query = new SolrQuery(*:*);
   QueryResponse response = solr.query(query);
   System.out.println(response =  + response);
 }

This works, but has a fair bit of seemingly unnecessary duplication,  
and it also leaves the JVM stays running for some reason.


Is this the proper way to use EmbeddedSolrServer, or are there some  
tips to improving the code and reducing the duplication?


Also, why does the JVM keep running?  Are we spinning off a thread  
that needs to be shut down?  Is there some sort of close() call that  
is needed?


Thanks,
Erik

[jira] Resolved: (SOLR-796) remove unused SolrIndexSearcher from DUH2

2008-10-02 Thread Ryan McKinley (JIRA)


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

Ryan McKinley resolved SOLR-796.


Resolution: Fixed

 remove unused SolrIndexSearcher from DUH2
 -

 Key: SOLR-796
 URL: https://issues.apache.org/jira/browse/SOLR-796
 Project: Solr
  Issue Type: Improvement
  Components: update
Reporter: Ryan McKinley
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-796-remove-searcher.patch


 Since the DUH2 does not use the searcher for deletes anymore, it does not 
 need to be able to...
 Check: http://www.nabble.com/Fwd%3A-read-only-SolrCore--td19769173.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: What is a Standard SearchComponent? (SOLR-680)

2008-10-02 Thread Ryan McKinley



On Oct 1, 2008, at 5:33 PM, Ryan McKinley wrote:
I disagree with Erik that we should have people explicitly  
configure the components.


Folks don't have to explicitly configure them, if they are just  
running with the example configuration - which is more likely than  
not.


Oh, another thing about search components, I don't like the first/ 
last thing - I like it to be explicit, less magic.


As for component registration precedence, it is the configured  
Component that has precedence.  The Component initialization code  
only adds the default Component if that name is not already used.   
Registering your own spellcheck Component will use your component.


Right, but what if someone has a stats component now in 1.3 wired  
into a custom request handler (but not /select), then upgrades to  
1.4 with the new implicit stats built-in - then all of a sudden a  
request to /select will use _their_ stats component, not the built  
in one.  Right?



Ok, I see you point...  since we are past 1.3, this may a moot point,  
but how about something like:


* SearchHandler has no components registered and must be configured  
manually.
* StandardRequestHandler (currently nothing more then extends  
SearchHandler) would register all components with no dependancies - it  
would not support things like first/last components.


Users extending SearchHandler would have absolute control -- users  
extending StandardRequestHandler would have standard configuration -  
features may be added between major releases, but not removed.


ryan

Re: EmbeddedSolrServer API usage

2008-10-02 Thread Ryan McKinley



On Oct 2, 2008, at 1:58 PM, Erik Hatcher wrote:


Thanks Ryan - good tips, and core.close() was the missing piece, duh.

Here's how it looks in JRuby:

 container = CoreContainer.new
 descriptor = CoreDescriptor.new(container, core1, /Users/erik/ 
apache-solr-1.3.0/example/solr)

 core = container.create(descriptor)
 container.register(core1, core, false)

 solr = EmbeddedSolrServer.new(container, core1)
 query = SolrQuery.new(*:*)
 response = solr.query(query)
 puts response
 core.close

Perhaps there should be an overloaded CoreContainer#register(core)  
that uses the name from the core descriptor so core1 doesn't have  
to be duplicated?




+1


  public SolrCore register(SolrCore core, boolean returnPrev) {
return register( core.getName(), core, returnPrev );
  }

solr 2.0 branch/sandbox?

2008-10-02 Thread Ryan McKinley


Hey-

Rather then continually point to solr 2.0 as a future future thing,  
i'd like to give a go at removing all configs and deprecated stuff. --  
I doubt that would end up being the real direction, but as an exercise  
would be quite valuable to figure out what the major issues will be  
and see how it feels.


What do you think the best way to do this is?

How do you feel if I make a branch to experiment with stripping all  
configs out of solr


perhaps:
http://svn.apache.org/repos/asf/lucene/solr/branches/sandbox/
or
http://svn.apache.org/repos/asf/lucene/solr/branches/sandbox/ryan/

thoughts?
ryan

[jira] Commented: (SOLR-794) ClientUtils.escapeQueryChars escapes chars a bit aggressive

2008-10-01 Thread Ryan McKinley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636084#action_12636084
 ] 

Ryan McKinley commented on SOLR-794:


but this has one BIG functional change...

since we are not escaping whitespace, now stuff passed to escaper has to escape 
it explicitly.

that is, before, I could pass in the name David Bowie  and know that that 
would be the Term.  With these changes, I would have to pass in \David 
Bowie\

perhaps we add ifWhitespace() then \char






 ClientUtils.escapeQueryChars escapes chars a bit aggressive
 ---

 Key: SOLR-794
 URL: https://issues.apache.org/jira/browse/SOLR-794
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 1.3
Reporter: Koji Sekiguchi
Priority: Trivial
 Fix For: 1.3.1, 1.4

 Attachments: SOLR-794.patch


 This was talked before at:
 http://www.nabble.com/ClientUtils-escape-query-td18833559.html
 I didn't notice it at that time though.
 This method outputs weird string when Japanese letters are given for example. 
 J1J2J3J4J5 = \J1\J2\J3\J4\J5 We don't want to see it.
 It should use QueryParser.escape() code as it says in javadoc.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Fwd: read-only SolrCore?

2008-10-01 Thread Ryan McKinley

Something funny is going on with my mail...  It seems everything I
have sent is disappearing...  hopefully this will make it.

-- Forwarded message --
From: Ryan McKinley [EMAIL PROTECTED]
Date: Wed, Oct 1, 2008 at 4:21 PM
Subject: read-only SolrCore?
To: solr-dev@lucene.apache.org

From the lucene 2.4 draft announcement...

 * IndexReader can be opened with new readOnly=true mode, which gives
   better performance in a multi-threaded environment.

I don't normally delve into lucene innards, so this may already be addressed.
Would it be worthwhile adding a 'readonly' mode for slave servers?  We
have discussed this before, but usually end up saying just don't send
any updates or run as a user who cant write the index...
But if there is a performance win to opening in read-only, i think it
is worth while.  Setting the SolrCore to read only would also throw an
error in the UpdateHandler if you try to update something...  (rather
then just commmit/ to reopen the index -- language that has never
really made sense)

It looks like we have access to the read only searcher, but never call
it.  From SolrCore.java:
  // gets a non-caching searcher
  public SolrIndexSearcher newSearcher(String name) throws IOException {
return newSearcher(name, false);
  }

  // gets a non-caching searcher
  public SolrIndexSearcher newSearcher(String name, boolean readOnly)
throws IOException {
return new SolrIndexSearcher(this, schema, main,
IndexReader.open(FSDirectory.getDirectory(getIndexDir()), readOnly),
true, false);
  }

thoughts?
ryan

Re: What is a Standard SearchComponent? (SOLR-680)

2008-10-01 Thread Ryan McKinley

The reason I thought StatsComponent is default while SpellCheck is  
not is that SpellChecking necessarily requires some configuration.   
Stats can be there without doing anything -- it is just the cost of  
checking if stats=true in the request.


I suggest that we add *all* Components that are generally useful off  
the shelf to the StandardRequestHandler.  We should add documentation  
to say: if you know exactly what features you need, you should  
configure the RequestHandler to use only those features.  The  
SearchHandler should not register any components by default.


I disagree with Erik that we should have people explicitly configure  
the components.


As for component registration precedence, it is the configured  
Component that has precedence.  The Component initialization code only  
adds the default Component if that name is not already used.   
Registering your own spellcheck Component will use your component.


ryan


On Oct 1, 2008, at 4:28 PM, Grant Ingersoll wrote:

SOLR-680 proposes to add StatsComponent to the set of standard  
search components.  Initially, the SpellCheckComponent did this as  
well.  At the time, I thought we shouldn't add them to the standard  
set, but clearly others think differently.


So, I think we should have a discussion of the merits of doing so,  
and try to come to some type of understanding of when something  
should be standard and when it should be optional.  I suspect, the  
answer is Erik's It depends, but let's discuss.


On the plus side, people get the new functionality without having to  
configure anything.  On the negative, it adds one or more if clauses  
(to see if the component is on) per query per added component.   
Not necessarily a big deal, but it is a few extra instructions that  
weren't being executed before...
It also, theoretically, could cause a name clash with an existing  
component that someone developed on their own.  For instance, if I  
had my own spellcheck Component, and then all of a sudden Solr put  
in a new one by default, what would that mean?  Would it be obvious  
to me which one is being used? Is that back-compatible?


My inclination is to err on not including them by default, yet I do  
think there are things that are highly valuable by default, and part  
of our job as developers is to provide a good out of the box  
experience.  And, to me, part of that is having to do as little  
configuration as possible.


Thoughts?


-Grant

Re: read-only SolrCore?

2008-10-01 Thread Ryan McKinley




It looks like we have access to the read only searcher, but never  
call

it.  From SolrCore.java:
// gets a non-caching searcher
public SolrIndexSearcher newSearcher(String name) throws  
IOException {

  return newSearcher(name, false);
}


This call was only used by the update handler to do get a searcher to
do deletions... but we no longer do that (DUH2.openSearcher() is no
longer called).  So I think everything should be read-only.

-Yonik


so can remove the indexSearcher from DUH2?

I just tried it, and the tests still pass.  It removes two protected  
functions:

openSearcher(); // never called
closeSearcher();  // called a lot


ryan

[jira] Created: (SOLR-796) remove unused SolrIndexSearcher from DUH2

2008-10-01 Thread Ryan McKinley (JIRA)

remove unused SolrIndexSearcher from DUH2
-

 Key: SOLR-796
 URL: https://issues.apache.org/jira/browse/SOLR-796
 Project: Solr
  Issue Type: Improvement
  Components: update
Reporter: Ryan McKinley
Priority: Minor
 Fix For: 1.4


Since the DUH2 does not use the searcher for deletes anymore, it does not need 
to be able to...

Check: http://www.nabble.com/Fwd%3A-read-only-SolrCore--td19769173.html

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields

2008-09-30 Thread Ryan McKinley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635758#action_12635758
 ] 

Ryan McKinley commented on SOLR-680:


good catch -- that would even work in distributed mode!

However, median still requires a second pass.  (unless you assume there are no 
null values)
If we do a second pass, we could also calculate Q1 and Q3 (1st and 3rd quarter 
deviation) -- JFreeChart has a nice program to graph that  :)

 StatsComponent - get min, max, sum, qt, avg of number fields
 

 Key: SOLR-680
 URL: https://issues.apache.org/jira/browse/SOLR-680
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Koji Sekiguchi
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-680.patch, SOLR-680.patch, SOLR-680.patch, 
 SOLR-680.patch


 StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
 request parameters:
 stats=onstats.field=price
 {code:xml}
 stats
  stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
  /stats_fields
 /stats
 {code}
 WRT stats, the component can output sum and avg, but not sd and var.
 USE CASE:
 StatsComponent can be used to get market price of DocSet e.g. rental 
 housing site, package tour site.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields

2008-09-30 Thread Ryan McKinley (JIRA)

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

Ryan McKinley updated SOLR-680:
---

Attachment: SOLR-680.patch

updated:
* calculate stddev in first pass -- and works distributed (thanks Sean!)
* throws a full error when asking for a bad field -- this seems better then
catching it and adding it to the response.
* changed param stddev to twopass -- now it is a flag to calculate things
that require a 2nd pass through the data. Currently only median

I'd like to commit this soon...

StatsComponent - get min, max, sum, qt, avg of number fields

Key: SOLR-680
URL: https://issues.apache.org/jira/browse/SOLR-680
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Koji Sekiguchi
Priority: Minor
Fix For: 1.4

Attachments: SOLR-680.patch, SOLR-680.patch, SOLR-680.patch,
SOLR-680.patch, SOLR-680.patch

StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
request parameters:
stats=onstats.field=price
{code:xml}
stats
stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
/stats_fields
/stats
{code}
WRT stats, the component can output sum and avg, but not sd and var.
USE CASE:
StatsComponent can be used to get market price of DocSet e.g. rental
housing site, package tour site.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields


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

Ryan McKinley updated SOLR-680:
---

Attachment: SOLR-680.patch

Koji -- this looks great!

I just updated the patch so it:
 - handles null values better (skips them, but counts them)
 - adds missing=number of null values for the field to the stats
 - throws an error if you try stats on a tokenized or multivalue field
 - registers the StatsComponet by default
 - optionally calculates median value and standard deviation (requires a second 
pass through the field cache)
 NOTE -- this will break in distributed context...  i'm not sure there is a 
fix for that...  we could return a weighted average?  perhaps a better result 
would be to return the raw values for each shard?

I'll upload this now, and start working on solrj integration with tests...

 StatsComponent - get min, max, sum, qt, avg of number fields
 

 Key: SOLR-680
 URL: https://issues.apache.org/jira/browse/SOLR-680
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Koji Sekiguchi
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-680.patch, SOLR-680.patch


 StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
 request parameters:
 stats=onstats.field=price
 {code:xml}
 stats
  stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
  /stats_fields
 /stats
 {code}
 WRT stats, the component can output sum and avg, but not sd and var.
 USE CASE:
 StatsComponent can be used to get market price of DocSet e.g. rental 
 housing site, package tour site.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields


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

Ryan McKinley updated SOLR-680:
---

Attachment: SOLR-680.patch

updated patch:





with the sample data:
http://localhost:8983/solr/select?q=*:*stats=truestats.field=pricestats.field=popularitystats.stddev=truerows=0
returns
{code:xml}
lst name=stats
  lst name=stats_fields
lst name=price
double name=min0.0/double
double name=max2199.0/double
double name=sum5251.26995/double
long name=qt15/long
long name=missing11/long
double name=mean350.084664/double
double name=median399.0/double
double name=stddev547.7375579061129/double
   /lst
   lst name=popularity
double name=min0.0/double
double name=max10.0/double
double name=sum90.0/double
long name=qt26/long
long name=missing0/long
double name=mean3.4615384615384617/double
double name=median7.0/double
double name=stddev3.557873176275616/double
   /lst
/lst
/lst

{code}

 StatsComponent - get min, max, sum, qt, avg of number fields
 

 Key: SOLR-680
 URL: https://issues.apache.org/jira/browse/SOLR-680
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Koji Sekiguchi
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-680.patch, SOLR-680.patch, SOLR-680.patch


 StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
 request parameters:
 stats=onstats.field=price
 {code:xml}
 stats
  stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
  /stats_fields
 /stats
 {code}
 WRT stats, the component can output sum and avg, but not sd and var.
 USE CASE:
 StatsComponent can be used to get market price of DocSet e.g. rental 
 housing site, package tour site.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields


[ 
https://issues.apache.org/jira/browse/SOLR-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635653#action_12635653
 ] 

ryantxu edited comment on SOLR-680 at 9/29/08 9:48 PM:
-

updated patch:

with the sample data:
http://localhost:8983/solr/select?q=*:*stats=truestats.field=pricestats.field=popularitystats.stddev=truerows=0
returns
{code:xml}
lst name=stats
  lst name=stats_fields
lst name=price
double name=min0.0/double
double name=max2199.0/double
double name=sum5251.26995/double
long name=qt15/long
long name=missing11/long
double name=mean350.084664/double
double name=median399.0/double
double name=stddev547.7375579061129/double
   /lst
   lst name=popularity
double name=min0.0/double
double name=max10.0/double
double name=sum90.0/double
long name=qt26/long
long name=missing0/long
double name=mean3.4615384615384617/double
double name=median7.0/double
double name=stddev3.557873176275616/double
   /lst
/lst
/lst
{code}

Changes:
 - changed qt to count
 - changed ave to mean  (so it sits nicely with median)
 - added stats support to solrj
 - added test to example jetty/embedded runners

now it just needs a little documentaion, then i think ready to go...


  was (Author: ryantxu):
updated patch:





with the sample data:
http://localhost:8983/solr/select?q=*:*stats=truestats.field=pricestats.field=popularitystats.stddev=truerows=0
returns
{code:xml}
lst name=stats
  lst name=stats_fields
lst name=price
double name=min0.0/double
double name=max2199.0/double
double name=sum5251.26995/double
long name=qt15/long
long name=missing11/long
double name=mean350.084664/double
double name=median399.0/double
double name=stddev547.7375579061129/double
   /lst
   lst name=popularity
double name=min0.0/double
double name=max10.0/double
double name=sum90.0/double
long name=qt26/long
long name=missing0/long
double name=mean3.4615384615384617/double
double name=median7.0/double
double name=stddev3.557873176275616/double
   /lst
/lst
/lst

{code}
  
 StatsComponent - get min, max, sum, qt, avg of number fields
 

 Key: SOLR-680
 URL: https://issues.apache.org/jira/browse/SOLR-680
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Koji Sekiguchi
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-680.patch, SOLR-680.patch, SOLR-680.patch


 StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
 request parameters:
 stats=onstats.field=price
 {code:xml}
 stats
  stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
  /stats_fields
 /stats
 {code}
 WRT stats, the component can output sum and avg, but not sd and var.
 USE CASE:
 StatsComponent can be used to get market price of DocSet e.g. rental 
 housing site, package tour site.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields


[ 
https://issues.apache.org/jira/browse/SOLR-680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12635653#action_12635653
 ] 

ryantxu edited comment on SOLR-680 at 9/29/08 9:49 PM:
-

updated patch:

with the sample data:
http://localhost:8983/solr/select?q=*:*stats=truestats.field=pricestats.field=popularitystats.stddev=truerows=0
returns
{code:xml}
lst name=stats
  lst name=stats_fields
lst name=price
double name=min0.0/double
double name=max2199.0/double
double name=sum5251.26995/double
long name=count15/long
long name=missing11/long
double name=mean350.084664/double
double name=median399.0/double
double name=stddev547.7375579061129/double
   /lst
   lst name=popularity
double name=min0.0/double
double name=max10.0/double
double name=sum90.0/double
long name=count26/long
long name=missing0/long
double name=mean3.4615384615384617/double
double name=median7.0/double
double name=stddev3.557873176275616/double
   /lst
/lst
/lst
{code}

Changes:
 - changed qt to count
 - changed ave to mean  (so it sits nicely with median)
 - added stats support to solrj
 - added test to example jetty/embedded runners

now it just needs a little documentaion, then i think ready to go...


  was (Author: ryantxu):
updated patch:

with the sample data:
http://localhost:8983/solr/select?q=*:*stats=truestats.field=pricestats.field=popularitystats.stddev=truerows=0
returns
{code:xml}
lst name=stats
  lst name=stats_fields
lst name=price
double name=min0.0/double
double name=max2199.0/double
double name=sum5251.26995/double
long name=qt15/long
long name=missing11/long
double name=mean350.084664/double
double name=median399.0/double
double name=stddev547.7375579061129/double
   /lst
   lst name=popularity
double name=min0.0/double
double name=max10.0/double
double name=sum90.0/double
long name=qt26/long
long name=missing0/long
double name=mean3.4615384615384617/double
double name=median7.0/double
double name=stddev3.557873176275616/double
   /lst
/lst
/lst
{code}

Changes:
 - changed qt to count
 - changed ave to mean  (so it sits nicely with median)
 - added stats support to solrj
 - added test to example jetty/embedded runners

now it just needs a little documentaion, then i think ready to go...

  
 StatsComponent - get min, max, sum, qt, avg of number fields
 

 Key: SOLR-680
 URL: https://issues.apache.org/jira/browse/SOLR-680
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Koji Sekiguchi
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-680.patch, SOLR-680.patch, SOLR-680.patch


 StatsComponent - it returns min,max,sum,qt,avg of specified number fields:
 request parameters:
 stats=onstats.field=price
 {code:xml}
 stats
  stats_fields
lst name=price
double name=min10/double
double name=max30/double
double name=avg20/double
double name=sum60/double
double name=qt3/double
/lst
  /stats_fields
 /stats
 {code}
 WRT stats, the component can output sum and avg, but not sd and var.
 USE CASE:
 StatsComponent can be used to get market price of DocSet e.g. rental 
 housing site, package tour site.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-680) StatsComponent - get min, max, sum, qt, avg of number fields