date:20091215


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

Noble Paul updated SOLR-773:


Comment: was deleted

(was: Sorry for the last Post. I feel like a newbie (which I am) and regret 
being on holidays ;-)! Can anybody delete it (I didn't find a way...)?)

 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, 
 lucene.tar.gz, screenshot-1.jpg, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-spatial_solr.patch, SOLR-773.patch, SOLR-773.patch, 
 solrGeoQuery.tar, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

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

[jira] Updated: (SOLR-773) Incorporate Local Lucene/Solr


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

Noble Paul updated SOLR-773:


Comment: was deleted

(was: Bonjour,
Je suis absent jusqu'au 4 janvier prochain, mais répondrai au plus vite à votre 
message dès mon retour.
Cordiales salutations,
Benoît Terradillos
)

 Incorporate Local Lucene/Solr
 -

 Key: SOLR-773
 URL: https://issues.apache.org/jira/browse/SOLR-773
 Project: Solr
  Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 1.5

 Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, 
 lucene.tar.gz, screenshot-1.jpg, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, 
 SOLR-773-spatial_solr.patch, SOLR-773.patch, SOLR-773.patch, 
 solrGeoQuery.tar, spatial-solr.tar.gz


 Local Lucene has been donated to the Lucene project.  It has some Solr 
 components, but we should evaluate how best to incorporate it into Solr.
 See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene

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

[jira] Commented: (SOLR-17) XSD for solr requests/responses


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

Shalin Shekhar Mangar commented on SOLR-17:
---

This is like a solution looking for a problem.

 XSD for solr requests/responses
 ---

 Key: SOLR-17
 URL: https://issues.apache.org/jira/browse/SOLR-17
 Project: Solr
  Issue Type: Improvement
Reporter: Mike Baranczak
Priority: Minor
 Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd, 
 UselessRequestHandler.java


 Attaching an XML schema definition for the responses and the update requests. 
 I needed to do this for myself anyway, so I might as well contribute it to 
 the project.
 At the moment, I have no plans to write an XSD for the config documents, but 
 it wouldn't be a bad idea.
 TODO: change the schema URL. I'm guessing that Apache already has some sort 
 of naming convention for these?

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

[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields


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

Noble Paul commented on SOLR-1131:
--

in FieldType#createFields(SchemaField field, FieldType delegatedType, String 
storageVal, boost, String ... externalVals)
{code:java}
String name = field.getName();
  MapString, String props = new HashMapString, String();
  //Just set these, delegate everything else to the field type
  props.put(indexed, true);
  props.put(stored, false);
  //props.put(omitNorms, true);
  //props.put(tokenized, false);
  if (field.indexed()) {

for (int j = 0; j  externalVals.length; j++) {
  //SchemaField is final, as is name, so we need to recreate each time
  //put the counter before the separator, b/c dynamic fields can't be 
asterisks on both the front and the end of the String
  SchemaField sf = SchemaField.create(name  + _ + j + 
POLY_FIELD_SEPARATOR + delegatedType.typeName, delegatedType, props);
  //QUESTION: should we allow for vectors, etc?  Not sure that it makes 
sense
  results[j] = delegatedType.createField(sf, externalVals[j], boost);
}
  }
{code}

It is not clear as to why can't the 'sf' instance be cached and reused? 

Why do we have a map for flags why not use a bitset?

 Allow a single field type to index multiple fields
 --

 Key: SOLR-1131
 URL: https://issues.apache.org/jira/browse/SOLR-1131
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Reporter: Ryan McKinley
Assignee: Grant Ingersoll
 Fix For: 1.5

 Attachments: SOLR-1131-IndexMultipleFields.patch, 
 SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch


 In a few special cases, it makes sense for a single field (the concept) to 
 be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
 concept point may be best indexed in a variety of ways:
  * geohash (sincle lucene field)
  * lat field, lon field (two double fields)
  * cartesian tiers (a series of fields with tokens to say if it exists within 
 that region)

-- 
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-1131) Allow a single field type to index multiple fields


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

Noble Paul edited comment on SOLR-1131 at 12/15/09 10:06 AM:
-

in FieldType#createFields(SchemaField field, FieldType delegatedType, String 
storageVal, boost, String ... externalVals)
{code:java}
String name = field.getName();
  MapString, String props = new HashMapString, String();
  //Just set these, delegate everything else to the field type
  props.put(indexed, true);
  props.put(stored, false);
  //props.put(omitNorms, true);
  //props.put(tokenized, false);
  if (field.indexed()) {

for (int j = 0; j  externalVals.length; j++) {
  //SchemaField is final, as is name, so we need to recreate each time
  //put the counter before the separator, b/c dynamic fields can't be 
asterisks on both the front and the end of the String
  SchemaField sf = SchemaField.create(name  + _ + j + 
POLY_FIELD_SEPARATOR + delegatedType.typeName, delegatedType, props);
  //QUESTION: should we allow for vectors, etc?  Not sure that it makes 
sense
  results[j] = delegatedType.createField(sf, externalVals[j], boost);
}
  }
{code}

It is not clear as to why can't the 'sf' instance be cached and reused? 

 we can also  avoid creating the synthetic field name at query time in 
PointField#.getFieldQuery


Why do we have a map for flags why not use a bitset?

  was (Author: noble.paul):
in FieldType#createFields(SchemaField field, FieldType delegatedType, 
String storageVal, boost, String ... externalVals)
{code:java}
String name = field.getName();
  MapString, String props = new HashMapString, String();
  //Just set these, delegate everything else to the field type
  props.put(indexed, true);
  props.put(stored, false);
  //props.put(omitNorms, true);
  //props.put(tokenized, false);
  if (field.indexed()) {

for (int j = 0; j  externalVals.length; j++) {
  //SchemaField is final, as is name, so we need to recreate each time
  //put the counter before the separator, b/c dynamic fields can't be 
asterisks on both the front and the end of the String
  SchemaField sf = SchemaField.create(name  + _ + j + 
POLY_FIELD_SEPARATOR + delegatedType.typeName, delegatedType, props);
  //QUESTION: should we allow for vectors, etc?  Not sure that it makes 
sense
  results[j] = delegatedType.createField(sf, externalVals[j], boost);
}
  }
{code}

It is not clear as to why can't the 'sf' instance be cached and reused? 

Why do we have a map for flags why not use a bitset?
  
 Allow a single field type to index multiple fields
 --

 Key: SOLR-1131
 URL: https://issues.apache.org/jira/browse/SOLR-1131
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Reporter: Ryan McKinley
Assignee: Grant Ingersoll
 Fix For: 1.5

 Attachments: SOLR-1131-IndexMultipleFields.patch, 
 SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch


 In a few special cases, it makes sense for a single field (the concept) to 
 be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
 concept point may be best indexed in a variety of ways:
  * geohash (sincle lucene field)
  * lat field, lon field (two double fields)
  * cartesian tiers (a series of fields with tokens to say if it exists within 
 that region)

-- 
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-1006) ConcurrentLRUCache API improvements


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

Shalin Shekhar Mangar edited comment on SOLR-1006 at 12/15/09 10:18 AM:


I don't have a use-case for this anymore. Let us close this issue.

  was (Author: shalinmangar):
I don't have a a use-case for this anymore. Let us close this issue.
  
 ConcurrentLRUCache API improvements
 ---

 Key: SOLR-1006
 URL: https://issues.apache.org/jira/browse/SOLR-1006
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-1006.patch, SOLR-1006.patch


 This is to make ConcurrentLRUCache more consistent with LinkedHashMap behavior
 # remove must not call evictionListener.evictedEntry()
 # -EvictionListener must be able prevent eviction of an element by returning 
 a false.-
 # Add a new method Map getOldestItems(long n)

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

[jira] Updated: (SOLR-1006) ConcurrentLRUCache API improvements


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

Shalin Shekhar Mangar updated SOLR-1006:


Description: 
This is to make ConcurrentLRUCache more consistent with LinkedHashMap behavior

# remove must not call evictionListener.evictedEntry()
# -EvictionListener must be able prevent eviction of an element by returning a 
false.-
# Add a new method Map getOldestItems(long n)

  was:
This is to make ConcurrentLRUCache more consistent with LinkedHashMap behavior

# remove must not call evictionListener.evictedEntry()
# EvictionListener must be able prevent eviction of an element by returning a 
false.
# Add a new method Map getOldestItems(long n)


I don't have a a use-case for this anymore. Let us close this issue.

 ConcurrentLRUCache API improvements
 ---

 Key: SOLR-1006
 URL: https://issues.apache.org/jira/browse/SOLR-1006
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-1006.patch, SOLR-1006.patch


 This is to make ConcurrentLRUCache more consistent with LinkedHashMap behavior
 # remove must not call evictionListener.evictedEntry()
 # -EvictionListener must be able prevent eviction of an element by returning 
 a false.-
 # Add a new method Map getOldestItems(long n)

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

