[jira] Commented: (SOLR-1365) Add configurable Sweetspot Similarity factory
[ https://issues.apache.org/jira/browse/SOLR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832711#action_12832711 ] Kevin Osborn commented on SOLR-1365: I am finally getting back around to this. And I am having trouble implementing SolrCoreAware. As The SolrResourceLoader has a method called assertAwareCompatibility which throws an exception my class does not extend SolrRequestHandler, QueryResponseWriter, SearchComponent, or UpdateRequestProcessorFactory. Am I missing anything? Add configurable Sweetspot Similarity factory - Key: SOLR-1365 URL: https://issues.apache.org/jira/browse/SOLR-1365 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Kevin Osborn Priority: Minor Fix For: 1.5 Attachments: SOLR-1365.patch This is some code that I wrote a while back. Normally, if you use SweetSpotSimilarity, you are going to make it do something useful by extending SweetSpotSimilarity. So, instead, I made a factory class and an configurable SweetSpotSimilarty. There are two classes. SweetSpotSimilarityFactory reads the parameters from schema.xml. It then creates an instance of VariableSweetSpotSimilarity, which is my custom SweetSpotSimilarity class. In addition to the standard functions, it also handles dynamic fields. So, in schema.xml, you could have something like this: similarity class=org.apache.solr.schema.SweetSpotSimilarityFactory bool name=useHyperbolicTftrue/bool float name=hyperbolicTfFactorsMin1.0/float float name=hyperbolicTfFactorsMax1.5/float float name=hyperbolicTfFactorsBase1.3/float float name=hyperbolicTfFactorsXOffset2.0/float int name=lengthNormFactorsMin1/int int name=lengthNormFactorsMax1/int float name=lengthNormFactorsSteepness0.5/float int name=lengthNormFactorsMin_description2/int int name=lengthNormFactorsMax_description9/int float name=lengthNormFactorsSteepness_description0.2/float int name=lengthNormFactorsMin_supplierDescription_*2/int int name=lengthNormFactorsMax_supplierDescription_*7/int float name=lengthNormFactorsSteepness_supplierDescription_*0.4/float /similarity So, now everything is in a config file instead of having to create your own subclass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1365) Add configurable Sweetspot Similarity factory
[ https://issues.apache.org/jira/browse/SOLR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744682#action_12744682 ] Kevin Osborn commented on SOLR-1365: Thanks for the comments. I'll make the changes for Erik's suggestions and come up with some tests. If it gets into 1.4, great. If not, then it is not a huge deal since this is already production code for us. But, if it could be put into the main code base, then even better. Add configurable Sweetspot Similarity factory - Key: SOLR-1365 URL: https://issues.apache.org/jira/browse/SOLR-1365 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Kevin Osborn Priority: Minor Fix For: 1.5 Attachments: SOLR-1365.patch This is some code that I wrote a while back. Normally, if you use SweetSpotSimilarity, you are going to make it do something useful by extending SweetSpotSimilarity. So, instead, I made a factory class and an configurable SweetSpotSimilarty. There are two classes. SweetSpotSimilarityFactory reads the parameters from schema.xml. It then creates an instance of VariableSweetSpotSimilarity, which is my custom SweetSpotSimilarity class. In addition to the standard functions, it also handles dynamic fields. So, in schema.xml, you could have something like this: similarity class=org.apache.solr.schema.SweetSpotSimilarityFactory bool name=useHyperbolicTftrue/bool float name=hyperbolicTfFactorsMin1.0/float float name=hyperbolicTfFactorsMax1.5/float float name=hyperbolicTfFactorsBase1.3/float float name=hyperbolicTfFactorsXOffset2.0/float int name=lengthNormFactorsMin1/int int name=lengthNormFactorsMax1/int float name=lengthNormFactorsSteepness0.5/float int name=lengthNormFactorsMin_description2/int int name=lengthNormFactorsMax_description9/int float name=lengthNormFactorsSteepness_description0.2/float int name=lengthNormFactorsMin_supplierDescription_*2/int int name=lengthNormFactorsMax_supplierDescription_*7/int float name=lengthNormFactorsSteepness_supplierDescription_*0.4/float /similarity So, now everything is in a config file instead of having to create your own subclass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1365) Add configurable Sweetspot Similarity factory
Add configurable Sweetspot Similarity factory - Key: SOLR-1365 URL: https://issues.apache.org/jira/browse/SOLR-1365 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Kevin Osborn Priority: Minor Fix For: 1.4 This is some code that I wrote a while back. Normally, if you use SweetSpotSimilarity, you are going to make it do something useful by extending SweetSpotSimilarity. So, instead, I made a factory class and an configurable SweetSpotSimilarty. There are two classes. SweetSpotSimilarityFactory reads the parameters from schema.xml. It then creates an instance of VariableSweetSpotSimilarity, which is my custom SweetSpotSimilarity class. In addition to the standard functions, it also handles dynamic fields. So, in schema.xml, you could have something like this: similarity class=org.apache.solr.schema.SweetSpotSimilarityFactory bool name=useHyperbolicTftrue/bool float name=hyperbolicTfFactorsMin1.0/float float name=hyperbolicTfFactorsMax1.5/float float name=hyperbolicTfFactorsBase1.3/float float name=hyperbolicTfFactorsXOffset2.0/float int name=lengthNormFactorsMin1/int int name=lengthNormFactorsMax1/int float name=lengthNormFactorsSteepness0.5/float int name=lengthNormFactorsMin_description2/int int name=lengthNormFactorsMax_description9/int float name=lengthNormFactorsSteepness_description0.2/float int name=lengthNormFactorsMin_supplierDescription_*2/int int name=lengthNormFactorsMax_supplierDescription_*7/int float name=lengthNormFactorsSteepness_supplierDescription_*0.4/float /similarity So, now everything is in a config file instead of having to create your own subclass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1365) Add configurable Sweetspot Similarity factory
[ https://issues.apache.org/jira/browse/SOLR-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12744376#action_12744376 ] Kevin Osborn commented on SOLR-1365: Thanks for the feedback. I looked at IndexSchema. It seems like the only useful function in my case is using isDynamicField vs. seeing if the field name ends with a *. But also is SimilarityFactory allowed to implement SolrCoreAware? I'm not too familiar with this interface, but my initial research shows that only SolrRequestHandler, QueryResponseWriter, SearchComponent, or UpdateRequestProcessorFactory may implement SolrCoreAware. Is this correct? Add configurable Sweetspot Similarity factory - Key: SOLR-1365 URL: https://issues.apache.org/jira/browse/SOLR-1365 Project: Solr Issue Type: New Feature Affects Versions: 1.3 Reporter: Kevin Osborn Priority: Minor Fix For: 1.4 Attachments: SOLR-1365.patch This is some code that I wrote a while back. Normally, if you use SweetSpotSimilarity, you are going to make it do something useful by extending SweetSpotSimilarity. So, instead, I made a factory class and an configurable SweetSpotSimilarty. There are two classes. SweetSpotSimilarityFactory reads the parameters from schema.xml. It then creates an instance of VariableSweetSpotSimilarity, which is my custom SweetSpotSimilarity class. In addition to the standard functions, it also handles dynamic fields. So, in schema.xml, you could have something like this: similarity class=org.apache.solr.schema.SweetSpotSimilarityFactory bool name=useHyperbolicTftrue/bool float name=hyperbolicTfFactorsMin1.0/float float name=hyperbolicTfFactorsMax1.5/float float name=hyperbolicTfFactorsBase1.3/float float name=hyperbolicTfFactorsXOffset2.0/float int name=lengthNormFactorsMin1/int int name=lengthNormFactorsMax1/int float name=lengthNormFactorsSteepness0.5/float int name=lengthNormFactorsMin_description2/int int name=lengthNormFactorsMax_description9/int float name=lengthNormFactorsSteepness_description0.2/float int name=lengthNormFactorsMin_supplierDescription_*2/int int name=lengthNormFactorsMax_supplierDescription_*7/int float name=lengthNormFactorsSteepness_supplierDescription_*0.4/float /similarity So, now everything is in a config file instead of having to create your own subclass. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-432) Add accessor functions to QueryResultsKey
Add accessor functions to QueryResultsKey - Key: SOLR-432 URL: https://issues.apache.org/jira/browse/SOLR-432 Project: Solr Issue Type: New Feature Components: search Reporter: Kevin Osborn Priority: Minor We need to add accessor functions to QueryResultsKey. In our custom regenerator, we need to get the query, filter and sort data items. The only accessible object we have is the QueryResultsKey object. I then added accessor functions for SFields and NC_Flags even though I don't need them in order to complete the interface. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-431) Add the ability to disable XML escaping in XMLWriter
Add the ability to disable XML escaping in XMLWriter Key: SOLR-431 URL: https://issues.apache.org/jira/browse/SOLR-431 Project: Solr Issue Type: New Feature Components: search Reporter: Kevin Osborn Priority: Minor Attachments: XMLWriter.diff This is definitely not the prettiest way to do things, but it is by far the simplest. In April, 2006, Erik Hatcher added a fix to Solr that properly escaped all XML attributes in the response. However, we have a specific instance where we do not want to escape the XML. We are injecting some additional elements into the XML. The escaping function, however, escapes these XML elements. So, I would like to add an additional XMLWriter.writeResponse function that has a boolean flag to turn off the escaping function. I will still keep the current signature, so nothing should break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-243) Create a hook to allow custome code to create custome index readers
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549609
]
Kevin Osborn commented on SOLR-243:
---
We used this patch with great success. We have a custom multiindex reader. This
patch allowed us to just plug in our changes without resorting to hack up the
base Solr code.
Create a hook to allow custome code to create custome index readers
---
Key: SOLR-243
URL: https://issues.apache.org/jira/browse/SOLR-243
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.3
Environment: Solr core
Reporter: John Wang
Fix For: 1.3
Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
indexReaderFactory.patch
I have a customized IndexReader and I want to write a Solr plugin to use my
derived IndexReader implementation. Currently IndexReader instantiation is
hard coded to be:
IndexReader.open(path)
It would be really useful if this is done thru a plugable factory that can be
configured, e.g. IndexReaderFactory
interface IndexReaderFactory{
IndexReader newReader(String name,String path);
}
the default implementation would just return: IndexReader.open(path)
And in the newSearcher and getSearcher methods in SolrCore class can call the
current factory implementation to get the IndexReader instance and then build
the SolrIndexSearcher by passing in the reader.
It would be really nice to add this improvement soon (This seems to be a
trivial addition) as our project really depends on this.
Thanks
-John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-429) Add remove function to LRUCache
[
https://issues.apache.org/jira/browse/SOLR-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Osborn resolved SOLR-429.
---
Resolution: Fixed
Add remove function to LRUCache
---
Key: SOLR-429
URL: https://issues.apache.org/jira/browse/SOLR-429
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Kevin Osborn
Priority: Minor
Attachments: LRUCache.diff
I want to add the following function to LRUCache:
public void remove(Object key) {
synchronized(map) {
map.remove(key);
}
}
We need to periodically remove certain items from the cache on certain
requests. There is also already functions for get, put, and clear, so this
would complete the interface.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-429) Add remove function to LRUCache
[
https://issues.apache.org/jira/browse/SOLR-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Osborn updated SOLR-429:
--
Attachment: LRUCache.diff
Add remove function to LRUCache
---
Key: SOLR-429
URL: https://issues.apache.org/jira/browse/SOLR-429
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Kevin Osborn
Priority: Minor
Attachments: LRUCache.diff
I want to add the following function to LRUCache:
public void remove(Object key) {
synchronized(map) {
map.remove(key);
}
}
We need to periodically remove certain items from the cache on certain
requests. There is also already functions for get, put, and clear, so this
would complete the interface.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-431) Add the ability to disable XML escaping in XMLWriter
[ https://issues.apache.org/jira/browse/SOLR-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Osborn updated SOLR-431: -- Attachment: XMLWriter.diff Add the ability to disable XML escaping in XMLWriter Key: SOLR-431 URL: https://issues.apache.org/jira/browse/SOLR-431 Project: Solr Issue Type: New Feature Components: search Reporter: Kevin Osborn Priority: Minor Attachments: XMLWriter.diff This is definitely not the prettiest way to do things, but it is by far the simplest. In April, 2006, Erik Hatcher added a fix to Solr that properly escaped all XML attributes in the response. However, we have a specific instance where we do not want to escape the XML. We are injecting some additional elements into the XML. The escaping function, however, escapes these XML elements. So, I would like to add an additional XMLWriter.writeResponse function that has a boolean flag to turn off the escaping function. I will still keep the current signature, so nothing should break. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-429) Add remove function to LRUCache
Add remove function to LRUCache
---
Key: SOLR-429
URL: https://issues.apache.org/jira/browse/SOLR-429
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Kevin Osborn
Priority: Minor
Attachments: LRUCache.diff
I want to add the following function to LRUCache:
public void remove(Object key) {
synchronized(map) {
map.remove(key);
}
}
We need to periodically remove certain items from the cache on certain
requests. There is also already functions for get, put, and clear, so this
would complete the interface.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
