Re: [Solr Wiki] Update of HowToContribute by BertrandDelacretaz
On 4/30/07, Chris Hostetter [EMAIL PROTECTED] wrote: ...eh? ... the https port is open to everyone as well correct?.. Yes you're right, sorry about that. I have corrected http://wiki.apache.org/solr/HowToContribute, but left http instead of https in the svn co example. I think we usually advertise http over https for read-only access, as it causes less load on our servers, and possibly less firewall problems. -Bertrand
RE: The ability to offering offset of keyword in search result
Would you please give me an example? For example, I want to pick only fieldname=features from the query result Regards, David -Original Message- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 1:50 AM To: solr-dev@lucene.apache.org Subject: RE: The ability to offering offset of keyword in search result : It come up with another question: In response XML, can I suppress output : of result name= section? Because I only need highlight section. well ... not really, you can say rows=0 but then you won't get highlighting either. you can use fl to make it smaller though (just pick only one field, score or your uniqueKey perhaps) -Hoss
[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_12492902 ] Will Johnson commented on SOLR-20: -- the new api's work great, thanks! what's the plan for this going forward? id' like to start doing some work on this as it's rather critical to my current project and an are i've dealt with a lot in the past. assuming it's not getting dumped into org.apache.* land any time soon are you accepting patches to this code? if so i have some modifications to the api's that i think will make them easier to use (such as a method to set FacetParams on SolrQuery) and i'll even flush out the SolrServerTest for fun. also, i noticed that all the methods on SolrServer throw undeclared SolrExceptions which extends RuntimeException when things so south. should those throw some other sort of non-ignorable exception like a new SolrServerException? while it made coding/compiling easier to leave out all the usually required try's and catches it made running/debugging much less enjoyable. - will 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: [Solr Wiki] Update of HowToContribute by BertrandDelacretaz
: advertise http over https for read-only access, as it causes less load : on our servers, and possibly less firewall problems. M ... gotcha, that makes sense. -Hoss
Re: svn commit: r533978 - /lucene/solr/trunk/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilter.java
Ryan: this should probably be called out in the CHANGES.txt as a change in
behavior.
: Date: Tue, 01 May 2007 09:02:08 -
: From: [EMAIL PROTECTED]
: Reply-To: solr-dev@lucene.apache.org
: To: [EMAIL PROTECTED]
: Subject: svn commit: r533978 -
: /lucene/solr/trunk/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilt
: er.java
:
: Author: ryan
: Date: Tue May 1 02:02:08 2007
: New Revision: 533978
:
: URL: http://svn.apache.org/viewvc?view=revrev=533978
: Log:
: minor security fix. This makes sure you can't call paths that start with /
from /select
:
: This way, if you register a handler with /path and use path based
authentication, you can not sneak into it using:
:
: http://localhost:8983/solr/select/?qt=/updatestream.body=...
:
: Modified:
:
lucene/solr/trunk/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilter.java
:
: Modified:
lucene/solr/trunk/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilter.java
: URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilter.java?view=diffrev=533978r1=533977r2=533978
: ==
: ---
lucene/solr/trunk/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilter.java
(original)
: +++
lucene/solr/trunk/src/webapp/src/org/apache/solr/servlet/SolrDispatchFilter.java
Tue May 1 02:02:08 2007
: @@ -139,6 +139,9 @@
:if( /select.equals( path ) || /select/.equals( path ) ) {
: solrReq = parsers.parse( path, req );
: String qt = solrReq.getParams().get( SolrParams.QT );
: +if( qt != null qt.startsWith( / ) ) {
: + throw new SolrException( 400, Invalid query type. Do not use
/select to access: +qt);
: +}
: handler = core.getRequestHandler( qt );
: if( handler == null ) {
:throw new SolrException( 400, unknown handler: +qt);
:
:
-Hoss
Re: javadoc location?
found the problem in DirectSolrConnection.java, we were tickling this bug... http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5082928 ...my gut says not to try and manually fix the site right now, and just wait for the next nightly to take care of it -- mainly because i'm paranoid about messing it up. I certainly won't object if any other committers want to do it. : Date: Tue, 1 May 2007 10:52:16 -0700 (PDT) : From: Chris Hostetter [EMAIL PROTECTED] : Reply-To: solr-dev@lucene.apache.org : To: Solr Dev solr-dev@lucene.apache.org : Subject: Re: javadoc location? : : : : goes to: : : http://lucene.apache.org/solr/api/index.html (404) : : : : we should probably fix that! : : The link is correct, that's where they are suppose to be -- the : problem seems to be that buildingthe javadocs is currently broken : : When i run ant javadoc locally i'm getting a bunch of warnings and : errors, the most significant seems to be... : : [javadoc] Building index for all the packages and classes... : [javadoc] /home/chrish/svn/solr/src/java/org/apache/solr/util/ContentStreamBase.java:52: warning - @Link is an unknown tag -- same as a known tag except for case. : [javadoc] java.util.MissingResourceException: Can't find resource for bundle com.sun.tools.doclets.formats.html.resources.standard, key doclet.malformed_html_link_tag : [javadoc] at java.util.ResourceBundle.getObject(ResourceBundle.java:326) : [javadoc] at java.util.ResourceBundle.getString(ResourceBundle.java:286) : [javadoc] at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:114) : [javadoc] at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:92) : [javadoc] at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.getText(MessageRetriever.java:81) : [javadoc] at com.sun.tools.doclets.internal.toolkit.util.MessageRetriever.warning(MessageRetriever.java:290) : [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.redirectRelativeLinks(HtmlDocletWriter.java:1526) : [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.commentTagsToString(HtmlDocletWriter.java:1438) : [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printCommentTags(HtmlDocletWriter.java:1397) : [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1370) : [javadoc] at com.sun.tools.doclets.formats.html.HtmlDocletWriter.printSummaryComment(HtmlDocletWriter.java:1366) : [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printComment(AbstractIndexWriter.java:192) : [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.printDescription(AbstractIndexWriter.java:164) : [javadoc] at com.sun.tools.doclets.formats.html.AbstractIndexWriter.generateContents(AbstractIndexWriter.java:89) : [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generateIndexFile(SingleIndexWriter.java:76) : [javadoc] at com.sun.tools.doclets.formats.html.SingleIndexWriter.generate(SingleIndexWriter.java:52) : [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.generateOtherFiles(HtmlDoclet.java:103) : [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:122) : [javadoc] at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) : [javadoc] at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) : [javadoc] at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) : [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) : [javadoc] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) : [javadoc] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) : [javadoc] at java.lang.reflect.Method.invoke(Method.java:585) : [javadoc] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:269) : [javadoc] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:143) : [javadoc] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) : [javadoc] at com.sun.tools.javadoc.Start.begin(Start.java:128) : [javadoc] at com.sun.tools.javadoc.Main.execute(Main.java:41) : [javadoc] at com.sun.tools.javadoc.Main.main(Main.java:31) : : : : -Hoss : -Hoss
RE: The ability to offering offset of keyword in search result
It works! By the way, fl=field1+field2+ also works :-) -Original Message- From: Mike Klaas [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 02, 2007 1:40 AM To: solr-dev@lucene.apache.org Subject: Re: The ability to offering offset of keyword in search result On 5/1/07, David Xiao [EMAIL PROTECTED] wrote: Would you please give me an example? For example, I want to pick only fieldname=features from the query result Try something like: ?q=a+queryhl=truehl.fl=featuresfl=features -Mike
[jira] Commented: (SOLR-199) N-gram
[ https://issues.apache.org/jira/browse/SOLR-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492947 ] Hoss Man commented on SOLR-199: --- NGramTokenizerFactory is refering to constants from, and constructing an instance of, EdgeNGramTokenizer I'm also not crazy about some of the utilities being added to BaseTokenizerFactory .. at a minimum they need better names (like getStringArg) but i'm not really clear on what this is suppose to mean at all... protected int getInt(String name, int defaultVal, boolean useDefault) ...if i don't want to use the default, then what am i suppose to pass as the defaultVal? how about if we don't make any changes to BaseTokenizerFactory and just let subclasses that want convenience methods for dealing with args use MapSolrParams and the methods it supports? N-gram -- Key: SOLR-199 URL: https://issues.apache.org/jira/browse/SOLR-199 Project: Solr Issue Type: New Feature Components: search Reporter: Adam Hiatt Priority: Trivial Attachments: SOLR-81-ngram.patch This tracks the creation of a patch that adds the n-gram/edge n-gram tokenizing functionality that was initially part of SOLR-81 (spell checking). This was taken out b/c the lucene SpellChecker class removed this dependency. None-the-less, I think this is useful functionality and the addition is trivial. How does everyone feel about such an addition? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-199) N-gram
: NGramTokenizerFactory is refering to constants from, and constructing : an instance of, EdgeNGramTokenizer : Are you saying that this worries you b/c it is referenced in the example : schema and will thus break without the lucene-analyzers package? I do : agree that this example should probably be taken out for the time being : (at the least). no, i'm saying that the class NGramTokenizerFactory does not produce instances of NGramTokenizer ... it produces instances of EdgeNGramTokenizer (which is coincidently what EdgeNGramTokenizerFactory does as well) -Hoss
Re: [jira] Commented: (SOLR-199) N-gram
Good point. That looks flat out broken. -- Adam On May 1, 2007, at 2:16 PM, Chris Hostetter wrote: : NGramTokenizerFactory is refering to constants from, and constructing : an instance of, EdgeNGramTokenizer : Are you saying that this worries you b/c it is referenced in the example : schema and will thus break without the lucene-analyzers package? I do : agree that this example should probably be taken out for the time being : (at the least). no, i'm saying that the class NGramTokenizerFactory does not produce instances of NGramTokenizer ... it produces instances of EdgeNGramTokenizer (which is coincidently what EdgeNGramTokenizerFactory does as well) -Hoss
[jira] Updated: (SOLR-199) N-gram
[ https://issues.apache.org/jira/browse/SOLR-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hiatt updated SOLR-199: Attachment: SOLR-199-n-gram.patch This is the new patch, not just cut out of SOLR-81... I removed references to the Base class and fixed the edge n-gram bug. N-gram -- Key: SOLR-199 URL: https://issues.apache.org/jira/browse/SOLR-199 Project: Solr Issue Type: New Feature Components: search Reporter: Adam Hiatt Priority: Trivial Attachments: SOLR-199-n-gram.patch, SOLR-81-ngram.patch This tracks the creation of a patch that adds the n-gram/edge n-gram tokenizing functionality that was initially part of SOLR-81 (spell checking). This was taken out b/c the lucene SpellChecker class removed this dependency. None-the-less, I think this is useful functionality and the addition is trivial. How does everyone feel about such an addition? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-115) replace BooleanQuery.getClauses() with clauses()
[ https://issues.apache.org/jira/browse/SOLR-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-115: -- Attachment: SOLR-115.patch audited all of our uses of getClausese() ... they were mainly for iteration, and a few to get length/size ... all good candidates for replacing with clauses() will commit this patch in a few days baring any objections. replace BooleanQuery.getClauses() with clauses() Key: SOLR-115 URL: https://issues.apache.org/jira/browse/SOLR-115 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Priority: Minor Attachments: SOLR-115.patch Basically, take advantage of http://issues.apache.org/jira/browse/LUCENE-745 after we update lucene versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-115) replace BooleanQuery.getClauses() with clauses()
[ https://issues.apache.org/jira/browse/SOLR-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reassigned SOLR-115: - Assignee: Hoss Man replace BooleanQuery.getClauses() with clauses() Key: SOLR-115 URL: https://issues.apache.org/jira/browse/SOLR-115 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Assigned To: Hoss Man Priority: Minor Attachments: SOLR-115.patch Basically, take advantage of http://issues.apache.org/jira/browse/LUCENE-745 after we update lucene versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-223) SolrQueryParser should do more error checking
SolrQueryParser should do more error checking - Key: SOLR-223 URL: https://issues.apache.org/jira/browse/SOLR-223 Project: Solr Issue Type: Improvement Components: search Reporter: Hoss Man as recently mentioned on the mailing list, when using SolrQueryParser a simple term query will fail if the field name used is not a valid field according to the schema (because it consults the IndexSchema to get the Analyzer) -- but a wildcard, fuzzy, or prefix query will not trigger such an error (because no analysis is done) we should make SolrQueryParser more aware of these types of errors. we should probably also make it more aware of when fields aren't indexed, attempting to query on them should be an error as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (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 ] Hoss Man reassigned SOLR-217: - Assignee: Hoss Man 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 Assigned To: Hoss Man Priority: Minor Fix For: 1.2 Attachments: ignoreNonIndexedNonStoredField.patch, ignoreUnnamedFields.patch, ignoreUnnamedFields_v3.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.
[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 ] Hoss Man updated SOLR-217: -- Attachment: ignoreUnnamedFields_v3.patch added a simple test to the existing patch. one thing to note is that this will result in the field being ignored if you try to query on it as well ... but this is a more general problem of qhat to do when people try to query on an unindexed field (see SOLR-223) will commit in a day or so barring objections 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, 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.
[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_12493006 ] Ryan McKinley commented on SOLR-20: --- great! Any feedback/help would be wonderful. I hope it is not *too* long before this can enter solr trunk, but it will first need two solr1.3 additions SOLR-193 and SOLR-135, until then I can apply any patches necessary. Re RuntimeException vs SolrServerException, I'm not sure the best choice. Earlier versions had a client exception and server exception, but in practice those got lumped together (in my case) anyway. I ended up just using SolrException because it is there. 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.