[jira] Closed: (SOLR-1006) ConcurrentLRUCache API improvements


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

Shalin Shekhar Mangar closed SOLR-1006.
---

   Resolution: Fixed
Fix Version/s: (was: 1.5)
   1.4

 ConcurrentLRUCache API improvements
 ---

 Key: SOLR-1006
 URL: https://issues.apache.org/jira/browse/SOLR-1006
 Project: Solr
  Issue Type: Improvement
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 1.4

 Attachments: SOLR-1006.patch, SOLR-1006.patch


 This is to make ConcurrentLRUCache more consistent with LinkedHashMap behavior
 # remove must not call evictionListener.evictedEntry()
 # -EvictionListener must be able prevent eviction of an element by returning 
 a false.-
 # Add a new method Map getOldestItems(long n)

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

[jira] Updated: (SOLR-1645) Add human content-type


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

Shalin Shekhar Mangar updated SOLR-1645:


Fix Version/s: (was: 1.4)
   1.5

1.4 has been released. Marking for 1.5 instead.

 Add human content-type
 --

 Key: SOLR-1645
 URL: https://issues.apache.org/jira/browse/SOLR-1645
 Project: Solr
  Issue Type: Improvement
  Components: contrib - Solr Cell (Tika extraction)
Affects Versions: 1.4
Reporter: Khalid Yagoubi
 Fix For: 1.5


 Idea is to allow Solr-Cell to calculate the human content-type from the 
 extracted content-type and map it to a field in the schema. 
 So the user can search on media: image or media:video
 Idea :
 1) Hardcode a hashmap in somewhere in extraction classes and get human 
 content-type from extracted content-type. I Think to SolrContentHandler.java
 2) Write an xml file where we can put a mapping like in tika-config.xml for 
 parsers
 3) Use tika-config.xml to get all supported mime-types

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

[jira] Commented: (SOLR-1212) TestNG Test Case


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

Shalin Shekhar Mangar commented on SOLR-1212:
-

I'm not sure what to do with this. We don't need to ship this with our 
releases. Perhaps it is best to mark this as Won't Fix and link this issue to 
http://wiki.apache.org/solr/TestingSolr so that people who use TestNG can use 
this code if necessary.

 TestNG Test Case 
 -

 Key: SOLR-1212
 URL: https://issues.apache.org/jira/browse/SOLR-1212
 Project: Solr
  Issue Type: New Feature
  Components: clients - java
Affects Versions: 1.4
 Environment: Java 6
Reporter: Kay Kay
 Fix For: 1.5

 Attachments: SOLR-1212.patch, testng-5.9-jdk15.jar

   Original Estimate: 1h
  Remaining Estimate: 1h

 TestNG equivalent of AbstractSolrTestCase , without using JUnit altogether . 
 New Class created: AbstractSolrNGTest 
 LICENSE.txt , NOTICE.txt modified as appropriate. ( TestNG under Apache 
 License 2.0 ) 
 TestNG 5.9-jdk15 added to lib. 
 Justification:  In some workplaces - people are moving towards TestNG and 
 take out JUnit altogether from the classpath. Hence useful in those cases.

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

[jira] Updated: (SOLR-1654) Add TikaEntityProcessor example to the DIHExample

2009-12-15 Thread Akshay K. Ukey (JIRA)


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

Akshay K. Ukey updated SOLR-1654:
-

Attachment: SOLR-1654.patch

Patch with slight change in the tika example solrconfig.xml and 
tika-data-config.xml

 Add TikaEntityProcessor example to the DIHExample
 -

 Key: SOLR-1654
 URL: https://issues.apache.org/jira/browse/SOLR-1654
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Affects Versions: 1.4
Reporter: Akshay K. Ukey
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1654.patch, SOLR-1654.patch


 As part of ant example a sample tika setup should be generated.

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

[jira] Resolved: (SOLR-1654) Add TikaEntityProcessor example to the DIHExample


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

Noble Paul resolved SOLR-1654.
--

Resolution: Fixed
  Assignee: Noble Paul

committed r890761
Thanks Akshay

 Add TikaEntityProcessor example to the DIHExample
 -

 Key: SOLR-1654
 URL: https://issues.apache.org/jira/browse/SOLR-1654
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Affects Versions: 1.4
Reporter: Akshay K. Ukey
Assignee: Noble Paul
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1654.patch, SOLR-1654.patch


 As part of ant example a sample tika setup should be generated.

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

[jira] Resolved: (SOLR-630) Spellchecker should not be case-sensitive and should be stopwords-aware


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

Shalin Shekhar Mangar resolved SOLR-630.


Resolution: Invalid

I don't think this is a problem. As Alex noted, it is all a matter of 
configuring your analyzers and spell checker correctly.

 Spellchecker should not be case-sensitive and should be stopwords-aware
 ---

 Key: SOLR-630
 URL: https://issues.apache.org/jira/browse/SOLR-630
 Project: Solr
  Issue Type: Bug
  Components: spellchecker
Reporter: Otis Gospodnetic
Priority: Minor
 Fix For: 1.5


 Here are 2 more bugs:
 1)
 Search for:
   united states of America
 Suggests:
  united states oft America
 It looks like the SC doesn't check stopwords, and of is a stopword.  Thus, 
 it does not exist in the index,
 but oft does, so SC suggests oft and thinks of is misspelled.  I think 
 the SC component should check the list of
 stopwords, too, no?
 2)
 Search for:
  united states of America
 Suggests:
  united states oftAmericaa
 The of-oft is described above.  But note how SC suggested America-Americaa, 
 but it didn't do that for america.
 This looks like case-sensitivity problem.  Shouldn't the SC be 
 case-insensitive?
 I can't produce a patch now (no src handy), so I'm hoping Grant or somebody 
 else can do it based on this report.

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

[jira] Updated: (SOLR-1532) allow StreamingUpdateSolrServer to use a provided HttpClient


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

Shalin Shekhar Mangar updated SOLR-1532:


Attachment: SOLR-1532.patch

Synced to trunk. I'll commit this shortly.

 allow StreamingUpdateSolrServer to use a provided HttpClient
 

 Key: SOLR-1532
 URL: https://issues.apache.org/jira/browse/SOLR-1532
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 1.4
Reporter: gabriele renzi
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1532.patch, SOLR-1532.patch


 As of r830319 StreamingUpdateSolrServer does not allow calling code to 
 provide an HttpClient, and this implies client code cannot reuse an existing 
 connection manager, the patch  adds a new constructor and refactors the old 
 one to use this.

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

[jira] Resolved: (SOLR-1532) allow StreamingUpdateSolrServer to use a provided HttpClient


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

Shalin Shekhar Mangar resolved SOLR-1532.
-

Resolution: Fixed
  Assignee: Shalin Shekhar Mangar

Committed revision 890769.

Thanks Gabriele!

 allow StreamingUpdateSolrServer to use a provided HttpClient
 

 Key: SOLR-1532
 URL: https://issues.apache.org/jira/browse/SOLR-1532
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 1.4
Reporter: gabriele renzi
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1532.patch, SOLR-1532.patch


 As of r830319 StreamingUpdateSolrServer does not allow calling code to 
 provide an HttpClient, and this implies client code cannot reuse an existing 
 connection manager, the patch  adds a new constructor and refactors the old 
 one to use this.

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

[jira] Updated: (SOLR-1655) Remove default datasource MockDataSource from DIH requestHandler config in dataimport-solrconfig.xml

2009-12-15 Thread Akshay K. Ukey (JIRA)


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

Akshay K. Ukey updated SOLR-1655:
-

Attachment: SOLR-1655.patch

Patch in sync with trunk

 Remove default datasource MockDataSource from DIH requestHandler config in 
 dataimport-solrconfig.xml
 

 Key: SOLR-1655
 URL: https://issues.apache.org/jira/browse/SOLR-1655
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 1.4
Reporter: Akshay K. Ukey
Assignee: Noble Paul
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1655.patch, SOLR-1655.patch


 Presence of MockDataSource as default datasource for DataImportHandler 
 requestHandler in dataimport-solrconfig.xml (which is used by DIH tests) 
 requires name attribute for dataSource tag to be present in dataConfig.

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

[jira] Updated: (SOLR-919) Cache and reuse the SolrConfig


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

Noble Paul updated SOLR-919:


Attachment: SOLR-919.patch

untested patch

 Cache and reuse the SolrConfig
 --

 Key: SOLR-919
 URL: https://issues.apache.org/jira/browse/SOLR-919
 Project: Solr
  Issue Type: Improvement
  Components: multicore
Reporter: Noble Paul
Assignee: Noble Paul
 Fix For: 1.5

 Attachments: SOLR-919.patch


 If there are 1000's of cores the no:of times we need to load and parse the 
 solrconfig.xml is going to be very expensive. It is desirable to just create 
 one instance of SolrConfig object and re-use it across cores

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

