Re: svn commit: r533596 - /lucene/solr/trunk/src/java/org/apache/solr/handler/admin/PropertiesRequestHandler.java
On 4/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ...Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/admin/PropertiesRequestHandler.java ... + public static NamedListString toNamedList( Properties p ) IIUC this method is of general use, it might be good to move it to a utility class, org.apache.solr.util.NamedListUtils maybe? -Bertrand
[jira] Commented: (SOLR-217) schema option to ignore unused fields
[ https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492664 ] Will Johnson commented on SOLR-217: --- since we now have required fields (http://issues.apache.org/jira/browse/SOLR-181) any chance we can have ignored fields as well? let me know if something else needs to be done to the patch but as far as i can tell the code works and people seem to agree that it's the correct approach. - will schema option to ignore unused fields - Key: SOLR-217 URL: https://issues.apache.org/jira/browse/SOLR-217 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.2 Reporter: Will Johnson Priority: Minor Fix For: 1.2 Attachments: ignoreNonIndexedNonStoredField.patch, ignoreUnnamedFields.patch One thing that causes problems for me (and i assume others) is that Solr is schema-strict in that unknown fields cause solr to throw exceptions and there is no way to relax this constraint. this can cause all sorts of serious problems if you have automated feeding applications that do things like SELECT * FROM table1 or where you want to add other fields to the document for processing purposes before sending them to solr but don't want to deal with 'cleanup' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-217) schema option to ignore unused fields
[ https://issues.apache.org/jira/browse/SOLR-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-217: -- Attachment: ignoreUnnamedFields_v3.patch v3 patch included. this version of the patch also takes into account the suggested example/solr/conf/schema.xml changes. schema option to ignore unused fields - Key: SOLR-217 URL: https://issues.apache.org/jira/browse/SOLR-217 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.2 Reporter: Will Johnson Priority: Minor Fix For: 1.2 Attachments: ignoreNonIndexedNonStoredField.patch, ignoreUnnamedFields.patch, ignoreUnnamedFields_v3.patch One thing that causes problems for me (and i assume others) is that Solr is schema-strict in that unknown fields cause solr to throw exceptions and there is no way to relax this constraint. this can cause all sorts of serious problems if you have automated feeding applications that do things like SELECT * FROM table1 or where you want to add other fields to the document for processing purposes before sending them to solr but don't want to deal with 'cleanup' -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
apachecon bound (where's yonik?)
Hey dev's, I'm at ApacheCon this week, and London after that, so I'll be mostly out-of-touch through May 8th. (My wife is coming with me... no late nights hacking Solr ;-) -Yonik
[jira] Updated: (SOLR-215) Multiple Solr Cores
[ https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-215: --- Attachment: solr-trunk-533775.patch The patch as it stands still requires some refactoring 'above' the Java core. Although the 'single core' feature has been retained (aka the static SolrCore.getCore), the SolrConfig.config could not; the admin servlet has been modified accordingly. Updated patch based on latest trunk. Multiple Solr Cores --- Key: SOLR-215 URL: https://issues.apache.org/jira/browse/SOLR-215 Project: Solr Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Attachments: solr-trunk-533775.patch, solr-trunk-src.patch Allow multiple cores in one web-application (or one class-loader): This allows to have multiple cores created from different config schema in the same application. The side effect is that this also allows different indexes. Some background on the 'whys': http://www.nabble.com/Multiple-Solr-Cores-tf3608399.html#a10082201 http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html#a9981355 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-20) A simple Java client for updating and searching
[ https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492700 ] Will Johnson commented on SOLR-20: -- the trunk version at http://solrstuff.org/svn/solrj/ seems to be missing a dependency and a copy of SolrParams. ant returns compile: [javac] Compiling 40 source files to C:\data\workspace\solrj\bin [javac] C:\data\workspace\solrj\src\org\apache\solr\client\solrj\impl\XMLResponseParser.java:10: package javax.xml.stream does not exist [javac] import javax.xml.stream.XMLInputFactory; [javac] C:\data\workspace\solrj\src\org\apache\solr\client\solrj\query\SolrQuery.java:10: cannot find symbol [javac] symbol : class SolrParams [javac] location: package org.apache.solr.util [javac] import org.apache.solr.util.SolrParams; A simple Java client for updating and searching --- Key: SOLR-20 URL: https://issues.apache.org/jira/browse/SOLR-20 Project: Solr Issue Type: New Feature Components: clients - java Environment: all Reporter: Darren Erik Vengroff Priority: Minor Attachments: DocumentManagerClient.java, DocumentManagerClient.java, solr-client-java-2.zip.zip, solr-client-java.zip, solr-client-sources.jar, solr-client.zip, solr-client.zip, solr-client.zip, solrclient_addqueryfacet.zip, SolrClientException.java, SolrServerException.java I wrote a simple little client class that can connect to a Solr server and issue add, delete, commit and optimize commands using Java methods. I'm posting here for review and comments as suggested by Yonik. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-215) Multiple Solr Cores
[ https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-215: --- Description: Allow multiple cores in one web-application (or one class-loader): This allows to have multiple cores created from different config schema in the same application. The side effect is that this also allows different indexes. Implementation notes for the patch: The patch allows to have multiple 'named' cores in the same application. The current single core behavior has been retained - the core named 'null' - but code could not be kept 100% compatible. (In particular, Solrconfig.config is gone; SolrCore.getCore() is still here though). A few classes were only existing as singletons and have thus been refactored. The Config class feature-set has been narrowed to class loading relative to the installation (lib) directory; The SolrConfig class feature-set has evolved towards the 'solr config' part, caching frequently accessed parameters; The IndexSchema class uses a SolrConfig instance; there are a few parameters in the configuration that pertain to indexing that were needed. The SolrCore is built from a SolrConfig an IndexSchema. The creation of a core has become: //create a configuration SolrConfig config = SolrConfig.createConfiguration(solrconfig.xml); //create a schema IndexSchema schema = new IndexSchema(config, schema0.xml); //create a core from the 2 other. SolrCore core = new SolrCore(core0, /path/to/index, config, schema); //Accessing a core: SolrCore core = SolrCore.getCore(core0); There are few other changes mainly related to passing through constructors the SolrCore/SolrConfig used. Some background on the 'whys': http://www.nabble.com/Multiple-Solr-Cores-tf3608399.html#a10082201 http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html#a9981355 was: Allow multiple cores in one web-application (or one class-loader): This allows to have multiple cores created from different config schema in the same application. The side effect is that this also allows different indexes. Some background on the 'whys': http://www.nabble.com/Multiple-Solr-Cores-tf3608399.html#a10082201 http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html#a9981355 Multiple Solr Cores --- Key: SOLR-215 URL: https://issues.apache.org/jira/browse/SOLR-215 Project: Solr Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Attachments: solr-trunk-533775.patch, solr-trunk-src.patch Allow multiple cores in one web-application (or one class-loader): This allows to have multiple cores created from different config schema in the same application. The side effect is that this also allows different indexes. Implementation notes for the patch: The patch allows to have multiple 'named' cores in the same application. The current single core behavior has been retained - the core named 'null' - but code could not be kept 100% compatible. (In particular, Solrconfig.config is gone; SolrCore.getCore() is still here though). A few classes were only existing as singletons and have thus been refactored. The Config class feature-set has been narrowed to class loading relative to the installation (lib) directory; The SolrConfig class feature-set has evolved towards the 'solr config' part, caching frequently accessed parameters; The IndexSchema class uses a SolrConfig instance; there are a few parameters in the configuration that pertain to indexing that were needed. The SolrCore is built from a SolrConfig an IndexSchema. The creation of a core has become: //create a configuration SolrConfig config = SolrConfig.createConfiguration(solrconfig.xml); //create a schema IndexSchema schema = new IndexSchema(config, schema0.xml); //create a core from the 2 other. SolrCore core = new SolrCore(core0, /path/to/index, config, schema); //Accessing a core: SolrCore core = SolrCore.getCore(core0); There are few other changes mainly related to passing through constructors the SolrCore/SolrConfig used. Some background on the 'whys': http://www.nabble.com/Multiple-Solr-Cores-tf3608399.html#a10082201 http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html#a9981355 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-20) A simple Java client for updating and searching
[ https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492716 ] Ryan McKinley commented on SOLR-20: --- aaah, It was compiling with java 6. I just added stax-api-1.0.jar and cleaned up some imports, it should run on java 5 now. A simple Java client for updating and searching --- Key: SOLR-20 URL: https://issues.apache.org/jira/browse/SOLR-20 Project: Solr Issue Type: New Feature Components: clients - java Environment: all Reporter: Darren Erik Vengroff Priority: Minor Attachments: DocumentManagerClient.java, DocumentManagerClient.java, solr-client-java-2.zip.zip, solr-client-java.zip, solr-client-sources.jar, solr-client.zip, solr-client.zip, solr-client.zip, solrclient_addqueryfacet.zip, SolrClientException.java, SolrServerException.java I wrote a simple little client class that can connect to a Solr server and issue add, delete, commit and optimize commands using Java methods. I'm posting here for review and comments as suggested by Yonik. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r533596 - /lucene/solr/trunk/src/java/org/apache/solr/handler/admin/PropertiesRequestHandler.java
Bertrand Delacretaz wrote: On 4/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ...Modified: lucene/solr/trunk/src/java/org/apache/solr/handler/admin/PropertiesRequestHandler.java ... + public static NamedListString toNamedList( Properties p ) IIUC this method is of general use, it might be good to move it to a utility class, org.apache.solr.util.NamedListUtils maybe? Actually, I realized Properties implements Map so it doesn't need any special!
[jira] Commented: (SOLR-215) Multiple Solr Cores
[ https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492743 ] Hoss Man commented on SOLR-215: --- I'm confused ... why is this issue Resolved:Fixed ? Multiple Solr Cores --- Key: SOLR-215 URL: https://issues.apache.org/jira/browse/SOLR-215 Project: Solr Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Attachments: solr-trunk-533775.patch, solr-trunk-src.patch Allow multiple cores in one web-application (or one class-loader): This allows to have multiple cores created from different config schema in the same application. The side effect is that this also allows different indexes. Implementation notes for the patch: The patch allows to have multiple 'named' cores in the same application. The current single core behavior has been retained - the core named 'null' - but code could not be kept 100% compatible. (In particular, Solrconfig.config is gone; SolrCore.getCore() is still here though). A few classes were only existing as singletons and have thus been refactored. The Config class feature-set has been narrowed to class loading relative to the installation (lib) directory; The SolrConfig class feature-set has evolved towards the 'solr config' part, caching frequently accessed parameters; The IndexSchema class uses a SolrConfig instance; there are a few parameters in the configuration that pertain to indexing that were needed. The SolrCore is built from a SolrConfig an IndexSchema. The creation of a core has become: //create a configuration SolrConfig config = SolrConfig.createConfiguration(solrconfig.xml); //create a schema IndexSchema schema = new IndexSchema(config, schema0.xml); //create a core from the 2 other. SolrCore core = new SolrCore(core0, /path/to/index, config, schema); //Accessing a core: SolrCore core = SolrCore.getCore(core0); There are few other changes mainly related to passing through constructors the SolrCore/SolrConfig used. Some background on the 'whys': http://www.nabble.com/Multiple-Solr-Cores-tf3608399.html#a10082201 http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html#a9981355 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SOLR-215) Multiple Solr Cores
[ https://issues.apache.org/jira/browse/SOLR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic reopened SOLR-215: --- I think Henri accidentally resolved this. Reopening. Btw. I'm *very* interested in serving multiple indices under a single Solr instance, possibly even embedded as described on the wiki or in LUCENE-212. I may not find the time to look at the patch before next week, though. Multiple Solr Cores --- Key: SOLR-215 URL: https://issues.apache.org/jira/browse/SOLR-215 Project: Solr Issue Type: Improvement Reporter: Henri Biestro Priority: Minor Attachments: solr-trunk-533775.patch, solr-trunk-src.patch Allow multiple cores in one web-application (or one class-loader): This allows to have multiple cores created from different config schema in the same application. The side effect is that this also allows different indexes. Implementation notes for the patch: The patch allows to have multiple 'named' cores in the same application. The current single core behavior has been retained - the core named 'null' - but code could not be kept 100% compatible. (In particular, Solrconfig.config is gone; SolrCore.getCore() is still here though). A few classes were only existing as singletons and have thus been refactored. The Config class feature-set has been narrowed to class loading relative to the installation (lib) directory; The SolrConfig class feature-set has evolved towards the 'solr config' part, caching frequently accessed parameters; The IndexSchema class uses a SolrConfig instance; there are a few parameters in the configuration that pertain to indexing that were needed. The SolrCore is built from a SolrConfig an IndexSchema. The creation of a core has become: //create a configuration SolrConfig config = SolrConfig.createConfiguration(solrconfig.xml); //create a schema IndexSchema schema = new IndexSchema(config, schema0.xml); //create a core from the 2 other. SolrCore core = new SolrCore(core0, /path/to/index, config, schema); //Accessing a core: SolrCore core = SolrCore.getCore(core0); There are few other changes mainly related to passing through constructors the SolrCore/SolrConfig used. Some background on the 'whys': http://www.nabble.com/Multiple-Solr-Cores-tf3608399.html#a10082201 http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html#a9981355 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r532982 - in /lucene/solr/trunk/src/java/org/apache/solr/handler/admin: LukeRequestHandler.java PluginInfoHandler.java PropertiesRequestHandler.java SystemInfoHandler.java ThreadDumpHa
: Log: : adding svn:keywords Ryan (et al.), you may want to check out the suggested subversion configs on the wiki to make this easier in the future... http://wiki.apache.org/solr/CommitterInfo -Hoss
[jira] Commented: (SOLR-219) Determine if prefix, wildcard, fuzzy queries should be lowercased
[ https://issues.apache.org/jira/browse/SOLR-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492751 ] Hoss Man commented on SOLR-219: --- I'm not opposed to an approach like this ... but it seems like a slippery slope to go down, with hard coded test strings, and assumptions about how analyzers will behave in all cases beased on one test case. perhaps a simpler approach that requires less guess work would be adding the ability for Fields and FieldTypes to container arbitrary key/val pair options that can be accessed as a map, and document that SolrQueryParser looks at some of these to make query parsing decisions? fieldType name=text_ws class=solr.TextField positionIncrementGap=100 analyzer tokenizer class=solr.WhitespaceTokenizerFactory/ /analyzer option name=lowerCaseForPrefixfalse/option /fieldType Determine if prefix, wildcard, fuzzy queries should be lowercased - Key: SOLR-219 URL: https://issues.apache.org/jira/browse/SOLR-219 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Priority: Minor Attachments: lowercase_prefix.patch Solr should be able to do the right thing when doing prefix/wildcard/fuzzy queries on fields with respect to lowercasing or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-55) TEST of Jira email integration
[ https://issues.apache.org/jira/browse/SOLR-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-55. -- Resolution: Fixed haven't done anything with this in a while, and i want an issue to test resolving with, so bye bye SOLR-55 TEST of Jira email integration -- Key: SOLR-55 URL: https://issues.apache.org/jira/browse/SOLR-55 Project: Solr Issue Type: Task Reporter: Hoss Man Assigned To: Hoss Man Priority: Trivial Test issue to experiement with jira email integration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: On Closing JIRA issues
: hymmm, i only did one action: Resolve Issue - Fixed and that sets : the status to Closed with a resolution Fixed : : Is there something i'm missing? in the Workflow area there are usually two links Resolve Issue and Close Issue ... both of which take you to nearly identicle screens for stating the Resolution, fix version, asignee, and a comment ... i'm guessing you just hit Close Issue' inadvertantly. -Hoss
[jira] Commented: (SOLR-219) Determine if prefix, wildcard, fuzzy queries should be lowercased
[ https://issues.apache.org/jira/browse/SOLR-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492779 ] Michael Pelz-Sherman commented on SOLR-219: --- IMHO, if this is implemented, it should be optional (via schema configuration) and NOT the default behavior. I personally much prefer having direct control over query case sensitivity on a per-field basis, thanks! Determine if prefix, wildcard, fuzzy queries should be lowercased - Key: SOLR-219 URL: https://issues.apache.org/jira/browse/SOLR-219 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Priority: Minor Attachments: lowercase_prefix.patch Solr should be able to do the right thing when doing prefix/wildcard/fuzzy queries on fields with respect to lowercasing or not. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Solr Wiki] Update of HowToContribute by BertrandDelacretaz
: - svn checkout https://svn.apache.org/repos/asf/lucene/solr/trunk : + svn checkout http://svn.apache.org/repos/asf/lucene/solr/trunk : }}} : + : + Checking out over http (as opposed to https) is open to anyone, but won't allow you to commit your changes. That's where patches come in, keep on reading! eh? ... the https port is open to everyone as well correct? [EMAIL PROTECTED]:~/tmp$ mkdir tmp-fake-svn-config [EMAIL PROTECTED]:~/tmp$ svn --config-dir tmp-fake-svn-config list https://svn.apache.org/repos/asf/lucene/solr/trunk CHANGES.txt KEYS.txt ... -Hoss
