[jira] Assigned: (SOLR-976) deleteByQuery is ignored when deleteById is placed prior to deleteByQuery in a
[
https://issues.apache.org/jira/browse/SOLR-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi reassigned SOLR-976:
---
Assignee: Koji Sekiguchi
> deleteByQuery is ignored when deleteById is placed prior to deleteByQuery in
> a
>
>
> Key: SOLR-976
> URL: https://issues.apache.org/jira/browse/SOLR-976
> Project: Solr
> Issue Type: Bug
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Trivial
> Fix For: 1.4
>
> Attachments: SOLR-976.patch
>
>
> Due to the following if block, deleteByQuery cannot be executed. cmd.id and
> cmd.query should be set to null when UpdateProcessor chain is finished.
> {code:title=RunUpdateProcessor}
> public void processDelete(DeleteUpdateCommand cmd) throws IOException {
> if( cmd.id != null ) {
> updateHandler.delete(cmd);
> }
> else {
> updateHandler.deleteByQuery(cmd);
> }
> super.processDelete(cmd);
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-976) deleteByQuery is ignored when deleteById is placed prior to deleteByQuery in a
[
https://issues.apache.org/jira/browse/SOLR-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671527#action_12671527
]
Mark Miller commented on SOLR-976:
--
My Opinion: it should clear both (this patch), and also execute both if both
are set. It makes as much or more sense than one wins over the other.
> deleteByQuery is ignored when deleteById is placed prior to deleteByQuery in
> a
>
>
> Key: SOLR-976
> URL: https://issues.apache.org/jira/browse/SOLR-976
> Project: Solr
> Issue Type: Bug
>Reporter: Koji Sekiguchi
>Priority: Trivial
> Fix For: 1.4
>
> Attachments: SOLR-976.patch
>
>
> Due to the following if block, deleteByQuery cannot be executed. cmd.id and
> cmd.query should be set to null when UpdateProcessor chain is finished.
> {code:title=RunUpdateProcessor}
> public void processDelete(DeleteUpdateCommand cmd) throws IOException {
> if( cmd.id != null ) {
> updateHandler.delete(cmd);
> }
> else {
> updateHandler.deleteByQuery(cmd);
> }
> super.processDelete(cmd);
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1011) Links to Replication page and other cores are 404s
[ https://issues.apache.org/jira/browse/SOLR-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-1011. - Resolution: Fixed Committed revision 741940. Thanks Jacob! > Links to Replication page and other cores are 404s > -- > > Key: SOLR-1011 > URL: https://issues.apache.org/jira/browse/SOLR-1011 > Project: Solr > Issue Type: Bug > Components: web gui > Environment: Tomcat6 > CentOS5 >Reporter: Jacob Singh >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: replication_gui_paths.diff, SOLR-1011.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This patch addresses some bad links in the admin gui when using the > replication screen (perhaps only in multicore??). > http://img.skitch.com/20090207-n98x9d53jycghg5icshd9xubn7.jpg > http://img.skitch.com/20090207-k3bxesdrwixc4sa2iaimax7hks.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-705) Distributed search should optionally return docID->shard map
[ https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671512#action_12671512 ] Yonik Seeley commented on SOLR-705: --- Sowhat do people think of "meta"? It seems like it could make things easier on clients - removing the need for correlation-by-id. > Distributed search should optionally return docID->shard map > > > Key: SOLR-705 > URL: https://issues.apache.org/jira/browse/SOLR-705 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 > Environment: all >Reporter: Brian Whitman > Fix For: 1.4 > > Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, > SOLR-705.patch, SOLR-705.patch > > > SOLR-303 queries with &shards parameters set need to return the dociD->shard > mapping in the response. Without it, updating/deleting documents when the # > of shards is variable is hard. We currently set this with a special > requestHandler that filters /update and inserts the shard as a field in the > index but it would be better if the shard location came back in the query > response outside of the index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-764) Support facet.sort=false (index order) with distributed search
[ https://issues.apache.org/jira/browse/SOLR-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671496#action_12671496 ] Wojtek Piaseczny commented on SOLR-764: --- In the new implementation, sort=false and sort=lex are the same. In the previous implementation, specifying sort=false would sort sortable-numbers (like sint) numerically, rather lexicographically. So there's a slight inconsistency between the new and old implementation. I like the idea of adding a numeric sort order. > Support facet.sort=false (index order) with distributed search > -- > > Key: SOLR-764 > URL: https://issues.apache.org/jira/browse/SOLR-764 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Wojtek Piaseczny > Fix For: 1.4 > > Attachments: SOLR-764.patch, SOLR-764.patch > > > Distributed search does not currently support sorting facets by index order > (facet.sort=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-284) Parsing Rich Document Types
[ https://issues.apache.org/jira/browse/SOLR-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll resolved SOLR-284. -- Resolution: Fixed I removed the auto key generation: Committed revision 741907. I think this can officially close out this patch. > Parsing Rich Document Types > --- > > Key: SOLR-284 > URL: https://issues.apache.org/jira/browse/SOLR-284 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Eric Pugh >Assignee: Grant Ingersoll > Fix For: 1.4 > > Attachments: libs.zip, rich.patch, rich.patch, rich.patch, > rich.patch, rich.patch, rich.patch, rich.patch, SOLR-284-no-key-gen.patch, > SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, > SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, solr-word.pdf, source.zip, > test-files.zip, test-files.zip, test.zip, un-hardcode-id.diff > > > I have developed a RichDocumentRequestHandler based on the CSVRequestHandler > that supports streaming a PDF, Word, Powerpoint, Excel, or PDF document into > Solr. > There is a wiki page with information here: > http://wiki.apache.org/solr/UpdateRichDocuments > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-284) Parsing Rich Document Types
[ https://issues.apache.org/jira/browse/SOLR-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-284: - Attachment: SOLR-284-no-key-gen.patch Remove Key Generation. Will commit shortly > Parsing Rich Document Types > --- > > Key: SOLR-284 > URL: https://issues.apache.org/jira/browse/SOLR-284 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Eric Pugh >Assignee: Grant Ingersoll > Fix For: 1.4 > > Attachments: libs.zip, rich.patch, rich.patch, rich.patch, > rich.patch, rich.patch, rich.patch, rich.patch, SOLR-284-no-key-gen.patch, > SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, > SOLR-284.patch, SOLR-284.patch, SOLR-284.patch, solr-word.pdf, source.zip, > test-files.zip, test-files.zip, test.zip, un-hardcode-id.diff > > > I have developed a RichDocumentRequestHandler based on the CSVRequestHandler > that supports streaming a PDF, Word, Powerpoint, Excel, or PDF document into > Solr. > There is a wiki page with information here: > http://wiki.apache.org/solr/UpdateRichDocuments > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-993) VariableResolverImpl addNamespace overwrites entire namespace instead of adding
[ https://issues.apache.org/jira/browse/SOLR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671478#action_12671478 ] Jared Flatow commented on SOLR-993: --- bq. This patch is WRONG. It would not work for the functions namespace. Because functions implements a custom map. look at EvaluatorBag.getFunctionsNameSpace(). Why shouldn't it work for the EvaluatorBag Functions? I am using the patch, as well as those functions... bq. Moreover ,your version of the VariableResolverImpl is more expensive and creates more objects. Map.putAll() is far more expensive because it creates so many Map.Entry and removals are more costly. Given the size of the namespaces I doubt there is a major performance penalty (it only creates "so many Map.Entry"s if they exist in the namespace already), but if that is a concern it can be avoided by getting the parent namespace first. bq. Can you tell me what are you trying to achieve. If you can give me usecases It may help me solve it better. I want to define the behavior of the VariableResolver better so it is more usable. There are significant ambiguities with the existing implementation. The "DOT_SPLIT and backup" of namespace names is incorrect. What if I have a namespace "a.b" containing a mapping with key "c.d", what does "a.b.c.d" refer to? The answer currently is it depends what other namespaces I have. Ideally, I would like to see the VariableResolver interface define the correct way to put values in/out of a namespace, and tell you which values are going to be overwritten when. This will make writing transformers more straightforward. > VariableResolverImpl addNamespace overwrites entire namespace instead of > adding > --- > > Key: SOLR-993 > URL: https://issues.apache.org/jira/browse/SOLR-993 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Jared Flatow >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: SOLR-993.patch, SOLR-993b.patch > > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > The addNamespace method in VariableResolverImpl does not so much add the > namespace as overwrite it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-764) Support facet.sort=false (index order) with distributed search
[ https://issues.apache.org/jira/browse/SOLR-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671470#action_12671470 ] Lars Kotthoff commented on SOLR-764: What do you mean by wrong order? When sorting lexicographically, I would expect it to return something like 1, 10, 11, 2, 20, 3, 4, 5 etc. as this is the lexicographic order. Ordering those by numeric value should probably be a new parameter, like "facet.sort=numeric". > Support facet.sort=false (index order) with distributed search > -- > > Key: SOLR-764 > URL: https://issues.apache.org/jira/browse/SOLR-764 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Wojtek Piaseczny > Fix For: 1.4 > > Attachments: SOLR-764.patch, SOLR-764.patch > > > Distributed search does not currently support sorting facets by index order > (facet.sort=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-705) Distributed search should optionally return docID->shard map
[ https://issues.apache.org/jira/browse/SOLR-705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Kotthoff updated SOLR-705: --- Attachment: SOLR-705.patch Attaching new patch which compiles again. > Distributed search should optionally return docID->shard map > > > Key: SOLR-705 > URL: https://issues.apache.org/jira/browse/SOLR-705 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 > Environment: all >Reporter: Brian Whitman > Fix For: 1.4 > > Attachments: SOLR-705.patch, SOLR-705.patch, SOLR-705.patch, > SOLR-705.patch, SOLR-705.patch > > > SOLR-303 queries with &shards parameters set need to return the dociD->shard > mapping in the response. Without it, updating/deleting documents when the # > of shards is variable is hard. We currently set this with a special > requestHandler that filters /update and inserts the shard as a field in the > index but it would be better if the shard location came back in the query > response outside of the index. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1011) Links to Replication page and other cores are 404s
[ https://issues.apache.org/jira/browse/SOLR-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1011: Attachment: SOLR-1011.patch Patch with the above change. I'll commit this shortly. > Links to Replication page and other cores are 404s > -- > > Key: SOLR-1011 > URL: https://issues.apache.org/jira/browse/SOLR-1011 > Project: Solr > Issue Type: Bug > Components: web gui > Environment: Tomcat6 > CentOS5 >Reporter: Jacob Singh >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: replication_gui_paths.diff, SOLR-1011.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > This patch addresses some bad links in the admin gui when using the > replication screen (perhaps only in multicore??). > http://img.skitch.com/20090207-n98x9d53jycghg5icshd9xubn7.jpg > http://img.skitch.com/20090207-k3bxesdrwixc4sa2iaimax7hks.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1011) Links to Replication page and other cores are 404s
[ https://issues.apache.org/jira/browse/SOLR-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671432#action_12671432 ] Shalin Shekhar Mangar commented on SOLR-1011: - Thanks Jacob. I think the core links on replication page were meant to go to the admin page of the core. I'll commit after making that change. > Links to Replication page and other cores are 404s > -- > > Key: SOLR-1011 > URL: https://issues.apache.org/jira/browse/SOLR-1011 > Project: Solr > Issue Type: Bug > Components: web gui > Environment: Tomcat6 > CentOS5 >Reporter: Jacob Singh >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: replication_gui_paths.diff > > Original Estimate: 1h > Remaining Estimate: 1h > > This patch addresses some bad links in the admin gui when using the > replication screen (perhaps only in multicore??). > http://img.skitch.com/20090207-n98x9d53jycghg5icshd9xubn7.jpg > http://img.skitch.com/20090207-k3bxesdrwixc4sa2iaimax7hks.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1011) Links to Replication page and other cores are 404s
[ https://issues.apache.org/jira/browse/SOLR-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-1011: --- Assignee: Shalin Shekhar Mangar > Links to Replication page and other cores are 404s > -- > > Key: SOLR-1011 > URL: https://issues.apache.org/jira/browse/SOLR-1011 > Project: Solr > Issue Type: Bug > Components: web gui > Environment: Tomcat6 > CentOS5 >Reporter: Jacob Singh >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: replication_gui_paths.diff > > Original Estimate: 1h > Remaining Estimate: 1h > > This patch addresses some bad links in the admin gui when using the > replication screen (perhaps only in multicore??). > http://img.skitch.com/20090207-n98x9d53jycghg5icshd9xubn7.jpg > http://img.skitch.com/20090207-k3bxesdrwixc4sa2iaimax7hks.jpg -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is back to normal: Solr-trunk #707
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/707/changes
Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build [mkdir] Created dir: /tmp/apache-solr-nightly/build/web compile-solrj: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj [javac] Compiling 73 source files to /tmp/apache-solr-nightly/build/solrj [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: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solr [javac] Compiling 352 source files to /tmp/apache-solr-nightly/build/solr [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. compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 139 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: 19, Failures: 0, Errors: 0, Time elapsed: 16.982 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 8.437 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 5.506 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.609 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 2.417 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.29 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.815 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 28.185 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.324 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.328 sec [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.887 sec [junit] Running org.apache.solr.analysis.HTMLStripReaderTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.593 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.755 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.57 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.319 sec [junit] Running org.apache.solr.analysis.TestCharFilter [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.326 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.751 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.645 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilter [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 0.347 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.331 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 2.018 sec [junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.11 sec [junit] Running org.apache.solr.analysis.TestPhoneticFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.148 sec [junit] Running org.apache.solr.analysis.TestRemoveDuplicatesTokenFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 1.429 sec [junit] Running org.apache.solr.analysis.TestSynonymFilter [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 1.872 sec [junit] Running org.apache.solr.analysis.TestSyno