[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields

2009-12-15 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll commented on SOLR-1131:
---

bq. It is not clear as to why can't the 'sf' instance be cached and reused? 

Because there is no way to change the name on a SchemaField w/o changing 
SchemaField to be non-final.  I don't think SchemaField should be non-final.

bq. Why do we have a map for flags why not use a bitset?

Yeah, we could add a new method that takes a bitset, b/c I believe that is what 
is used under the hood anyway.


 Allow a single field type to index multiple fields
 --

 Key: SOLR-1131
 URL: https://issues.apache.org/jira/browse/SOLR-1131
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Reporter: Ryan McKinley
Assignee: Grant Ingersoll
 Fix For: 1.5

 Attachments: SOLR-1131-IndexMultipleFields.patch, 
 SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch


 In a few special cases, it makes sense for a single field (the concept) to 
 be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
 concept point may be best indexed in a variety of ways:
  * geohash (sincle lucene field)
  * lat field, lon field (two double fields)
  * cartesian tiers (a series of fields with tokens to say if it exists within 
 that region)

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

[jira] Resolved: (SOLR-1655) Remove default datasource MockDataSource from DIH requestHandler config in dataimport-solrconfig.xml


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

Noble Paul resolved SOLR-1655.
--

Resolution: Fixed

committed r890775
Thanks Akshay

 Remove default datasource MockDataSource from DIH requestHandler config in 
 dataimport-solrconfig.xml
 

 Key: SOLR-1655
 URL: https://issues.apache.org/jira/browse/SOLR-1655
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 1.4
Reporter: Akshay K. Ukey
Assignee: Noble Paul
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1655.patch, SOLR-1655.patch


 Presence of MockDataSource as default datasource for DataImportHandler 
 requestHandler in dataimport-solrconfig.xml (which is used by DIH tests) 
 requires name attribute for dataSource tag to be present in dataConfig.

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

[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields


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

Noble Paul commented on SOLR-1131:
--

bq.Because there is no way to change the name on a SchemaField w/o changing 
SchemaField to be non-final. I don't think SchemaField should be non-final.

Even if SchemaField is final we can precreate and cache the SchemaField objects 
because the properties of the synthetic field is known in advance. For 
instance, if you have a dimension of 2 ,the PointType instance will always have 
2 well known synthetic names and types that can be created well in advance and 
they can be reused

 Allow a single field type to index multiple fields
 --

 Key: SOLR-1131
 URL: https://issues.apache.org/jira/browse/SOLR-1131
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Reporter: Ryan McKinley
Assignee: Grant Ingersoll
 Fix For: 1.5

 Attachments: SOLR-1131-IndexMultipleFields.patch, 
 SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch


 In a few special cases, it makes sense for a single field (the concept) to 
 be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
 concept point may be best indexed in a variety of ways:
  * geohash (sincle lucene field)
  * lat field, lon field (two double fields)
  * cartesian tiers (a series of fields with tokens to say if it exists within 
 that region)

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

[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields

2009-12-15 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll commented on SOLR-1131:
---

bq. Even if SchemaField is final we can precreate and cache the SchemaField 
objects because the properties of the synthetic field is known in advance. For 
instance, if you have a dimension of 2 ,the PointType instance will always have 
2 well known synthetic names and types that can be created well in advance and 
they can be reused

True, but you need to also be able to change the name and it needs to be able 
to rely on the existing createField signature, which uses these values on the 
SchemaField.  Earlier patches had a separate, internal createField() method 
that took in all the options (thus not requiring the SF at all) but they don't 
work for the delegation.  

I'm open to ideas, though, so throw up some code.

 Allow a single field type to index multiple fields
 --

 Key: SOLR-1131
 URL: https://issues.apache.org/jira/browse/SOLR-1131
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Reporter: Ryan McKinley
Assignee: Grant Ingersoll
 Fix For: 1.5

 Attachments: SOLR-1131-IndexMultipleFields.patch, 
 SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch


 In a few special cases, it makes sense for a single field (the concept) to 
 be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
 concept point may be best indexed in a variety of ways:
  * geohash (sincle lucene field)
  * lat field, lon field (two double fields)
  * cartesian tiers (a series of fields with tokens to say if it exists within 
 that region)

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

[jira] Updated: (SOLR-1131) Allow a single field type to index multiple fields


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

Shalin Shekhar Mangar updated SOLR-1131:


Attachment: SOLR-1131.patch

I guess Noble was referring to something like what is done in this patch.

# DelegatingFieldType has a new method:
{code}
public SchemaField[] getSubFields(SchemaField mainField);
{code}
# PointType and PlusMinusField implement this new method. It is not the 
prettiest way but this is one way to do it.
# With this approach, we can get the names from the subFields wherever the name 
is used (not implemented in this patch).

The PlusMinusField is actually a field type and not a field so we should 
probably rename it to PlusMinusFieldType.

 Allow a single field type to index multiple fields
 --

 Key: SOLR-1131
 URL: https://issues.apache.org/jira/browse/SOLR-1131
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Reporter: Ryan McKinley
Assignee: Grant Ingersoll
 Fix For: 1.5

 Attachments: SOLR-1131-IndexMultipleFields.patch, 
 SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch


 In a few special cases, it makes sense for a single field (the concept) to 
 be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
 concept point may be best indexed in a variety of ways:
  * geohash (sincle lucene field)
  * lat field, lon field (two double fields)
  * cartesian tiers (a series of fields with tokens to say if it exists within 
 that region)

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

[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields

2009-12-15 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll commented on SOLR-1131:
---

OK, I see what you mean.  I don't think we should add it onto the interface, 
though.  I think it can just be handled by changing the signature of the 
createField method that takes in the delegatedFieldType.

 Allow a single field type to index multiple fields
 --

 Key: SOLR-1131
 URL: https://issues.apache.org/jira/browse/SOLR-1131
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Reporter: Ryan McKinley
Assignee: Grant Ingersoll
 Fix For: 1.5

 Attachments: SOLR-1131-IndexMultipleFields.patch, 
 SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch


 In a few special cases, it makes sense for a single field (the concept) to 
 be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
 concept point may be best indexed in a variety of ways:
  * geohash (sincle lucene field)
  * lat field, lon field (two double fields)
  * cartesian tiers (a series of fields with tokens to say if it exists within 
 that region)

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

[jira] Resolved: (SOLR-1653) add PatternReplaceCharFilter

2009-12-15 Thread Koji Sekiguchi (JIRA)


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

Koji Sekiguchi resolved SOLR-1653.
--

Resolution: Fixed

Committed revision 890798. Thanks Shalin and Noble for taking time to review 
the patch.

 add PatternReplaceCharFilter
 

 Key: SOLR-1653
 URL: https://issues.apache.org/jira/browse/SOLR-1653
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Affects Versions: 1.4
Reporter: Koji Sekiguchi
Assignee: Koji Sekiguchi
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1653.patch, SOLR-1653.patch


 Add a new CharFilter that uses a regular expression for the target of replace 
 string in char stream.
 Usage:
 {code:title=schema.xml}
 fieldType name=textCharNorm class=solr.TextField 
 positionIncrementGap=100 
   analyzer
 charFilter class=solr.PatternReplaceCharFilterFactory
 groupedPattern=([nN][oO]\.)\s*(\d+)
 replaceGroups=1,2 blockDelimiters=:;/
 charFilter class=solr.MappingCharFilterFactory 
 mapping=mapping-ISOLatin1Accent.txt/
 tokenizer class=solr.WhitespaceTokenizerFactory/
   /analyzer
 /fieldType
 {code}

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

[jira] Commented: (SOLR-1532) allow StreamingUpdateSolrServer to use a provided HttpClient

2009-12-15 Thread gabriele renzi (JIRA)


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

gabriele renzi commented on SOLR-1532:
--

thanks toy you, I was starting to lose hope :)

 allow StreamingUpdateSolrServer to use a provided HttpClient
 

 Key: SOLR-1532
 URL: https://issues.apache.org/jira/browse/SOLR-1532
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 1.4
Reporter: gabriele renzi
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 1.5

 Attachments: SOLR-1532.patch, SOLR-1532.patch


 As of r830319 StreamingUpdateSolrServer does not allow calling code to 
 provide an HttpClient, and this implies client code cannot reuse an existing 
 connection manager, the patch  adds a new constructor and refactors the old 
 one to use this.

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

Jetty/Solr unresponsive

2009-12-15 Thread Thomas Koch

Hi,

I'm trying to package SOLR 1.4 for debian. When running test tests, many of 
them fail with Jetty/Solr unresponsive after something about 121 seconds 
(timeout?).

a) Why? Is it possible, that I'm expected to run the tests as root?

b) I've to disable all tests, that access the internet when building the 
debian package. As I understand, JUnit doesn't have a way to annotate tests 
with a tag (accesses-internet) and then have the test runner disable tests 
with certain tags?

c) When I've run the tests with ant test, where do I have a summary of failed 
tests? Do I've to scan through the output of ant test?

Thanks for your help,

Thomas Koch, http://www.koch.ro

