[jira] Updated: (SOLR-133) change XmlUpdateRequestHandler to use StAX instead of XPP
[ https://issues.apache.org/jira/browse/SOLR-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-133: --- Attachment: SOLR-133-XmlUpdateRequestHandler-StAX-139.patch Updated to apply against trunk and removed the SOLR-139 dependency. Not it just relies on SOLR-193. > change XmlUpdateRequestHandler to use StAX instead of XPP > - > > Key: SOLR-133 > URL: https://issues.apache.org/jira/browse/SOLR-133 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man > Attachments: SOLR-133-XmlUpdateRequestHandler-StAX-139.patch, > SOLR-133-XmlUpdateRequestHandler-StAX-139.patch, > SOLR-133-XmlUpdateRequestHandler-StAX-139.patch, > SOLR-133-XmlUpdateRequestHandler-StAX-139.patch, > SOLR-133-XmlUpdateRequestHandler-StAX-139.patch, > SOLR-133-XmlUpdateRequestHandler-StAX-139.patch, SOLR-133.diff, SOLR-133.diff > > > there has been discussion of using StAX for XML parsing of updates instead of > XPP ... opening an issue to track it as a possible improvement (orriginally > mentioned in SOLR-61, but that task was more specificly about refactoring the > existing code) -- 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-HighlightingConfig.patch applies with trunk > 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-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.
[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-HighlightingConfig.patch > 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-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.
Hudson build is back to normal: Solr-Nightly #102
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/102/
[jira] Resolved: (SOLR-242) tr parameter implies XSL, no wt=xslt necessary
[ https://issues.apache.org/jira/browse/SOLR-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman resolved SOLR-242. Resolution: Won't Fix > tr parameter implies XSL, no wt=xslt necessary > -- > > Key: SOLR-242 > URL: https://issues.apache.org/jira/browse/SOLR-242 > Project: Solr > Issue Type: Improvement >Reporter: Brian Whitman >Priority: Trivial > > Perhaps the most trivial issue ever, but &tr=file.xsl should imply that the > XML from whichever response writer is being used gets parsed by the given > transform. The wt=xslt is somewhat redundant. And maybe change the tr > parameter to xslt. > Imagine in the future there's a response writer that outputs a different kind > of XML. That shouldn't preclude the use of a transform on top of that > response. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-239) Read IndexSchema from InputStream instead of Config file
[ https://issues.apache.org/jira/browse/SOLR-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Will Johnson updated SOLR-239: -- Attachment: IndexSchemaStream2.patch New patch that address all 6 suggestions. The one thing that is interesting is that using http://localhost:8983/solr/admin/get-file.jsp?file=schema.xml does not work as it prints out a number of newlines before the XML declaration which causes it to be invalid. I'm not quite sure how to fix this without rewriting get-file.jsp as a servlet and making sure it only prints out the xml. In any case it does work against url's that only contain valid xml however I wasn't sure how we go about testing things that require the example to be running. (the test is therefore commented out) as for motivations, yes it does require a good bit of overhead and i think it would be good to have a 'lighter' IndexSchema implementation for client api's. i do think however that it's nice to know exactly what is running and to be able to inspect each fields capabilities so i'm not sure what the right thing to do is. - will > Read IndexSchema from InputStream instead of Config file > > > Key: SOLR-239 > URL: https://issues.apache.org/jira/browse/SOLR-239 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.2 > Environment: all >Reporter: Will Johnson >Priority: Minor > Fix For: 1.2 > > Attachments: IndexSchemaStream.patch, IndexSchemaStream2.patch, > IndexSchemaStream2.patch, IndexSchemaStream2.patch, IndexSchemaStream2.patch > > > Soon to follow patch adds a constructor to IndexSchema to allow them to be > created directly from InputStreams. The overall logic for the Core's use of > the IndexSchema creation/use does not change however this allows java clients > like those in SOLR-20 to be able to parse an IndexSchema. Once a schema is > parsed, the client can inspect an index's capabilities which is useful for > building generic search UI's. ie provide a drop down list of fields to > search/sort by. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] release rc4 as Solr 1.2
+1 Bill On 6/3/07, Chris Hostetter <[EMAIL PROTECTED]> wrote: : http://people.apache.org/~yonik/staging_area/solr/1.2rc4/ : as Apache Solr 1.2 +1 -Hoss
Re: [VOTE] release rc4 as Solr 1.2
+1 On Jun 2, 2007, at 6:19 PM, Yonik Seeley wrote: OK, this one is it! Please vote to release the artifacts at http://people.apache.org/~yonik/staging_area/solr/1.2rc4/ as Apache Solr 1.2 +1 -Yonik
Re: Packaging solr for Debian: using debian-supplied lucene-*.jar
(NOTE: Moved to Solr Dev) : It's not too bad (at least for solr-1.1.0, haven't looked at the : upcoming 1.2.0 yet). To create the .deb, the java sources in the solr ... : ant dist-war. The resulting .war-file is unpacked into the package file, ... That sounds like a lot more work then just compiling/installing a "fat war" containing all of the need jars embedded in it. : > 3) Some of the jars Solr inlcudes in it's war are not the officially : > released version of third party software. We frequently use development : That may be a problem. For the depencies on Lucene, it may mean I should : either wait for the next Lucene release before packaging the previous : Solr release, or package a development Lucene release separately (I'm : also one of the maintainers of the Debian Lucene package). It's a moving target ... the APIs may change in between releases (ie: SOlr could upgrade to a nightly build of Lucene between 2.1 and 2.2, and start taking advantage of API changes made after 2.1 ... those APIs can freely change again before the official Lucene 2.2 release. When Solr upgrades it's embedded version to 2.2, we'll fix any breakage because of those dependencies, but you may be screwed either way as long as you only look at official releases of all the parties involved. : The other libraries of which Solr uses unreleased versions (by the way, : that are not noted in the README in the subversion repository, but I'm : guessing from the jarfile names in lib/) are we've never really had a policy of listing other third part jars that are included in the README ... they're listed in NOTICES.txt -Hoss
[jira] Updated: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Keller updated SOLR-236: - Attachment: SOLR-236-FieldCollapsing.patch Right, It's more useful. This new version includes the result as you expect it. You should add the following constraint on the wiki: The collapsing field must be un-tokenized. > 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.2 >Reporter: Emmanuel Keller > Attachments: collapse_field.patch, collapse_field.patch, > field_collapsing.patch, field_collapsing.patch, field_collapsing.patch, > field_collapsing_1.1.0.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 (1.2) > - "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] Commented: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501405 ] Ryan McKinley commented on SOLR-236: I just took a look at this using the example data: http://localhost:8983/solr/select/?q=*:*&collapse.field=cat&collapse.max=1&collapse.type=normal&rows=10 cat 1 2 2 1 1 1 2 2 1 1 - - - what is the "1" at the front of each response? Perhaps the 'doc' results should be renamed 'offset' or 'index', and then have another one named 'doc' that uses the uniqueKey as the index... this would be useful to build a Map. - - - Also, check: http://localhost:8983/solr/select/?q=*:*&collapse.field=cat&collapse.max=1&collapse.type=adjacent&rows=50 ArrayIndexOutOfBoundsException: - - - > You should add the following constraint on the wiki: The collapsing field > must be un-tokenized. Anyone can edit the wiki (you just have to make an account) -- it would be great if you could help keep the page accurate / useful. JIRA discussion comment trails don't work so well at that... Re: tokenized... what about it does not work? Are the limitations an different if it is mult-valued? Is it just that if any token matches within the field it will collapse and that may or may not be what you expect? - - - Did you get a chance to look at the questions from the previous discussion? I just noticed Yonik posted something new there: http://www.nabble.com/result-grouping--tf2910425.html#a10959848 > 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.2 >Reporter: Emmanuel Keller > Attachments: collapse_field.patch, collapse_field.patch, > field_collapsing.patch, field_collapsing.patch, field_collapsing.patch, > field_collapsing_1.1.0.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 (1.2) > - "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-248) Capitalization Filter Factory
[ https://issues.apache.org/jira/browse/SOLR-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-248: --- Attachment: SOLR-248-CapitalizationFilter.patch applies with trunk > Capitalization Filter Factory > - > > Key: SOLR-248 > URL: https://issues.apache.org/jira/browse/SOLR-248 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Priority: Minor > Attachments: SOLR-248-CapitalizationFilter.patch, > SOLR-248-CapitalizationFilter.patch > > > For tokens that are used in faceting, it is nice to have standard > capitalization. > I want "Aerial views" and "Aerial Views" to both be: "Aerial Views" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-254) FunctionQuery.toString() is not correct when using bf=func^1.0
[
https://issues.apache.org/jira/browse/SOLR-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi updated SOLR-254:
Attachment: FunctionQuery.patch
the patch attached
> FunctionQuery.toString() is not correct when using bf=func^1.0
> --
>
> Key: SOLR-254
> URL: https://issues.apache.org/jira/browse/SOLR-254
> Project: Solr
> Issue Type: Bug
> Components: search
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: FunctionQuery.patch
>
>
> To reproduce, try the following URL for example app:
> http://localhost:8983/solr/select?indent=on&version=2.2&q=*%3A*&start=0&rows=10&fl=*%2Cscore&qt=dismax&wt=standard&debugQuery=on&explainOther=&hl.fl=&bf=price
> You'll see the following debug info at parsedquery tag:
> FunctionQuery(org.apache.solr.schema.SortableFloatFieldSource:sfloat(price))^1.0)
> Note that there are three ")", though "(" are two. This happens when you set
> boost to 1.0 (bf=func^1.0).
> If you use othat than 1.0 (try the following URL for boost=2.0), this doesn't
> happen.
> http://localhost:8983/solr/select?indent=on&version=2.2&q=*%3A*&start=0&rows=10&fl=*%2Cscore&qt=dismax&wt=standard&debugQuery=on&explainOther=&hl.fl=&bf=price%5E2.0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-254) FunctionQuery.toString() is not correct when using bf=func^1.0
FunctionQuery.toString() is not correct when using bf=func^1.0
--
Key: SOLR-254
URL: https://issues.apache.org/jira/browse/SOLR-254
Project: Solr
Issue Type: Bug
Components: search
Reporter: Koji Sekiguchi
Priority: Minor
To reproduce, try the following URL for example app:
http://localhost:8983/solr/select?indent=on&version=2.2&q=*%3A*&start=0&rows=10&fl=*%2Cscore&qt=dismax&wt=standard&debugQuery=on&explainOther=&hl.fl=&bf=price
You'll see the following debug info at parsedquery tag:
FunctionQuery(org.apache.solr.schema.SortableFloatFieldSource:sfloat(price))^1.0)
Note that there are three ")", though "(" are two. This happens when you set
boost to 1.0 (bf=func^1.0).
If you use othat than 1.0 (try the following URL for boost=2.0), this doesn't
happen.
http://localhost:8983/solr/select?indent=on&version=2.2&q=*%3A*&start=0&rows=10&fl=*%2Cscore&qt=dismax&wt=standard&debugQuery=on&explainOther=&hl.fl=&bf=price%5E2.0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-254) FunctionQuery.toString() is not correct when using bf=func^1.0
[
https://issues.apache.org/jira/browse/SOLR-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-254.
---
Resolution: Fixed
Thanks Koji, I just committed this.
> FunctionQuery.toString() is not correct when using bf=func^1.0
> --
>
> Key: SOLR-254
> URL: https://issues.apache.org/jira/browse/SOLR-254
> Project: Solr
> Issue Type: Bug
> Components: search
>Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: FunctionQuery.patch
>
>
> To reproduce, try the following URL for example app:
> http://localhost:8983/solr/select?indent=on&version=2.2&q=*%3A*&start=0&rows=10&fl=*%2Cscore&qt=dismax&wt=standard&debugQuery=on&explainOther=&hl.fl=&bf=price
> You'll see the following debug info at parsedquery tag:
> FunctionQuery(org.apache.solr.schema.SortableFloatFieldSource:sfloat(price))^1.0)
> Note that there are three ")", though "(" are two. This happens when you set
> boost to 1.0 (bf=func^1.0).
> If you use othat than 1.0 (try the following URL for boost=2.0), this doesn't
> happen.
> http://localhost:8983/solr/select?indent=on&version=2.2&q=*%3A*&start=0&rows=10&fl=*%2Cscore&qt=dismax&wt=standard&debugQuery=on&explainOther=&hl.fl=&bf=price%5E2.0
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
