Re: svn commit: r547493 - in /lucene/solr/trunk: ./ src/java/org/apache/solr/common/ src/java/org/apache/solr/schema/ src/java/org/apache/solr/update/ src/test/org/apache/solr/common/
Ryan: independent of the javadoc comment on loadStoredFields about it
possibly being refactored somwhere else, the build method doesn't really
match the semantics of the DocumentBuilder class.
i think i commented in SOLR-193 that it didn't belove in DOcumentBuilder,
i realize now that it's there to take advantage of the addField method --
it might make sense to refactor that logic that into a static helper
method that can be used by another class -- but even if we don't, the
logic in the build method should probably follow the same workflow as the
other methods, calling startDoc() and returning the document directly is a
bit out of character for that class.
perhaps instead of a build method that returns a document, it just just be
a void processInputDocument method with usage like...
DocumentBuilder b = ;
for (SolrInputDocument i : ...) {
b.startDoc()
b.processInputDocument(i);
b.endDoc()
doSOmethingWith(b.getDoc());
}
: Modified:
lucene/solr/trunk/src/java/org/apache/solr/update/DocumentBuilder.java
: URL:
http://svn.apache.org/viewvc/lucene/solr/trunk/src/java/org/apache/solr/update/DocumentBuilder.java?view=diff&rev=547493&r1=547492&r2=547493
: ==
: --- lucene/solr/trunk/src/java/org/apache/solr/update/DocumentBuilder.java
(original)
: +++ lucene/solr/trunk/src/java/org/apache/solr/update/DocumentBuilder.java
Thu Jun 14 19:27:48 2007
: @@ -18,12 +18,17 @@
: package org.apache.solr.update;
:
: import java.util.ArrayList;
: +import java.util.Date;
: import java.util.HashMap;
: import java.util.List;
:
: import org.apache.lucene.document.Document;
: import org.apache.lucene.document.Field;
: +import org.apache.lucene.document.Fieldable;
: +import org.apache.solr.common.SolrDocument;
: import org.apache.solr.common.SolrException;
: +import org.apache.solr.common.SolrInputDocument;
: +import org.apache.solr.schema.DateField;
: import org.apache.solr.schema.IndexSchema;
: import org.apache.solr.schema.SchemaField;
:
: @@ -63,6 +68,12 @@
:+ ": first='" + oldValue + "' second='" + val + "'");
: }
:}
: +
: + if( doc == null ) {
: +throw new SolrException( SolrException.ErrorCode.SERVER_ERROR,
: +"must call startDoc() before adding fields!" );
: + }
: +
:// field.setBoost(boost);
:doc.add(field);
: }
: @@ -139,5 +150,66 @@
:
: Document ret = doc; doc=null;
: return ret;
: + }
: +
: + /**
: + * Build a lucene document from a SolrInputDocument
: + *
: + * @since solr 1.3
: + */
: + public Document build( SolrInputDocument doc )
: + {
: +this.startDoc();
: +
: +for( String name : doc.getFieldNames() ) {
: + Float boost = doc.getBoost( name );
: + if( boost == null ) {
: +boost = new Float( 1 );
: + }
: +
: + for( Object v : doc.getFieldValues( name ) ) {
: +if( v instanceof Date ) {
: + // Make sure to format dates
: + SchemaField sfield = schema.getField(name);
: + if( sfield.getType() instanceof DateField ) {
: +DateField df = (DateField)sfield.getType();
: +this.addField( name, df.toInternal( (Date)v )+'Z', boost );
: +continue;
: + }
: +}
: +this.addField( name, v==null ? null : v.toString(), boost );
: + }
: +}
: +
: +// set the full document boost
: +Document luceneDoc = this.getDoc();
: +if( doc.getBoost( null ) != null ) {
: + luceneDoc.setBoost( doc.getBoost( null ) );
: +}
: +return luceneDoc;
: + }
: +
: + /**
: + * Add fields from the solr document
: + *
: + * TODO: /!\ NOTE /!\ This semantics of this function are still in flux.
: + * Something somewhere needs to be able to fill up a SolrDocument from
: + * a lucene document - this is one place that may happen. It may also be
: + * moved to an independent function
: + *
: + * @since solr 1.3
: + */
: + public SolrDocument loadStoredFields( SolrDocument doc, Document luceneDoc
)
: + {
: +for( Object f : luceneDoc.getFields() ) {
: + Fieldable field = (Fieldable)f;
: + if( field.isStored() ) {
: +SchemaField sf = schema.getField( field.name() );
: +if( !schema.isCopyFieldTarget( sf ) ) {
: + doc.addField( field.name(), sf.getType().toObject( field ) );
: +}
: + }
: +}
: +return doc;
:}
: }
-Hoss
clover and hudson (and jetty) -- was Re: [jira] Commented: (SOLR-143) Support for PMD and Clover
: It might be best to just pursue the clover integration separately from since the biggest benefit of clover is likely to be modifying the nightly build to run it, and since we (may) have a problem with the nightly.sh script and the new unit tests ryan wrote that run jetty, perhaps now is a good time to consider switching to using hudson as our primary build integration system? (ie: turn off the nightly.sh cron, link to hudson for nightly builds, take over ownership of the Hudson SOlr configuration from the guy whose name I can't remember who orriginally set it all up for Hadoop, learn how to take advantage of some of hte cool Jira/patch hooks it aparently has, etc...) thoughts? -Hoss
[jira] Commented: (SOLR-143) Support for PMD and Clover
[ https://issues.apache.org/jira/browse/SOLR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505426 ] Hoss Man commented on SOLR-143: --- 1) i never got a chance to look into the license issues of including the XSLT for formating the PMD output in solr 2) since opening this issue, i have found better ways to do things with PMD instead of needing to run the analysis twice. It might be best to just pursue the clover integration separately from the PMD stuff since many people use IDEs that have "code inspectors" for doing PMD type stuff built into them. ... then we can revist PMD later if we want. > Support for PMD and Clover > -- > > Key: SOLR-143 > URL: https://issues.apache.org/jira/browse/SOLR-143 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man >Priority: Minor > Attachments: pmd-and-clover.diff, SOLR-143-CloverAndPMD.patch > > > had some time on a plane this weekend, so I adapted some of the clover hooks > from Java-Lucene to Solr's build.xml and also put in hooks for running PMD (a > bug pattern finding tool). > the PMD hook actually teste the PMD ruleset twice, once warning about any > violations, and once failing the build if any serious violations were found > ... the goal would be to hook this into the "ant test" target so you can't > successfully build if you have any serious rule violations. > i strarted with a custom ruleset based on some of the bigger rules from PMD > ... the theory being that as well clean up the code base we can add more > nit-picky rules if we want to :) > User is required to provide their own copy of PMD and/or clover on in an > ANT_LIB. Clover requires (ASF committer) license, PMD is freely available... > http://pmd.sourceforge.net/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-176) Add detailed timing data to query response output
[ https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-176: Attachment: dtiming.patch added javadocs for RTimer.java, and removed a superfluous line from SRH.java > Add detailed timing data to query response output > - > > Key: SOLR-176 > URL: https://issues.apache.org/jira/browse/SOLR-176 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.2 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: dtiming.patch, dtiming.patch, dtiming.patch, > dtiming.patch, RequesthandlerBase.patch > > > see > http://www.nabble.com/%27accumulate%27-copyField-for-faceting-tf3329986.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-176) Add detailed timing data to query response output
[ https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505397 ] Ryan McKinley commented on SOLR-176: > > Might it then make sense to wait until the search component thing is done? > Auto-timing everything would be easy. > Yes, i think so. but this is still useful for debuging in the meantime. (as a patch) Will's addition is independent, it adds average timing info to RequestHandler statistics > Add detailed timing data to query response output > - > > Key: SOLR-176 > URL: https://issues.apache.org/jira/browse/SOLR-176 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.2 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: dtiming.patch, dtiming.patch, dtiming.patch, > RequesthandlerBase.patch > > > see > http://www.nabble.com/%27accumulate%27-copyField-for-faceting-tf3329986.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-176) Add detailed timing data to query response output
[ https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505395 ] Ryan McKinley commented on SOLR-176: Will's RequesthandlerBase.patch addition is simple, straightforward, useful - i will add that now. > Add detailed timing data to query response output > - > > Key: SOLR-176 > URL: https://issues.apache.org/jira/browse/SOLR-176 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.2 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: dtiming.patch, dtiming.patch, dtiming.patch, > RequesthandlerBase.patch > > > see > http://www.nabble.com/%27accumulate%27-copyField-for-faceting-tf3329986.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-176) Add detailed timing data to query response output
[ https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505393 ] Mike Klaas commented on SOLR-176: - Might it then make sense to wait until the search component thing is done? Auto-timing everything would be easy. > Add detailed timing data to query response output > - > > Key: SOLR-176 > URL: https://issues.apache.org/jira/browse/SOLR-176 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.2 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: dtiming.patch, dtiming.patch, dtiming.patch, > RequesthandlerBase.patch > > > see > http://www.nabble.com/%27accumulate%27-copyField-for-faceting-tf3329986.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-176) Add detailed timing data to query response output
[ https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-176: --- Attachment: dtiming.patch * applies with trunk. * added timing info to StandardRequestHandler I think this will make lots of sense in the context of search components: http://www.nabble.com/search-components-%28plugins%29-tf3898040.html > Add detailed timing data to query response output > - > > Key: SOLR-176 > URL: https://issues.apache.org/jira/browse/SOLR-176 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.2 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: dtiming.patch, dtiming.patch, dtiming.patch, > RequesthandlerBase.patch > > > see > http://www.nabble.com/%27accumulate%27-copyField-for-faceting-tf3329986.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-143) Support for PMD and Clover
[ https://issues.apache.org/jira/browse/SOLR-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505372 ] Ryan McKinley commented on SOLR-143: what do you think about including this soon? With all the recent changes, it would be nice easily integrate with clover... > Support for PMD and Clover > -- > > Key: SOLR-143 > URL: https://issues.apache.org/jira/browse/SOLR-143 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man >Priority: Minor > Attachments: pmd-and-clover.diff, SOLR-143-CloverAndPMD.patch > > > had some time on a plane this weekend, so I adapted some of the clover hooks > from Java-Lucene to Solr's build.xml and also put in hooks for running PMD (a > bug pattern finding tool). > the PMD hook actually teste the PMD ruleset twice, once warning about any > violations, and once failing the build if any serious violations were found > ... the goal would be to hook this into the "ant test" target so you can't > successfully build if you have any serious rule violations. > i strarted with a custom ruleset based on some of the bigger rules from PMD > ... the theory being that as well clean up the code base we can add more > nit-picky rules if we want to :) > User is required to provide their own copy of PMD and/or clover on in an > ANT_LIB. Clover requires (ASF committer) license, PMD is freely available... > http://pmd.sourceforge.net/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Resolved: (SOLR-20) A simple Java client for updating and searching
Just to be clean, you can (and should) keep using 1.2 for the solr server; but solrj is only in the trunk (1.3) branch. John Stewart wrote: Aha, 1.3. Thanks, I'm using 1.2. jds On 6/15/07, Ryan McKinley <[EMAIL PROTECTED]> wrote: after running "ant dist" you will need: apache-solr-1.3-dev-common.jar apache-solr-1.3-dev-solrj.jar solrj-lib/*.jar John Stewart wrote: > Hi Ryan, > > Forgive me if this is a newbie question. I just pulled solrj out of the > main solr trunk. There's a dependency on import > org.apache.solr.common.util.NamedList. I can't find this class. There's a > import org.apache.util.NamedList, but not a package called common. > > Thanks, > > jds > > On 6/15/07, Ryan McKinley (JIRA) <[EMAIL PROTECTED]> wrote: >> >> >> [ >> https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] >> >> >> Ryan McKinley resolved SOLR-20. >> --- >> >> Resolution: Fixed >> >> Added to trunk... any new problems should get their own issue. >> >> > 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 >> >Assignee: Ryan McKinley >> >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: [jira] Resolved: (SOLR-20) A simple Java client for updating and searching
Aha, 1.3. Thanks, I'm using 1.2. jds On 6/15/07, Ryan McKinley <[EMAIL PROTECTED]> wrote: after running "ant dist" you will need: apache-solr-1.3-dev-common.jar apache-solr-1.3-dev-solrj.jar solrj-lib/*.jar John Stewart wrote: > Hi Ryan, > > Forgive me if this is a newbie question. I just pulled solrj out of the > main solr trunk. There's a dependency on import > org.apache.solr.common.util.NamedList. I can't find this class. There's a > import org.apache.util.NamedList, but not a package called common. > > Thanks, > > jds > > On 6/15/07, Ryan McKinley (JIRA) <[EMAIL PROTECTED]> wrote: >> >> >> [ >> https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] >> >> >> Ryan McKinley resolved SOLR-20. >> --- >> >> Resolution: Fixed >> >> Added to trunk... any new problems should get their own issue. >> >> > 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 >> >Assignee: Ryan McKinley >> >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: [jira] Resolved: (SOLR-20) A simple Java client for updating and searching
after running "ant dist" you will need: apache-solr-1.3-dev-common.jar apache-solr-1.3-dev-solrj.jar solrj-lib/*.jar John Stewart wrote: Hi Ryan, Forgive me if this is a newbie question. I just pulled solrj out of the main solr trunk. There's a dependency on import org.apache.solr.common.util.NamedList. I can't find this class. There's a import org.apache.util.NamedList, but not a package called common. Thanks, jds On 6/15/07, Ryan McKinley (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Ryan McKinley resolved SOLR-20. --- Resolution: Fixed Added to trunk... any new problems should get their own issue. > 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 >Assignee: Ryan McKinley >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: [jira] Resolved: (SOLR-20) A simple Java client for updating and searching
Hi Ryan, Forgive me if this is a newbie question. I just pulled solrj out of the main solr trunk. There's a dependency on import org.apache.solr.common.util.NamedList. I can't find this class. There's a import org.apache.util.NamedList, but not a package called common. Thanks, jds On 6/15/07, Ryan McKinley (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/SOLR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Ryan McKinley resolved SOLR-20. --- Resolution: Fixed Added to trunk... any new problems should get their own issue. > 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 >Assignee: Ryan McKinley >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] Commented: (SOLR-205) SolrSharp - a C# client API for Solr
[
https://issues.apache.org/jira/browse/SOLR-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505363
]
Jeff Rodenburg commented on SOLR-205:
-
The Example application includes some code for delete by query, but it is
commented out. The particular code looks like:
//List listQP = new List();
//listQP.Add(new QueryParameter("id", "101"));
//QueryParameterCollection queryParameterCollection = new
QueryParameterCollection("delete", listQP);
//Query query = new Query();
//query.AddQueryParameters(queryParameterCollection,
ParameterJoin.AND);
//DeleteIndexDocument deleteIndexDocument = new
DeleteIndexDocument(query);
DeleteIndexDocument deleteIndexDocument = new
DeleteIndexDocument("101");
oUpdate.PostToIndex(deleteIndexDocument, true);
Uncomment those and comment out the single DeleteIndexDocument("101") line to
execute a delete-by-query.
> SolrSharp - a C# client API for Solr
>
>
> Key: SOLR-205
> URL: https://issues.apache.org/jira/browse/SOLR-205
> Project: Solr
> Issue Type: New Feature
> Environment: Microsoft Windows, .Net Framework 2.0
>Reporter: Jeff Rodenburg
>Priority: Minor
>
> SolrSharp is a client API written in C# using the .Net framework to interact
> with Apache Solr.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-205) SolrSharp - a C# client API for Solr
[ https://issues.apache.org/jira/browse/SOLR-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505361 ] ms commented on SOLR-205: - Jeff- I will check the code at the link you provided. However, looking at the Examples, I do not see code sample for delete by query. My intention is to delte all documents/range of documents prior to (partially) reb-uilding the index. > SolrSharp - a C# client API for Solr > > > Key: SOLR-205 > URL: https://issues.apache.org/jira/browse/SOLR-205 > Project: Solr > Issue Type: New Feature > Environment: Microsoft Windows, .Net Framework 2.0 >Reporter: Jeff Rodenburg >Priority: Minor > > SolrSharp is a client API written in C# using the .Net framework to interact > with Apache Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
: > [junit] Test org.apache.solr.client.solrj.embedded.TestJettySolrRunner FAILED : > : : Is there any way to see what error it failed with? ant test-reports i was going to say you can find them on people.apache.org in the /tmp directory .. but it looks like the nightly.sh is actualy running on the lucene zone. i don't have an account there, but yonik should (since his crontab runs the bightly.sh anyway) -Hoss
[jira] Commented: (SOLR-205) SolrSharp - a C# client API for Solr
[ https://issues.apache.org/jira/browse/SOLR-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505340 ] Jeff Rodenburg commented on SOLR-205: - There was a bug in DeleteIndexDocument, which has been updated. Deleting by query vs. unique key was not being handled properly. The source at http://solrstuff.org/svn/solrsharp has been updated (documentation to updated later.) ms - for your scenario, this issues a delete-by-id request using the xml syntax "*a*". This is not the same as a delete-by-query, if that's the intention. Please look at the example for code that shows how to delete by query. > SolrSharp - a C# client API for Solr > > > Key: SOLR-205 > URL: https://issues.apache.org/jira/browse/SOLR-205 > Project: Solr > Issue Type: New Feature > Environment: Microsoft Windows, .Net Framework 2.0 >Reporter: Jeff Rodenburg >Priority: Minor > > SolrSharp is a client API written in C# using the .Net framework to interact > with Apache Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-236: --- Attachment: SOLR-236-FieldCollapsing.patch No real changes. Updated to apply with trunk. Moved the valid values for CollapseType to a 'common' package - - - - as a side note, when you make a patch, its easiest to deal with if the path is relative to the solr root directory. src/java/org/apache/solr/search/SolrIndexSearcher.java is better then: /Users/ekeller/Documents/workspace/solr/src/java/org/apache/solr/search/SolrIndexSearcher.java > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller > Attachments: field_collapsing_1.1.0.patch, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-139: --- Attachment: SOLR-139-IndexDocumentCommand.patch updated with trunk > Support updateable/modifiable documents > --- > > Key: SOLR-139 > URL: https://issues.apache.org/jira/browse/SOLR-139 > Project: Solr > Issue Type: Improvement > Components: update >Reporter: Ryan McKinley > Attachments: SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-XmlUpdater.patch > > > It would be nice to be able to update some fields on a document without > having to insert the entire document. > Given the way lucene is structured, (for now) one can only modify stored > fields. > While we are at it, we can support incrementing an existing value - I think > this only makes sense for numbers. > for background, see: > http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (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:all-tabpanel ] Ryan McKinley resolved SOLR-20. --- Resolution: Fixed Added to trunk... any new problems should get their own issue. > 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 >Assignee: Ryan McKinley >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] 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_12505313 ] Ryan McKinley commented on SOLR-20: --- solr 1.2 was released ~1 week ago so the next official stable release is at least a few months out. The solrj client is quite stable (I won't say that too strongly until more people are using it) and will be included in solr nightly builds. While I don't recommend using the solr server nightly builds, the client should be ok. > 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 >Assignee: Ryan McKinley >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] 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_12505304 ] Michael Young commented on SOLR-20: --- We are planning to replace our custom Lucene implementation with Solr in the next release of Liferay. This Java client would be extremely useful to us and we would like to see it in the next stable release. When do you anticipate this, or at least an alpha version? > 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 >Assignee: Ryan McKinley >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-225) Allow pluggable Highlighting classes -- Formatters and Fragmenters
[ https://issues.apache.org/jira/browse/SOLR-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-225: --- Attachment: SOLR-225+260-HighlightPlugins.patch This uses SOLR-260 general plugin loader to load highlighting plugins. Since these patches touch a few of the same files, I will maintain them together. > Allow pluggable Highlighting classes -- Formatters and Fragmenters > -- > > Key: SOLR-225 > URL: https://issues.apache.org/jira/browse/SOLR-225 > Project: Solr > Issue Type: Improvement >Reporter: Brian Whitman > Attachments: SOLR-225+260-HighlightPlugins.patch, > SOLR-225-HighlightingConfig.patch, SOLR-225-HighlightingConfig.patch, > SOLR-225-HighlightingConfig.patch, SOLR-225-HighlightingConfig.patch, > SOLR-225-HighlightingConfig.patch > > > Highlighting should support a pluggable architecture similar to what is seen > with RequestHandlers, Fields, FieldTypes, etc > ' > For more background: > http://www.nabble.com/Custom-fragmenter-tf3681588.html#a10289335 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
[junit] Test org.apache.solr.client.solrj.embedded.TestJettySolrRunner FAILED Is there any way to see what error it failed with? ant test-reports hudson seems to have built fine: http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/112/ This is the test that starts jetty (on port 8984) Perhaps it does not like that?
Re: Multiple indexes/cores (aka solr-215) functional value?
On 6/15/07, Henrib <[EMAIL PROTECTED]> wrote: The idea of the multiple core/indexes feature has been discussed in many threads and it seems/seemed it has/had some functional value; how do we ensure this value is generic enough for the issue (& patch) to ever be solved? More importantly, is there an issue in the first place? For all use cases where it might make sense to use multiple indexes, the common (as in community and commiters) wisdom is that one index is enough I think that's the case mainly because it reflected the capabilities of solr at the time... so if someone asks how they create more than one index, the natural reaction has been to ask "do you really need to?" in the spirit of helping them quickly solve their problem with what was available. Of course, now there is your very ambitious SOLR-215, which I personally haven't had the time to look at, but I commend your great writeup on it - it really helps to have that type of detailed overview when attempting to evaluate such a large patch. -Yonik
Fwd: Call for Papers Opens for OS Summit Asia 2007
Begin forwarded message: From: J Aaron Farr <[EMAIL PROTECTED]> Call for Papers Opens for OS Summit Asia 2007 The call for papers is now open for OS Summit Asia, to be held November 26-30 at the Cyberport in Hong Kong. This joint conference between the Apache Software Foundation and the Eclipse Foundation will be consist of two days of tutorials (Nov 26-27) and three days of regular conference sessions (Nov 28-30). The paper submission deadline is Friday, 13 July, 2007, Midnight PDT. You may log in to the ApacheCon submission site to submit your proposals. Further details about the conference, submissions, and fees can be found at: http://www.ossummit.com/cfp.html Topics appropriate for submission include, but are not restricted to, the following: * ASF-wide projects such as Apache HTTP server, Tomcat, Struts, Geronimo, mod_perl and XML Web Services * Eclipse-wide projects such as BI and Reporting Tools (BIRT), Web Tools Platform (WTP), Eclipse Modeling Framework (EMF), Data Tools Platform (DTP), Equinox and the Rich Client Platform (RCP) * Programming languages such as Java, Perl, Python, Ruby and PHP * Web development technologies and techniques including security, performance tuning, e-commerce and J2EE * New technologies and trends such as Web Services and Web 2.0 * Open source community and business models, legal and marketing issues * Open source projects and activities in Asia, local efforts and case studies Thanks and we hope to hear from you, and see you in Hong Kong! -- The OSSummit Planners [EMAIL PROTECTED]
Multiple indexes/cores (aka solr-215) functional value?
The idea of the multiple core/indexes feature has been discussed in many threads and it seems/seemed it has/had some functional value; how do we ensure this value is generic enough for the issue (& patch) to ever be solved? More importantly, is there an issue in the first place? For all use cases where it might make sense to use multiple indexes, the common (as in community and commiters) wisdom is that one index is enough and its schema will accommodate any functional need; from storing documents that have no field in common to documents in different languages or documents with varying publication workflows or lifetime, etc..., one index (schema/config/core) - fits the functional bill. In very rare hard cases, you might have to deploy multiple web applications. If having only one index is never a problem, the project has no need for a patch that introduces multiple indexes. Thus, if the solr-215 issue is a non-issue, what is the process to close it and mark it as 'invalid'? It would be of great community value to state that thinking about using multiple indexes is a mistake within the Solr project scope; use Lucene or else if this is what you need. Is/should the single index best practice the sole one the Solr community needs ? I should have asked this earlier, still learning... -- View this message in context: http://www.nabble.com/Multiple-indexes-cores-%28aka-solr-215%29-functional-value--tf3927076.html#a11137029 Sent from the Solr - Dev mailing list archive at Nabble.com.
Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build checkJunitPresence: compile-common: [mkdir] Created dir: /tmp/apache-solr-nightly/build/common [javac] Compiling 24 source files to /tmp/apache-solr-nightly/build/common [javac] Note: /tmp/apache-solr-nightly/src/java/org/apache/solr/common/params/DisMaxParams.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile: [mkdir] Created dir: /tmp/apache-solr-nightly/build/core [javac] Compiling 192 source files to /tmp/apache-solr-nightly/build/core [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile-solrj-core: [mkdir] Created dir: /tmp/apache-solr-nightly/build/client/solrj [javac] Compiling 21 source files to /tmp/apache-solr-nightly/build/client/solrj [javac] Note: /tmp/apache-solr-nightly/client/java/solrj/src/org/apache/solr/client/solrj/impl/CommonsHttpSolrServer.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. compile-solrj: [javac] Compiling 2 source files to /tmp/apache-solr-nightly/build/client/solrj [javac] Note: /tmp/apache-solr-nightly/client/java/solrj/src/org/apache/solr/client/solrj/embedded/JettySolrRunner.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 52 source files to /tmp/apache-solr-nightly/build/tests [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. junit: [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results [junit] Running org.apache.solr.BasicFunctionalityTest [junit] Tests run: 24, Failures: 0, Errors: 0, Time elapsed: 22.673 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.709 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 3.472 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 1.213 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.462 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.374 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.051 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.045 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.058 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 0.045 sec [junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.061 sec [junit] Running org.apache.solr.analysis.TestPhoneticFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.089 sec [junit] Running org.apache.solr.analysis.TestRemoveDuplicatesTokenFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.049 sec [junit] Running org.apache.solr.analysis.TestSynonymFilter [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.098 sec [junit] Running org.apache.solr.analysis.TestTrimFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.06 sec [junit] Running org.apache.solr.analysis.TestWordDelimiterFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 5.098 sec [junit] Running org.apache.solr.common.SolrDocumentTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.068 sec [junit] Running org.apache.solr.common.params.SolrParamTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.088 sec [junit] Running org.apache.solr.common.util.ContentStreamTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 0.58 sec [junit] Running org.apache.solr.common.util.IteratorChainTest [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 0.043 sec [juni
[jira] Commented: (SOLR-255) RemoteSearchable for Solr(use RMI)
[
https://issues.apache.org/jira/browse/SOLR-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12505078
]
Toru Matsuzawa commented on SOLR-255:
-
My implementation is as follows.
client --> Solr instance +/data/index
+/local/other/solr1/data/index
+/local/other/solr2/data/index
+/local/other/solr3/data/index
|
+--- RMI <--- Remote Solr
index(/data/index)
|
+--- RMI <--- Remote Solr
index(/data/index)
First of all, I'd like to get your comments whether my modification is
beneficial for Solr.
If it is helpful, is it possible to implement this changes without modifying
Lucene?
I need your comments on this point.(If you have any other ideas for the
implementation, please let me know.)
After it becomes clear the necessity of modifying Lucene, I'd like to post it
to Lucene's JIRA.
I understand there are some overlaps with SOLR-215.
However, I think this modification can coexist with SOLR-215.
Thank you.
> RemoteSearchable for Solr(use RMI)
> --
>
> Key: SOLR-255
> URL: https://issues.apache.org/jira/browse/SOLR-255
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: Toru Matsuzawa
> Attachments: solr-multi20070606.zip
>
>
> I experimentally implemented RemoteSearchable of Lucene for Solr.
> I referred to "FederatedSearch" and used RMI.
> Two or more Searchers can be referred to with SolrIndexSearcher.
> These query-only indexes can be specified in solrconfig.xml,
> enumerating the list under a tag.
>
> E:\sample\data1
> E:\sample\data2
> rmi://localhost
>
> The index in the dataDir is also used as the default index of solr
> to update and query.
> When data of a document in a index specified under the is
> updated,
> that document data in the index will be deleted and data of the updated
> document will be stored
> in the index in the dataDir.
> SolrRemoteSearchable (the searcher for remote access) is started from
> SolrCore
> by specifying "< remoteSearcher>true" in solrconfig.xml.(It
> is registered in RMI. )
> ("-Djava.security.policy" should be set when you start VM. )
> Not all of the operational cases are tested
> because Solr has so many features.
> Moreover, TestUnit has not been made
> because I made this through a trial and error process.
> Some changes are required in Lucene to execute this.
> I need your comments on this although it might be hard without TestUnit.
> I especially worry about the followings:
> - Am I on the right truck about this issue?
> - Is the extent of modifying Lucene tolerable?
> - Are there any ideas to implement this feature without modifying Lucene?
> - Does this idea contribute for improving Solr?
> - This implementation may partially overlap with "Multiple Solr Cores".
> What should be done?
> - Are there any other considerations about this issue, which I have
> overlooked?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