Re: NPE in MoreLikeThis referenced doc not found and debugQuery=True

On Thu, Dec 10, 2009 at 6:34 PM, david.stu...@progressivealliance.co.uk 
david.stu...@progressivealliance.co.uk wrote:

 Hi All,

 When I do a specific MLT search on a document with debugQuery=True I am
 getting
 a NullPoniterException both on screen and in my catalina logs. The query is
 as
 follows


 http://localhost:8080/solr2/select/?mlt.minwl=3mlt.fl=bodymlt.mintf=1mlt.maxwl=15mlt.maxqt=20version=1.2rows=5mlt.mindf=1fl=nid,title,path,url,digest,teaserstart=0q=nid:16036qt=mltdebugQuery=true

 Is this desired behavior?

 java.lang.RuntimeException: java.lang.NullPointerException
 at org.apache.solr.search.QueryParsing.toString(QueryParsing.java:470)
 at

 org.apache.solr.util.SolrPluginUtils.doStandardDebug(SolrPluginUtils.java:399)
 at

 org.apache.solr.handler.MoreLikeThisHandler.handleRequestBody(MoreLikeThisHandle
 r.java:189)
 at

 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java
 :131)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1204)
 at

 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
 at

 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
 at

 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt
 erChain.java:235)
 at

 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.
 java:206)
 at

 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:2
 33)
 at

 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1
 91)
 at

 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
 at

 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at

 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109
 )
 at
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
 at
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
 at

 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Pr
 otocol.java:583)
 at
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 at java.lang.Thread.run(Thread.java:637)
 Caused by: java.lang.NullPointerException
 at org.apache.solr.search.QueryParsing.toString(QueryParsing.java:439)
 at org.apache.solr.search.QueryParsing.toString(QueryParsing.java:467)
 ... 18 more


 Apologies if this has been discussed or deemed desired, but thought I would
 mention this and offer a patch as a entry into helping with the project.


Thanks for reporting this Dave. It'd be great if you can open a Jira issue
and attach a unit test reproducing this issue. A fix would be even better :)

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

-- 
Regards,
Shalin Shekhar Mangar.

[jira] Commented: (SOLR-17) XSD for solr requests/responses


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

Chris A. Mattmann commented on SOLR-17:
---

In what way? And furthermore, I don't appreciate the tone of your comment. Is 
this the way you, as a committer, encourage people to contribute to SOLR? I 
hope not.

 XSD for solr requests/responses
 ---

 Key: SOLR-17
 URL: https://issues.apache.org/jira/browse/SOLR-17
 Project: Solr
  Issue Type: Improvement
Reporter: Mike Baranczak
Priority: Minor
 Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd, 
 UselessRequestHandler.java


 Attaching an XML schema definition for the responses and the update requests. 
 I needed to do this for myself anyway, so I might as well contribute it to 
 the project.
 At the moment, I have no plans to write an XSD for the config documents, but 
 it wouldn't be a bad idea.
 TODO: change the schema URL. I'm guessing that Apache already has some sort 
 of naming convention for these?

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

[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)

2009-12-15 Thread Yonik Seeley (JIRA)

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

Yonik Seeley commented on SOLR-1277:

I think I'll try to start implementing some bootstrap code - it will make it
simple for new users to get a cluster up and running, in addition to making
further development easier. I'm thinking of enabling via -Dboostrap_collection
that will do everything necessary including copying local files to zk.

Implement a Solr specific naming service (using Zookeeper)
--

Key: SOLR-1277
URL: https://issues.apache.org/jira/browse/SOLR-1277
Project: Solr
Issue Type: New Feature
Affects Versions: 1.4
Reporter: Jason Rutherglen
Assignee: Grant Ingersoll
Priority: Minor
Fix For: 1.5

Attachments: log4j-1.2.15.jar, SOLR-1277.patch, SOLR-1277.patch,
SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.jar

Original Estimate: 672h
Remaining Estimate: 672h

The goal is to give Solr server clusters self-healing attributes
where if a server fails, indexing and searching don't stop and
all of the partitions remain searchable. For configuration, the
ability to centrally deploy a new configuration without servers
going offline.
We can start with basic failover and start from there?
Features:
* Automatic failover (i.e. when a server fails, clients stop
trying to index to or search it)
* Centralized configuration management (i.e. new solrconfig.xml
or schema.xml propagates to a live Solr cluster)
* Optionally allow shards of a partition to be moved to another
server (i.e. if a server gets hot, move the hot segments out to
cooler servers). Ideally we'd have a way to detect hot segments
and move them seamlessly. With NRT this becomes somewhat more
difficult but not impossible?

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

[jira] Commented: (SOLR-1630) StringIndexOutOfBoundsException in SpellCheckComponent

2009-12-15 Thread Guillaume Lebourgeois (JIRA)


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

Guillaume Lebourgeois commented on SOLR-1630:
-

Hi, it seems I've encountered the same bug. All queries using the - char, or 
the _ char make solr throw an exception when using the SpellCheckComponent. It 
is possible to temporary fix it by setting accuracy parameter to 1.0 (which 
makes the spellcheck pretty useless, but avoid exceptions).

 StringIndexOutOfBoundsException in SpellCheckComponent
 --

 Key: SOLR-1630
 URL: https://issues.apache.org/jira/browse/SOLR-1630
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis, spellchecker
Affects Versions: 1.4
 Environment: Solr 1.4
 Lucene 2.9.1
 Win XP
 java version 1.6.0_14
Reporter: Robin Wojciki
Assignee: Shalin Shekhar Mangar
 Attachments: bug.xml, schema.xml, solrconfig.xml


 For some documents/search strings, the SpellCheckComponent throws 
 StringIndexOutOfBoundsException
 See: http://www.lucidimagination.com/search/document/3be6555227e031fc/
 h2. Replication
  * Save attached schema.xml and solrconfig.xml in 
 apache-solr-1.4.0/example/solr/conf
  * Start Solr
  * Index attached bug.xml
  * Query [http://localhost:8983/solr/select/?q=awehjse-wjkekw]
 It throws a StringIndexOutOfBoundsException
 {noformat} String index out of range: -7
 java.lang.StringIndexOutOfBoundsException: String index out of range: -7
   at java.lang.AbstractStringBuilder.replace(Unknown Source)
   at java.lang.StringBuilder.replace(Unknown Source)
   at 
 org.apache.solr.handler.component.SpellCheckComponent.toNamedList(SpellCheckComponent.java:248)
   at 
 org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:143)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
 {noformat} 

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

[jira] Created: (SOLR-1657) convert the rest of solr to use the new tokenstream API

convert the rest of solr to use the new tokenstream API
---

 Key: SOLR-1657
 URL: https://issues.apache.org/jira/browse/SOLR-1657
 Project: Solr
  Issue Type: Task
Reporter: Robert Muir


org.apache.solr.analysis:
BufferedTokenStream
 - CommonGramsFilter
 - CommonGramsQueryFilter
 - RemoveDuplicatesTokenFilter
CapitalizationFilterFactory
HyphenatedWordsFilter
LengthFilter (deprecated, remove)
PatternTokenizerFactory (remove deprecated methods)
SynonymFilter
SynonymFilterFactory
WordDelimiterFilter

org.apache.solr.handler:
AnalysisRequestHandler
AnalysisRequestHandlerBase

org.apache.solr.handler.component:
QueryElevationComponent
SpellCheckComponent

org.apache.solr.highlight:
DefaultSolrHighlighter

org.apache.solr.search:
FieldQParserPlugin

org.apache.solr.spelling:
SpellingQueryConverter


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

[jira] Created: (SOLR-1658) Negative query weirdness

2009-12-15 Thread David Bowen (JIRA)

Negative query weirdness


 Key: SOLR-1658
 URL: https://issues.apache.org/jira/browse/SOLR-1658
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.4
Reporter: David Bowen


In the standard Solr example, the queries
# adapter AND NOT power
# adapter AND (NOT power)

are different.  The second will never return any results.  I find this 
surprising.  I think the second query should be the same as the first.



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

[jira] Commented: (SOLR-1657) convert the rest of solr to use the new tokenstream API

2009-12-15 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-1657:
---

+ test classes that use old stuff for testing ;)

 convert the rest of solr to use the new tokenstream API
 ---

 Key: SOLR-1657
 URL: https://issues.apache.org/jira/browse/SOLR-1657
 Project: Solr
  Issue Type: Task
Reporter: Robert Muir

 org.apache.solr.analysis:
 BufferedTokenStream
  - CommonGramsFilter
  - CommonGramsQueryFilter
  - RemoveDuplicatesTokenFilter
 CapitalizationFilterFactory
 HyphenatedWordsFilter
 LengthFilter (deprecated, remove)
 PatternTokenizerFactory (remove deprecated methods)
 SynonymFilter
 SynonymFilterFactory
 WordDelimiterFilter
 org.apache.solr.handler:
 AnalysisRequestHandler
 AnalysisRequestHandlerBase
 org.apache.solr.handler.component:
 QueryElevationComponent
 SpellCheckComponent
 org.apache.solr.highlight:
 DefaultSolrHighlighter
 org.apache.solr.search:
 FieldQParserPlugin
 org.apache.solr.spelling:
 SpellingQueryConverter

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

[jira] Commented: (SOLR-1657) convert the rest of solr to use the new tokenstream API


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

Robert Muir commented on SOLR-1657:
---

bq. + test classes that use old stuff for testing 

in fact I am working on the tests first. In my opinion what we should do is 
take the functionality of lucene's BaseTokenStreamTestCase and add it to 
BaseTokenTestCase.
Perhaps this old stuff can be implemented on top of assertTokenStreamContents, 
assertAnalyzesTo, etc, or we can change the tests.

Either way, my reasoning is that this logic is very careful about ensuring that 
tokenstreams behave properly, it inserts garbage data to make sure that 
attributes are cleared correctly, etc, etc.


 convert the rest of solr to use the new tokenstream API
 ---

 Key: SOLR-1657
 URL: https://issues.apache.org/jira/browse/SOLR-1657
 Project: Solr
  Issue Type: Task
Reporter: Robert Muir

 org.apache.solr.analysis:
 BufferedTokenStream
  - CommonGramsFilter
  - CommonGramsQueryFilter
  - RemoveDuplicatesTokenFilter
 CapitalizationFilterFactory
 HyphenatedWordsFilter
 LengthFilter (deprecated, remove)
 PatternTokenizerFactory (remove deprecated methods)
 SynonymFilter
 SynonymFilterFactory
 WordDelimiterFilter
 org.apache.solr.handler:
 AnalysisRequestHandler
 AnalysisRequestHandlerBase
 org.apache.solr.handler.component:
 QueryElevationComponent
 SpellCheckComponent
 org.apache.solr.highlight:
 DefaultSolrHighlighter
 org.apache.solr.search:
 FieldQParserPlugin
 org.apache.solr.spelling:
 SpellingQueryConverter

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

[jira] Created: (SOLR-1659) Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 +

2009-12-15 Thread Mark Miller (JIRA)

Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 +
---

 Key: SOLR-1659
 URL: https://issues.apache.org/jira/browse/SOLR-1659
 Project: Solr
  Issue Type: Task
Reporter: Mark Miller




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

[jira] Updated: (SOLR-1659) Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 +

2009-12-15 Thread Mark Miller (JIRA)


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

Mark Miller updated SOLR-1659:
--

Attachment: SOLR-1659.patch

A quick, rough stab at everything *but* analyzer stuff (SOLR-1657), test class 
stuff, and a compression workaround (which Lucene has pulled).

 Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 +
 ---

 Key: SOLR-1659
 URL: https://issues.apache.org/jira/browse/SOLR-1659
 Project: Solr
  Issue Type: Task
Reporter: Mark Miller
 Attachments: SOLR-1659.patch




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

[jira] Commented: (SOLR-17) XSD for solr requests/responses

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

Shalin Shekhar Mangar commented on SOLR-17:
---

Chris, it seems that you are taking my comment personally. Please don't; it is
not my intention to ridicule anyone's efforts.

As you can see, this issue has been open for some time now and a major reason
is that we have never found a good use for an XSD. I'm merely trying to say
that it seems like we're trying to _find_ use-cases for a solution instead of
starting with an actual need.

My point is that Solr can use it we _want_ to but Solr certainly does not
_need_ to use it. I don't think we gain much by an XSD.

XSD for solr requests/responses
---

Key: SOLR-17
URL: https://issues.apache.org/jira/browse/SOLR-17
Project: Solr
Issue Type: Improvement
Reporter: Mike Baranczak
Priority: Minor
Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd,
UselessRequestHandler.java

Attaching an XML schema definition for the responses and the update requests.
I needed to do this for myself anyway, so I might as well contribute it to
the project.
At the moment, I have no plans to write an XSD for the config documents, but
it wouldn't be a bad idea.
TODO: change the schema URL. I'm guessing that Apache already has some sort
of naming convention for these?

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

[jira] Created: (SOLR-1660) capitalizationfilter crashes if you use the maxWordCountOption

capitalizationfilter crashes if you use the maxWordCountOption
--

 Key: SOLR-1660
 URL: https://issues.apache.org/jira/browse/SOLR-1660
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 1.4
Reporter: Robert Muir
 Attachments: SOLR-1660.patch

because arrayCopys into null.

if you want a testcase i can yank it out of in-progress patch from SOLR-1657, 
but i think its obvious.


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

[jira] Updated: (SOLR-1660) capitalizationfilter crashes if you use the maxWordCountOption


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

Robert Muir updated SOLR-1660:
--

Attachment: SOLR-1660.patch

 capitalizationfilter crashes if you use the maxWordCountOption
 --

 Key: SOLR-1660
 URL: https://issues.apache.org/jira/browse/SOLR-1660
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 1.4
Reporter: Robert Muir
 Attachments: SOLR-1660.patch


 because arrayCopys into null.
 if you want a testcase i can yank it out of in-progress patch from SOLR-1657, 
 but i think its obvious.

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

[jira] Commented: (SOLR-1658) Negative query weirdness

2009-12-15 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on SOLR-1658:


I agree.  Extended dismax already implements this.

It comes down to needing a flag... sometimes you want pure negative queries 
(when parsing query parts for example) and sometimes you don't.  We should just 
add a boolean flag to SolrQueryParser.

*But* we don't want to do this for the top level for filter queries - as an 
optimization, solr currently caches -foo:x the same as foo:x and if we always 
handled negative queries at the QP level, it would disable that.

 Negative query weirdness
 

 Key: SOLR-1658
 URL: https://issues.apache.org/jira/browse/SOLR-1658
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 1.4
Reporter: David Bowen

 In the standard Solr example, the queries
 # adapter AND NOT power
 # adapter AND (NOT power)
 are different.  The second will never return any results.  I find this 
 surprising.  I think the second query should be the same as the first.

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

[jira] Commented: (SOLR-17) XSD for solr requests/responses

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

Chris A. Mattmann commented on SOLR-17:
---

{quote}
Chris, it seems that you are taking my comment personally. Please don't; it is
not my intention to ridicule anyone's efforts.
{quote}

I wouldn't say I took it personally -- as I said, I'm not sure I appreciated
the tone of the comment. A one-liner, that's curt, provides no background (lest
only an opinion), and that sounds like ridicule will elicit such a response in
many cases, see Netiquette Guidelines:

http://tools.ietf.org/html/rfc1855

{quote}
As you can see, this issue has been open for some time now and a major reason
is that we have never found a good use for an XSD. I'm merely trying to say
that it seems like we're trying to find use-cases for a solution instead of
starting with an actual need.
{quote}

Sure, judging by its issue number (17), I could tell it has been open for a
while. The ongoing conversation regarding SOLR-1586, see here:

http://www.lucidimagination.com/search/document/7094af4a3aa8bc03/namespaces_in_response_solr_1586

led me to this issue, as pointed out by Hoss. There _have_ been some relevant
discussions that have come up regarding XSD's, which was my point. So, I'm not
sure that we're _trying_ to find anything -- the discussion presented itself on
its own. Furthermore, even if the discussion hadn't occured, it doesn't seem
very contribution friendly to ignore something that clearly adds value to a
group of people. XML and XSD people exist and have their tools (as I noted
above, Doxygen, XMLSpy, etc.) for doing validation, and for generating sample
XML files, for designing XML, etc.. Just because there aren't a lot of votes on
the issue, or lots of mail traffic, it doesn't mean that the issue should not
get attention. I'm not sure what's so controversial about adding an XSD to the
SOLR trunk. Hence my point in calling attention to this issue. There's been a
patch available for quite some time. What's missing from the patch to get this
contribution into the trunk?

{quote}
My point is that Solr can use it we want to but Solr certainly does not need to
use it. I don't think we gain much by an XSD.
{quote}

I agree that SOLR, from a code/API/functionality perspective, does not _need_
to use it. However, it would not hurt anything to add the XSD as part of the
trunk for those that would like to download it and use it to understand how to
write additional SOLR XML consuming clients. Or for those that would like to
validate SOLR XML responses they receive. This isn't outside of the ordinary at
all, and I think only adds value, and doesn't take any away. If the concern is
maintaining it, I'd be happy to do so. I'm sure there are others that would
contribute as well.

XSD for solr requests/responses
---

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

[jira] Commented: (SOLR-17) XSD for solr requests/responses

2009-12-15 Thread Uri Boness (JIRA)

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

Uri Boness commented on SOLR-17:

Having well defined XSD's for public services can be *extremely* helpful in
many aspects... together with proper version management they define the
contract between the users the the service. Some of the use cases that Chris
listed above are definitely valid and realistic. Moreover, XSD provides a
natural and proper documentation for the supported formats which any decent xml
editor can make use of and provide you with hints for writing the
solrconfig.xml and the schema.xml (for example).

That said... most of the xml formats in Solr are too generic to benefit from
XSD's. The only format where it makes sense is the schema.xml as it has an
expressive domain-driven structure. Unfortunately this is something you cannot
say for for the response formats and the solrconfig.xml where the
expressiveness lays within the *values* of the elements/attributes rather than
in the elements/attribute *names* themselves. XSD doesn't handle
element/attribute values very well.

XSD for solr requests/responses
---

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

[jira] Commented: (SOLR-17) XSD for solr requests/responses

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

Chris A. Mattmann commented on SOLR-17:
---

Hi Uri:

Thanks. Comments below:

{quote}
Having well defined XSD's for public services can be extremely helpful in many
aspects... together with proper version management they define the contract
between the users the the service. Some of the use cases that Chris listed
above are definitely valid and realistic. Moreover, XSD provides a natural and
proper documentation for the supported formats which any decent xml editor can
make use of and provide you with hints for writing the solrconfig.xml and the
schema.xml (for example).
{quote}

+1.

{quote}
That said... most of the xml formats in Solr are too generic to benefit from
XSD's. The only format where it makes sense is the schema.xml as it has an
expressive domain-driven structure. Unfortunately this is something you cannot
say for for the response formats and the solrconfig.xml where the
expressiveness lays within the values of the elements/attributes rather than in
the elements/attribute names themselves. XSD doesn't handle element/attribute
values very well.
{quote}

Kinda sorta. Regardless of how generic the XML used in SOLR is, I think it can
still benefit from being documented in an XSD. That way, as you mentioned
above, if it ever changes, with proper versioning, you have a baseline. In
addition, for those wanting to know what can and can't be done to be a valid
SOLR XML response (as I did w.r.t. geo stuff), the XSD/DTD can serve as a guide
regarding that interface. And beyond just names, there's cardinality that the
XSD could help validate (i.e., can you have sub-tags within a double in the
SOLR XML response? -- the answer is no, and this is something that could be
codified in a DTD/XSD). Furthermore, we could also document what each of the
valid attribute and element definitions are too, which would be useful even
from a documentation perspective.

Maybe the idea is that we should have XSD/DTDs for not only the services, but
also for some of the configuration. This is a completely valid idea and I'm +1
for it. However, as a start, I think contributing and committing the SOLR XML
response writer output XSD (and a DTD, which I'll attach) is something that
adds value, doesn't take anything away, or touch other parts of the code, etc.,
and is worthwhile to do.

Cheers,
Chris

XSD for solr requests/responses
---

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

[jira] Commented: (SOLR-17) XSD for solr requests/responses

2009-12-15 Thread Uri Boness (JIRA)

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

Uri Boness commented on SOLR-17:

{quote}
However, as a start, I think contributing and committing the SOLR XML response
writer output XSD (and a DTD, which I'll attach) is something that adds value,
doesn't take anything away, or touch other parts of the code, etc., and is
worthwhile to do.
{quote}

Fair enough. I guess it can always serve as a reference to better understanding
what to expect from a Solr response (instead of trying to figure things out
from the code). Good thing about this generic format is that it's unlikely to
change that frequently, so the XSD's will probably not change that often as
well.

XSD for solr requests/responses
---

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

[jira] Commented: (SOLR-1656) XInclude's are resolved relative CWD, not instance dir

2009-12-15 Thread Hoss Man (JIRA)


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

Hoss Man commented on SOLR-1656:


bq. I may be very wrongly informing but using ...

I'm sure you are correct, but as i mentioned, Config only has an InputStream 
when it instantiates the DocumentBuilder. (hence: non trivial fix)

 XInclude's are resolved relative CWD, not instance dir
 --

 Key: SOLR-1656
 URL: https://issues.apache.org/jira/browse/SOLR-1656
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.4
Reporter: Hoss Man

 As noted on the mailing list, when an XInclude in a config files refrences a 
 relative path, it's resolved relative the CWD of the servlet container, and 
 not the instanceDir of the core...
  
 http://old.nabble.com/using-Xinclude-with-multi-core-to26548400.html#a26548400

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

[jira] Commented: (SOLR-17) XSD for solr requests/responses

2009-12-15 Thread Hoss Man (JIRA)

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

Hoss Man commented on SOLR-17:
--

bq. There are actually a lot of useful things that could be done with an XSD.

I agree ... my comment (way back when) was more about what we should do with it
in a Solr release: converting it from a *.xsd attachment to a *.patch
attachment...

1. where should it live in source control? where should it live in the release
artifact?
2. what schema URI should we pick for identifying this? (i suspect apache.org
has a standard for this, so or at least precident from other projects, so we
should make sure we follow those examples before picking one arbitrarily
3. it won't do any good unless we make the XmlResponseWriter refrence the
schema URI so client tools can validate with it.
4. we need hooks in our own test system for validating responses we get back to
catch potential bugs (either in the schema itself, or in xml that might get
inadvertantly changed)

...etc...

XSD for solr requests/responses
---

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

Re: Namespaces in response (SOLR-1586)

2009-12-15 Thread Chris Hostetter


:  a SolrQueryResponse, no one has ever accused any of those response writers
:  of not being flexible enough to generate a *different* type of response in
:  those formats.
: 
: You may be right, but actually quite a few issues have referenced even non
: XMLWriters of similar issues. See:

I honeslty don't understand what you're getting at here, this list of 
issues is all over the map and almost none of them relate to the 
extensibility of any request handlers...

: http://issues.apache.org/jira/browse/SOLR-1616
  ... this was from someone who didn't notice json.nl=arrarr and 
  felt like the default way of representing a NamedList in JSON was odd.  
  they didn't disagree with the JSON structure, they just don't like the 
  default.
: http://issues.apache.org/jira/browse/SOLR-358
  ...this was an improvement issue to track adding the ruby response 
  writer ... which idnd't exist before this.
: http://issues.apache.org/jira/browse/SOLR-1555
  ...this is a bug in how the term compontent adds the terms to the 
  response ... it's completley orthoginal to the response output 
  structure.
: http://issues.apache.org/jira/browse/SOLR-431
  ...this is from one of my coworkers who had some really old, really 
  hideously hackish plugins from before Solr was open sourced that was 
  trying to find a way to work arround a big fixed in the xml escaping -- 
  i could maybe see this as a response writers need to be more flexible 
  type issue, except they knew from the start the start they were abusing 
  a bug.
: http://issues.apache.org/jira/browse/SOLR-912
  ...this is an issue Kay opened to revamp NamedList to be more typesafe 
  ... also has absolutely nothign to do with how flexible the output 
  representation is.

: Maybe, maybe not. I'm not sure the effect is to make it crystal clear as
: much as it is to make it clearer. XMLWriter is totally ambiguous -- what
: type of XML does it generate? I would argue SOLR response XML, hence the
: SorlXmlResponseWriter.

eh ... agree to disagree i guess. it seems just as valid to say that 
UpdateCommand -- what type of data does it update? ... or that 
RequestHandler is ambigious because it can only handle Solr requests, 
so it should be title SolrRequestHandler.

we have enough ambiguity and confusion with some of our config file 
options and names that non-java users see ... the ones that only plugin 
writers see i'm less concerned with ... better to beef up the javadocs 
that deal with a bunch of deprecation headaches just to add Solr to the 
front of a class name.


-Hoss

[jira] Commented: (SOLR-17) XSD for solr requests/responses

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

Chris A. Mattmann commented on SOLR-17:
---

@Uri:

{quote}
Fair enough. I guess it can always serve as a reference to better understanding
what to expect from a Solr response (instead of trying to figure things out
from the code). Good thing about this generic format is that it's unlikely to
change that frequently, so the XSD's will probably not change that often as
well.
{quote}

+1, thanks for hearing me out!

@Hoss

{quote}
1. where should it live in source control? where should it live in the release
artifact?
2. what schema URI should we pick for identifying this? (i suspect apache.org
has a standard for this, so or at least precident from other projects, so we
should make sure we follow those examples before picking one arbitrarily
{quote}

In src, I think it should live here: src/xsd (let's call it solrresponse.xsd),
and let's make a DTD too (called solrresponse.dtd) that lives in src/dtd. In
release, let's make it live somewhere that gets published onto the SOLR website
(you guys are using forrest, right? I can put a patch together that copies it
to the right place). It would be great to have it at, say:

http://lucene.apache.org/solr/schema/solrresponse.xsd
http://lucene.apaceh.org/solr/dtd/solrresponse.dtd

In the long term, maybe we could version the URIs too, based on the current
SOLR version, but that's down the road.

{quote}
3. it won't do any good unless we make the XmlResponseWriter refrence the
schema URI so client tools can validate with it.
{quote}

Well it'll do some good just to have it out there. I'm a fan of incremental
patchiness, so as a start, can we make this issue just put the XSD/DTD into the
src, and then copy it to a Forrest accessible link, and then a do site rebuild?
Then, as patch #2, we tackle your #3 above. I agree, #3 is pretty trivial
(modifying a static final String in XMLWriter.java), but to me we can do it as
a separate, clean patch, not cluttered with adding the XSD/DTD and then
modifying Forrest (which this patch can do).

{quote}
4. we need hooks in our own test system for validating responses we get back to
catch potential bugs (either in the schema itself, or in xml that might get
inadvertantly changed)
{quote}

I think this is patch #3, or maybe #2a (and can go in along with #2 above), but
+1 for this too. I'm happy to contribute/lead the efforts here. I'll start
preparing patches right away.

Cheers,
Chris

XSD for solr requests/responses
---

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

Re: Namespaces in response (SOLR-1586)

2009-12-15 Thread Mattmann, Chris A (388J)

Hi Hoss:

On 12/15/09 6:39 PM, Chris Hostetter hossman_luc...@fucit.org wrote:

 
 
 :  a SolrQueryResponse, no one has ever accused any of those response writers
 :  of not being flexible enough to generate a *different* type of response in
 :  those formats.
 :
 : You may be right, but actually quite a few issues have referenced even non
 : XMLWriters of similar issues. See:
 
 I honeslty don't understand what you're getting at here, this list of
 issues is all over the map and almost none of them relate to the
 extensibility of any request handlers...

They may be all over the map, but in general they address your statement
about non-XML response writers being flexible enough to generate a
different type of response (although admittedly, none are as clear at the
XMLWriter examples, I'll give you that). The examples I gave were just based
on a quick search of JIRA.

 : Maybe, maybe not. I'm not sure the effect is to make it crystal clear as
 : much as it is to make it clearer. XMLWriter is totally ambiguous -- what
 : type of XML does it generate? I would argue SOLR response XML, hence the
 : SorlXmlResponseWriter.
 
 eh ... agree to disagree i guess. it seems just as valid to say that
 UpdateCommand -- what type of data does it update? ... or that
 RequestHandler is ambigious because it can only handle Solr requests,
 so it should be title SolrRequestHandler.

True! I guess it's just aesthetics. I can go either way, but I dunno. (and
yes, just to be a pest, What type of data does that UpdateCommand update?)

 
 we have enough ambiguity and confusion with some of our config file
 options and names that non-java users see ... the ones that only plugin
 writers see i'm less concerned with ... better to beef up the javadocs
 that deal with a bunch of deprecation headaches just to add Solr to the
 front of a class name.

You give a little, you get a little back. Maybe a compromise is to called it
NamedListResponseWriter, b/c that's really what it writes, no? Naming can be
a pain -- I'll try and think of a good one when I'm preparing the patch for
SOLR-1649.

Thanks for the discussion. Helps to clarify things!

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.mattm...@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department University of
Southern California, Los Angeles, CA 90089 USA
++

[jira] Updated: (SOLR-1316) Create autosuggest component

2009-12-15 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  updated SOLR-1316:


Attachment: suggest.patch

Updated patch:

 * removed the broken RadixTree,
 * changed Suggester and Lookup API so that they don't join the tokens - 
instead they will use whatever tokens are produced by the analyzer. For now 
results are merged into a single SpellingResult.

 Create autosuggest component
 

 Key: SOLR-1316
 URL: https://issues.apache.org/jira/browse/SOLR-1316
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.4
Reporter: Jason Rutherglen
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 1.5

 Attachments: suggest.patch, suggest.patch, suggest.patch, TST.zip

   Original Estimate: 96h
  Remaining Estimate: 96h

 Autosuggest is a common search function that can be integrated
 into Solr as a SearchComponent. Our first implementation will
 use the TernaryTree found in Lucene contrib. 
 * Enable creation of the dictionary from the index or via Solr's
 RPC mechanism
 * What types of parameters and settings are desirable?
 * Hopefully in the future we can include user click through
 rates to boost those terms/phrases higher

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

[jira] Commented: (SOLR-1316) Create autosuggest component

2009-12-15 Thread Andrzej Bialecki (JIRA)


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

Andrzej Bialecki  commented on SOLR-1316:
-

bq. What about DAWGs? Are we still considering them?

I would be happy to include DAWGs if someone were to implement them ... ;)

 Create autosuggest component
 

 Key: SOLR-1316
 URL: https://issues.apache.org/jira/browse/SOLR-1316
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.4
Reporter: Jason Rutherglen
Assignee: Shalin Shekhar Mangar
Priority: Minor
 Fix For: 1.5

 Attachments: suggest.patch, suggest.patch, suggest.patch, TST.zip

   Original Estimate: 96h
  Remaining Estimate: 96h

 Autosuggest is a common search function that can be integrated
 into Solr as a SearchComponent. Our first implementation will
 use the TernaryTree found in Lucene contrib. 
 * Enable creation of the dictionary from the index or via Solr's
 RPC mechanism
 * What types of parameters and settings are desirable?
 * Hopefully in the future we can include user click through
 rates to boost those terms/phrases higher

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

ValueSourceParser problem

Howdy

Couple of things about the ValueSourceParser

#1 Change documentation of
http://wiki.apache.org/solr/SolrPlugins#ValueSourceParser to say extends
ValueSourceParser rather than implements.

#2 There's an AbstractMethodError when you extend ValueSourceParser and
don't override the init(NamedList args) method
because SolrCore:~439 createInitInstance, cast's the plugin class as a
NamedListInitializedPlugin, and call's
((NamedListInitializedPlugin) o).init(info.initArgs);

If your extended ValueSourceParser class doesn't provide an override, then
there's nothing that implements the base interface from
NamedListInitializedPlugin.

Providing a head scratching conundrum that should be avoided.

Seems more than a documentation fix

Patrick

Re: ValueSourceParser problem

2009-12-15 Thread Mattmann, Chris A (388J)

Hey Patrick,

On 12/15/09 9:31 PM, patrick o'leary pj...@pjaol.com wrote:

 #1 Change documentation of
 http://wiki.apache.org/solr/SolrPlugins#ValueSourceParser to say extends
 ValueSourceParser rather than implements.

I updated the Wiki based on your comment.

Cheers,
Chris

++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.mattm...@jpl.nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++
Adjunct Assistant Professor, Computer Science Department University of
Southern California, Los Angeles, CA 90089 USA
++

Re: ValueSourceParser problem

On Wed, Dec 16, 2009 at 11:01 AM, patrick o'leary pj...@pjaol.com wrote:


 #2 There's an AbstractMethodError when you extend ValueSourceParser and
 don't override the init(NamedList args) method
 because SolrCore:~439 createInitInstance, cast's the plugin class as a
 NamedListInitializedPlugin, and call's
 ((NamedListInitializedPlugin) o).init(info.initArgs);

 If your extended ValueSourceParser class doesn't provide an override, then
 there's nothing that implements the base interface from
 NamedListInitializedPlugin.


ValueSourceParser in trunk has an empty init method so you should never get
a AbstractMethodError. Can you check again?

-- 
Regards,
Shalin Shekhar Mangar.

Re: ValueSourceParser problem

Check SolrCore.createInitInstance
It cast's your CustomValueSourceParser as a NamedListInitializedPlugin which
is an interface,
thus the AbstractMethodError, as there isn't a concrete implementation of
init.

If it cast it as a ValueSourceParser in SolrCore then it would be fine.

On Tue, Dec 15, 2009 at 9:59 PM, Shalin Shekhar Mangar 
shalinman...@gmail.com wrote:

 On Wed, Dec 16, 2009 at 11:01 AM, patrick o'leary pj...@pjaol.com wrote:

 
  #2 There's an AbstractMethodError when you extend ValueSourceParser and
  don't override the init(NamedList args) method
  because SolrCore:~439 createInitInstance, cast's the plugin class as a
  NamedListInitializedPlugin, and call's
  ((NamedListInitializedPlugin) o).init(info.initArgs);
 
  If your extended ValueSourceParser class doesn't provide an override,
 then
  there's nothing that implements the base interface from
  NamedListInitializedPlugin.
 
 
 ValueSourceParser in trunk has an empty init method so you should never get
 a AbstractMethodError. Can you check again?

 --
 Regards,
 Shalin Shekhar Mangar.

Re: ValueSourceParser problem

On Wed, Dec 16, 2009 at 11:32 AM, patrick o'leary pj...@pjaol.com wrote:

 Check SolrCore.createInitInstance
 It cast's your CustomValueSourceParser as a NamedListInitializedPlugin
 which
 is an interface,
 thus the AbstractMethodError, as there isn't a concrete implementation of
 init.

 If it cast it as a ValueSourceParser in SolrCore then it would be fine.


That is not possible. Even though the object is cast to an interface
NamedListInitializedPlugin, it is still an instance of ValueSourceParser and
therefore it does have an implementation of the init method. Am I missing
something?

-- 
Regards,
Shalin Shekhar Mangar.

Re: ValueSourceParser problem

SEVERE: java.lang.AbstractMethodError
at org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:439)
at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1498)
at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1492)
at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1525)
at
org.apache.solr.core.SolrCore.initValueSourceParsers(SolrCore.java:1469)
at org.apache.solr.core.SolrCore.init(SolrCore.java:549)
at
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:137)
at
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99)

And
svn info
Path: .
URL: http://svn.apache.org/repos/asf/lucene/solr/trunk
Repository Root: http://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 891117
Node Kind: directory
Schedule: normal
Last Changed Author: koji
Last Changed Rev: 890798
Last Changed Date: 2009-12-15 06:13:59 -0800 (Tue, 15 Dec 2009)


On Tue, Dec 15, 2009 at 10:12 PM, Shalin Shekhar Mangar 
shalinman...@gmail.com wrote:

 On Wed, Dec 16, 2009 at 11:32 AM, patrick o'leary pj...@pjaol.com wrote:

  Check SolrCore.createInitInstance
  It cast's your CustomValueSourceParser as a NamedListInitializedPlugin
  which
  is an interface,
  thus the AbstractMethodError, as there isn't a concrete implementation of
  init.
 
  If it cast it as a ValueSourceParser in SolrCore then it would be fine.
 
 
 That is not possible. Even though the object is cast to an interface
 NamedListInitializedPlugin, it is still an instance of ValueSourceParser
 and
 therefore it does have an implementation of the init method. Am I missing
 something?

 --
 Regards,
 Shalin Shekhar Mangar.

Re: ValueSourceParser problem

On Wed, Dec 16, 2009 at 11:58 AM, patrick o'leary pj...@pjaol.com wrote:

 SEVERE: java.lang.AbstractMethodError
at org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:439)
at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1498)
at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1492)
at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1525)
at
 org.apache.solr.core.SolrCore.initValueSourceParsers(SolrCore.java:1469)
at org.apache.solr.core.SolrCore.init(SolrCore.java:549)
at

 org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:137)
at
 org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99)

 And
 svn info
 Path: .
 URL: http://svn.apache.org/repos/asf/lucene/solr/trunk
 Repository Root: http://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 891117
 Node Kind: directory
 Schedule: normal
 Last Changed Author: koji
 Last Changed Rev: 890798
 Last Changed Date: 2009-12-15 06:13:59 -0800 (Tue, 15 Dec 2009)


I just wrote a custom ValueSourceParser which does not override the init
method and it loads fine on current trunk. Can you share your code?

-- 
Regards,
Shalin Shekhar Mangar.

Re: ValueSourceParser problem

Rather than subject the list to code, it's pasted here
http://www.pasteyourcode.com/13969


On Tue, Dec 15, 2009 at 10:42 PM, Shalin Shekhar Mangar 
shalinman...@gmail.com wrote:

 On Wed, Dec 16, 2009 at 11:58 AM, patrick o'leary pj...@pjaol.com wrote:

  SEVERE: java.lang.AbstractMethodError
 at org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:439)
 at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1498)
 at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1492)
 at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1525)
 at
  org.apache.solr.core.SolrCore.initValueSourceParsers(SolrCore.java:1469)
 at org.apache.solr.core.SolrCore.init(SolrCore.java:549)
 at
 
 
 org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:137)
 at
 
 org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83)
 at
 org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99)
 
  And
  svn info
  Path: .
  URL: http://svn.apache.org/repos/asf/lucene/solr/trunk
  Repository Root: http://svn.apache.org/repos/asf
  Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
  Revision: 891117
  Node Kind: directory
  Schedule: normal
  Last Changed Author: koji
  Last Changed Rev: 890798
  Last Changed Date: 2009-12-15 06:13:59 -0800 (Tue, 15 Dec 2009)
 
 
 I just wrote a custom ValueSourceParser which does not override the init
 method and it loads fine on current trunk. Can you share your code?

 --
 Regards,
 Shalin Shekhar Mangar.

[jira] Updated: (SOLR-1131) Allow a single field type to index multiple fields

2009-12-15 Thread Noble Paul നോബിള്‍ नोब्ळ्


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

Noble Paul updated SOLR-1131:
-

Attachment: SOLR-1131.patch

Modified the Query creation to use the cached SchemaField names. 

 Allow a single field type to index multiple fields
 --

 Key: SOLR-1131
 URL: https://issues.apache.org/jira/browse/SOLR-1131
 Project: Solr
  Issue Type: New Feature
  Components: Schema and Analysis
Reporter: Ryan McKinley
Assignee: Grant Ingersoll
 Fix For: 1.5

 Attachments: SOLR-1131-IndexMultipleFields.patch, 
 SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, 
 SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch


 In a few special cases, it makes sense for a single field (the concept) to 
 be indexed as a set of Fields (lucene Field).  Consider SOLR-773.  The 
 concept point may be best indexed in a variety of ways:
  * geohash (sincle lucene field)
  * lat field, lon field (two double fields)
  * cartesian tiers (a series of fields with tokens to say if it exists within 
 that region)

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

Re: ValueSourceParser problem

it does not have the code for SocialValueSource..

On Wed, Dec 16, 2009 at 12:18 PM, patrick o'leary pj...@pjaol.com wrote:
 Rather than subject the list to code, it's pasted here
 http://www.pasteyourcode.com/13969


 On Tue, Dec 15, 2009 at 10:42 PM, Shalin Shekhar Mangar 
 shalinman...@gmail.com wrote:

 On Wed, Dec 16, 2009 at 11:58 AM, patrick o'leary pj...@pjaol.com wrote:

  SEVERE: java.lang.AbstractMethodError
     at org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:439)
     at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1498)
     at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1492)
     at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1525)
     at
  org.apache.solr.core.SolrCore.initValueSourceParsers(SolrCore.java:1469)
     at org.apache.solr.core.SolrCore.init(SolrCore.java:549)
     at
 
 
 org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:137)
     at
 
 org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83)
     at
 org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99)
 
  And
  svn info
  Path: .
  URL: http://svn.apache.org/repos/asf/lucene/solr/trunk
  Repository Root: http://svn.apache.org/repos/asf
  Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
  Revision: 891117
  Node Kind: directory
  Schedule: normal
  Last Changed Author: koji
  Last Changed Rev: 890798
  Last Changed Date: 2009-12-15 06:13:59 -0800 (Tue, 15 Dec 2009)
 
 
 I just wrote a custom ValueSourceParser which does not override the init
 method and it loads fine on current trunk. Can you share your code?

 --
 Regards,
 Shalin Shekhar Mangar.





-- 
-
Noble Paul | Systems Architect| AOL | http://aol.com

Re: ValueSourceParser problem

Yeah.. can't release that part mate, all you need is

package com.pjaol;

import org.apache.lucene.queryParser.ParseException;
import org.apache.solr.search.FunctionQParser;
import org.apache.solr.search.ValueSourceParser;
import org.apache.solr.search.function.ValueSource;

public class CustomValueSourceParser extends ValueSourceParser{

@Override
public ValueSource parse(FunctionQParser fp) throws ParseException {

System.out.println(*** Called);
return null;
}

}


And
valueSourceParser name=social_a class=com.pjaol.CustomValueSourceParser
/
in your solrconfig.xml

The parse method only gets called at query time

2009/12/15 Noble Paul നോബിള്‍ नोब्ळ् noble.p...@corp.aol.com

 it does not have the code for SocialValueSource..

 On Wed, Dec 16, 2009 at 12:18 PM, patrick o'leary pj...@pjaol.com wrote:
  Rather than subject the list to code, it's pasted here
  http://www.pasteyourcode.com/13969
 
 
  On Tue, Dec 15, 2009 at 10:42 PM, Shalin Shekhar Mangar 
  shalinman...@gmail.com wrote:
 
  On Wed, Dec 16, 2009 at 11:58 AM, patrick o'leary pj...@pjaol.com
 wrote:
 
   SEVERE: java.lang.AbstractMethodError
  at
 org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:439)
  at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1498)
  at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1492)
  at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1525)
  at
  
 org.apache.solr.core.SolrCore.initValueSourceParsers(SolrCore.java:1469)
  at org.apache.solr.core.SolrCore.init(SolrCore.java:549)
  at
  
  
 
 org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:137)
  at
  
 
 org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83)
  at
  org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99)
  
   And
   svn info
   Path: .
   URL: http://svn.apache.org/repos/asf/lucene/solr/trunk
   Repository Root: http://svn.apache.org/repos/asf
   Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
   Revision: 891117
   Node Kind: directory
   Schedule: normal
   Last Changed Author: koji
   Last Changed Rev: 890798
   Last Changed Date: 2009-12-15 06:13:59 -0800 (Tue, 15 Dec 2009)
  
  
  I just wrote a custom ValueSourceParser which does not override the init
  method and it loads fine on current trunk. Can you share your code?
 
  --
  Regards,
  Shalin Shekhar Mangar.
 
 



 --
 -
 Noble Paul | Systems Architect| AOL | http://aol.com

Re: ValueSourceParser problem