[jira] Commented: (SOLR-1169) SortedIntDocSet
[ https://issues.apache.org/jira/browse/SOLR-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12709645#action_12709645 ] Mike Klaas commented on SOLR-1169: -- sweet. intersecting sorted int dicts should be faster in the general case. HashSet will of course win when one set is very small, but I expect this to still be pretty fast anyway. > SortedIntDocSet > --- > > Key: SOLR-1169 > URL: https://issues.apache.org/jira/browse/SOLR-1169 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley >Assignee: Yonik Seeley > Fix For: 1.4 > > > A DocSet type that can skip to support SOLR-1165 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704284#action_12704284 ] Mike Klaas commented on SOLR-1116: -- +1 for url-safe base64 (-_ being the extra chars) > Add a Binary FieldType > -- > > Key: SOLR-1116 > URL: https://issues.apache.org/jira/browse/SOLR-1116 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1116.patch, SOLR-1116.patch > > > Lucene supports binary data for field but Solr has no corresponding field > type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1044) Use Hadoop RPC for inter Solr communication
[
https://issues.apache.org/jira/browse/SOLR-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679466#action_12679466
]
Mike Klaas commented on SOLR-1044:
--
{quote} I haven't yet seen a HTTP server serving more than around 1200 req/sec
(apache HTTPD). A call based server can serve 4k-5k messages easily. (I am
yet to test hadoop RPC) . The proliferation of a large no: of frameworks around
that is a testimony to the superiority of that approach. {/quote}
up to 50,000 req/sec, with keepalive:
http://www.litespeedtech.com/web-server-performance-comparison-litespeed-2.0-vs.html
> Use Hadoop RPC for inter Solr communication
> ---
>
> Key: SOLR-1044
> URL: https://issues.apache.org/jira/browse/SOLR-1044
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Noble Paul
>
> Solr uses http for distributed search . We can make it a whole lot faster if
> we use an RPC mechanism which is more lightweight/efficient.
> Hadoop RPC looks like a good candidate for this.
> The implementation should just have one protocol. It should follow the Solr's
> idiom of making remote calls . A uri + params +[optional stream(s)] . The
> response can be a stream of bytes.
> To make this work we must make the SolrServer implementation pluggable in
> distributed search. Users should be able to choose between the current
> CommonshttpSolrServer, or a HadoopRpcSolrServer .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-952) duplicated code in (Default)SolrHighlighter and HighlightingUtils
[ https://issues.apache.org/jira/browse/SOLR-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12674830#action_12674830 ] Mike Klaas commented on SOLR-952: - HighlightingUtils has been deprecated for at least one release; can't we just rip it out? > duplicated code in (Default)SolrHighlighter and HighlightingUtils > - > > Key: SOLR-952 > URL: https://issues.apache.org/jira/browse/SOLR-952 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.4 >Reporter: Chris Harris >Priority: Minor > Attachments: SOLR-952.patch > > > A large quantity of code is duplicated between the deprecated > HighlightingUtils class and the newer SolrHighlighter and > DefaultSolrHighlighter (which have been getting bug fixes and enhancements). > The Utils class is no longer used anywhere in Solr, but people writing > plugins may be taking advantage of it, so it should be cleaned up. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-793) set a commit time bounds in the command
[
https://issues.apache.org/jira/browse/SOLR-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638825#action_12638825
]
Mike Klaas commented on SOLR-793:
-
I don't see any issue with the code: adddedDocument is always called within a
synchronized context anyway, after all.
One question: right now you have it set to use the minimum of
autocommit/maxTime and commitWithin on the update command. Might it be better
to always use commitWithin, even if it greater than a specified maxTime? This
would allow the insertion of "less important than normal" docs (right now, it
seems only useful for the "more important" case)
> set a commit time bounds in the command
> -
>
> Key: SOLR-793
> URL: https://issues.apache.org/jira/browse/SOLR-793
> Project: Solr
> Issue Type: Improvement
> Components: update
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-793-commitWithin.patch, SOLR-793-commitWithin.patch
>
>
> Currently there are two options for how to handle commiting documents:
> 1. the client explicitly starts the commit via
> 2. set an auto commit value on the server -- clients can assume all documents
> will be commited within that time.
> However, this does not help in the case where the clients know what documents
> need updating quickly and others that could wait. I suggest adding:
> {code:xml}
> ...
> {/code:xml}
> to the update syntax so the client can schedule commits explicitly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-793) set a commit time bounds in the command
[
https://issues.apache.org/jira/browse/SOLR-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637173#action_12637173
]
Mike Klaas commented on SOLR-793:
-
Hey Ryan,
I think this is good functionality and will take a look at the synchro stuff in
the next day or so. I feel somewhat reponsible, being the one who inflicted
it on everyone :)
> set a commit time bounds in the command
> -
>
> Key: SOLR-793
> URL: https://issues.apache.org/jira/browse/SOLR-793
> Project: Solr
> Issue Type: Improvement
> Components: update
>Reporter: Ryan McKinley
>Priority: Minor
> Attachments: SOLR-793-commitWithin.patch, SOLR-793-commitWithin.patch
>
>
> Currently there are two options for how to handle commiting documents:
> 1. the client explicitly starts the commit via
> 2. set an auto commit value on the server -- clients can assume all documents
> will be commited within that time.
> However, this does not help in the case where the clients know what documents
> need updating quickly and others that could wait. I suggest adding:
> {code:xml}
> ...
> {/code:xml}
> to the update syntax so the client can schedule commits explicitly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-777) backword match search, for domain search etc.
[ https://issues.apache.org/jira/browse/SOLR-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632842#action_12632842 ] Mike Klaas commented on SOLR-777: - As Walter mentioned, you don't really want reverse string for matching domains. The best way to store domains is reverse component (www.google.com -> com.google.www); it is one of the admitted failures of the designers of DNS to not do it that way. Storing that in a string field, you can search for revdomain:(com.google com.google.*) to match a domain+subdomains correctly (Note: your prefix query isn't correct, as it would match www.notreallyapache.org). > backword match search, for domain search etc. > - > > Key: SOLR-777 > URL: https://issues.apache.org/jira/browse/SOLR-777 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Koji Sekiguchi >Priority: Minor > Attachments: SOLR-777-reverseStringFilter.patch > > > There is a requirement for searching domains with backward match. For > example, using "apache.org" for a query string, www.apache.org, > lucene.apache.org could be returned. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-766) Remove python client from 1.3 distribution
[ https://issues.apache.org/jira/browse/SOLR-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas resolved SOLR-766. - Resolution: Fixed > Remove python client from 1.3 distribution > -- > > Key: SOLR-766 > URL: https://issues.apache.org/jira/browse/SOLR-766 > Project: Solr > Issue Type: Task > Components: clients - python >Affects Versions: 1.3 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Blocker > Fix For: 1.3 > > Attachments: SOLR-766.patch > > > see solr-dev thread: > http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200809.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-766) Remove python client from 1.3 distribution
[ https://issues.apache.org/jira/browse/SOLR-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-766: Attachment: SOLR-766.patch > Remove python client from 1.3 distribution > -- > > Key: SOLR-766 > URL: https://issues.apache.org/jira/browse/SOLR-766 > Project: Solr > Issue Type: Task > Components: clients - python >Affects Versions: 1.3 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Blocker > Fix For: 1.3 > > Attachments: SOLR-766.patch > > > see solr-dev thread: > http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200809.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-766) Remove python client from 1.3 distribution
[ https://issues.apache.org/jira/browse/SOLR-766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12630004#action_12630004 ] Mike Klaas commented on SOLR-766: - JIRA seems to be not allowing me to upload a patch. Here is the text of the proposed README: Note: As of version 1.3, Solr no longer comes bundled with a Python client. The existing client was not sufficiently maintained or tested as development of Solr progressed, and committers felt that the code was not up to our usual high standards of release. The client bundled with previous versions of Solr will continue to be available indefinitely at: http://svn.apache.org/viewvc/lucene/solr/tags/release-1.2.0/client/python/ Please see http://wiki.apache.org/solr/SolPython for information on third-party Solr python clients. > Remove python client from 1.3 distribution > -- > > Key: SOLR-766 > URL: https://issues.apache.org/jira/browse/SOLR-766 > Project: Solr > Issue Type: Task > Components: clients - python >Affects Versions: 1.3 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Blocker > Fix For: 1.3 > > > see solr-dev thread: > http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200809.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-766) Remove python client from 1.3 distribution
Remove python client from 1.3 distribution -- Key: SOLR-766 URL: https://issues.apache.org/jira/browse/SOLR-766 Project: Solr Issue Type: Task Components: clients - python Affects Versions: 1.3 Reporter: Mike Klaas Assignee: Mike Klaas Priority: Blocker Fix For: 1.3 see solr-dev thread: http://mail-archives.apache.org/mod_mbox/lucene-solr-dev/200809.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-216) Improvements to solr.py
[ https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629981#action_12629981 ] Mike Klaas commented on SOLR-216: - That's great! Be sure to update http://wiki.apache.org/solr/SolPython as the project progresses. > Improvements to solr.py > --- > > Key: SOLR-216 > URL: https://issues.apache.org/jira/browse/SOLR-216 > Project: Solr > Issue Type: Improvement > Components: clients - python >Affects Versions: 1.2 >Reporter: Jason Cater >Assignee: Mike Klaas >Priority: Trivial > Attachments: solr-solrpy-r5.patch, solr.py, solr.py, solr.py, > solr.py, test_all.py > > > I've taken the original solr.py code and extended it to include higher-level > functions. > * Requires python 2.3+ > * Supports SSL (https://) schema > * Conforms (mostly) to PEP 8 -- the Python Style Guide > * Provides a high-level results object with implicit data type conversion > * Supports batching of update commands -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-216) Improvements to solr.py
[ https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12629556#action_12629556 ] Mike Klaas commented on SOLR-216: - Dariusz, Have you thought about publishing the update python client as a thirdparty/standalone package? If it becomes popular and stable, it could be folded back in to the Solr distro, but for the time being I suspect that it will be difficult to work on in trunk (since there don't seem to be core devs who use it). cheers, -Mike > Improvements to solr.py > --- > > Key: SOLR-216 > URL: https://issues.apache.org/jira/browse/SOLR-216 > Project: Solr > Issue Type: Improvement > Components: clients - python >Affects Versions: 1.2 >Reporter: Jason Cater >Assignee: Mike Klaas >Priority: Trivial > Attachments: solr-solrpy-r5.patch, solr.py, solr.py, solr.py, > solr.py, test_all.py > > > I've taken the original solr.py code and extended it to include higher-level > functions. > * Requires python 2.3+ > * Supports SSL (https://) schema > * Conforms (mostly) to PEP 8 -- the Python Style Guide > * Provides a high-level results object with implicit data type conversion > * Supports batching of update commands -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-684) Hudson builds do not have the SVN revision because svnversion is not available
[ https://issues.apache.org/jira/browse/SOLR-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627106#action_12627106 ] Mike Klaas commented on SOLR-684: - Good point, Hoss. > Hudson builds do not have the SVN revision because svnversion is not available > -- > > Key: SOLR-684 > URL: https://issues.apache.org/jira/browse/SOLR-684 > Project: Solr > Issue Type: Task >Affects Versions: 1.3 >Reporter: Lars Kotthoff >Assignee: Hoss Man >Priority: Trivial > Fix For: 1.3 > > > The build file tries to run svnversion when generating the jar manifest to > include the revision number. This fails in Hudson however as the svnversion > executable is not available. > This could be addressed by installing svnversion on the build machine or > using alternative means of determining the revision number. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-684) Hudson builds do not have the SVN revision because svnversion is not available
[
https://issues.apache.org/jira/browse/SOLR-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627090#action_12627090
]
Mike Klaas commented on SOLR-684:
-
In case this ever needs to be done with pure "svn":
$ svn info | grep 'Revision' | awk '{print $2}'
15171
> Hudson builds do not have the SVN revision because svnversion is not available
> --
>
> Key: SOLR-684
> URL: https://issues.apache.org/jira/browse/SOLR-684
> Project: Solr
> Issue Type: Task
>Affects Versions: 1.3
>Reporter: Lars Kotthoff
>Assignee: Hoss Man
>Priority: Trivial
>
> The build file tries to run svnversion when generating the jar manifest to
> include the revision number. This fails in Hudson however as the svnversion
> executable is not available.
> This could be addressed by installing svnversion on the build machine or
> using alternative means of determining the revision number.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-739) Add support for OmitTf
[ https://issues.apache.org/jira/browse/SOLR-739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627049#action_12627049 ] Mike Klaas commented on SOLR-739: - Haven't looked at the patch, but defaulting to omitTf=true is backwards-incompatible (think multi-valued string fields) > Add support for OmitTf > -- > > Key: SOLR-739 > URL: https://issues.apache.org/jira/browse/SOLR-739 > Project: Solr > Issue Type: New Feature >Reporter: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-739.patch > > > Allow setting omitTf in the field schema. Default to true for all but text > fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-474) audit docs for Spellchecker
[
https://issues.apache.org/jira/browse/SOLR-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas resolved SOLR-474.
-
Resolution: Fixed
I've verified the behaviour and updated the wiki page accordingly.
> audit docs for Spellchecker
> ---
>
> Key: SOLR-474
> URL: https://issues.apache.org/jira/browse/SOLR-474
> Project: Solr
> Issue Type: Task
>Affects Versions: 1.3
>Reporter: Hoss Man
>Assignee: Mike Klaas
> Fix For: 1.3
>
>
> according to this troubling comment from Mike, the spellchecker handler
> javadocs (and wiki) may not reflect reality...
> http://www.nabble.com/spellcheckhandler-to14627712.html#a14627712
> {quote}
> Multi-word spell checking is available only with extendedResults=true, and
> only in trunk. I
> believe that the current javadocs are incorrect on this point.
> {quote}
> we should audit/fix this before 1.3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-474) audit docs for Spellchecker
[
https://issues.apache.org/jira/browse/SOLR-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622677#action_12622677
]
Mike Klaas commented on SOLR-474:
-
The issue is more wikidocs vs. behaviour. I apologize I haven't gotten to this
yet--I've been suffering from RSI the last month or so and it has been
difficult to get it non-work computer time. I'll take a look today.
> audit docs for Spellchecker
> ---
>
> Key: SOLR-474
> URL: https://issues.apache.org/jira/browse/SOLR-474
> Project: Solr
> Issue Type: Task
>Affects Versions: 1.3
>Reporter: Hoss Man
>Assignee: Mike Klaas
> Fix For: 1.3
>
>
> according to this troubling comment from Mike, the spellchecker handler
> javadocs (and wiki) may not reflect reality...
> http://www.nabble.com/spellcheckhandler-to14627712.html#a14627712
> {quote}
> Multi-word spell checking is available only with extendedResults=true, and
> only in trunk. I
> believe that the current javadocs are incorrect on this point.
> {quote}
> we should audit/fix this before 1.3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-216) Improvements to solr.py
[ https://issues.apache.org/jira/browse/SOLR-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622391#action_12622391 ] Mike Klaas commented on SOLR-216: - Hi Dariusz, There will almost certainly be no more releases of Solr 1.2. 1.3 will likely be released in less than a month. However, it is good that you published this code so that it can be found by other parties. I'd be much more interested in working toward a client that is compatible with the upcoming 1.3 release (it is unlikely that it can be included, but it can be distributed separately). cheers, -Mike > Improvements to solr.py > --- > > Key: SOLR-216 > URL: https://issues.apache.org/jira/browse/SOLR-216 > Project: Solr > Issue Type: Improvement > Components: clients - python >Affects Versions: 1.2 >Reporter: Jason Cater >Assignee: Mike Klaas >Priority: Trivial > Attachments: solr-solrpy-r5.patch, solr.py, solr.py, solr.py, > solr.py, test_all.py > > > I've taken the original solr.py code and extended it to include higher-level > functions. > * Requires python 2.3+ > * Supports SSL (https://) schema > * Conforms (mostly) to PEP 8 -- the Python Style Guide > * Provides a high-level results object with implicit data type conversion > * Supports batching of update commands -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-659) Explicitly set start and rows per shard for more efficient bulk queries across distributed Solr
[ https://issues.apache.org/jira/browse/SOLR-659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-659: Fix Version/s: (was: 1.3) IMO it is too late in the release process for new features. > Explicitly set start and rows per shard for more efficient bulk queries > across distributed Solr > --- > > Key: SOLR-659 > URL: https://issues.apache.org/jira/browse/SOLR-659 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Brian Whitman >Priority: Minor > Attachments: shards.start_rows.patch > > > The default behavior of setting start and rows on distributed solr (SOLR-303) > is to set start at 0 across all shards and set rows to start+rows across each > shard. This ensures all results are returned for any arbitrary start and rows > setting, but during "bulk queries" (where start is incrementally increased > and rows is kept consistent) the client would need finer control of the > per-shard start and rows parameter as retrieving many thousands of documents > becomes intractable as start grows higher. > Attaching a patch that creates a &shards.start and &shards.rows parameter. If > used, the logic that sets rows to start+rows per shard is overridden and each > shard gets the exact start and rows set in shards.start and shards.rows. The > client will receive up to shards.rows * nShards results and should set rows > accordingly. This makes bulk queries across distributed solr possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-474) audit docs for Spellchecker
[
https://issues.apache.org/jira/browse/SOLR-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617580#action_12617580
]
Mike Klaas commented on SOLR-474:
-
I will look at this before release.
> audit docs for Spellchecker
> ---
>
> Key: SOLR-474
> URL: https://issues.apache.org/jira/browse/SOLR-474
> Project: Solr
> Issue Type: Task
>Affects Versions: 1.3
>Reporter: Hoss Man
>Assignee: Mike Klaas
> Fix For: 1.3
>
>
> according to this troubling comment from Mike, the spellchecker handler
> javadocs (and wiki) may not reflect reality...
> http://www.nabble.com/spellcheckhandler-to14627712.html#a14627712
> {quote}
> Multi-word spell checking is available only with extendedResults=true, and
> only in trunk. I
> believe that the current javadocs are incorrect on this point.
> {quote}
> we should audit/fix this before 1.3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-665) FIFO Cache (Unsynchronized): 9x times performance boost
[ https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617549#action_12617549 ] Mike Klaas commented on SOLR-665: - [quote]We may simply use java.util.concurrent.locks instead of heavy synchronized... we may also use Executor framework instead of single-thread faceting... We may even base SOLR on Apache MINA project.[/quote] Simply replacing synchronized with java.util.concurrent.locks doesn't increase performance. There needs to be a specific strategy for employing these locks in a way that makes sense. For instance, one idea would be to create a read/write lock with the put()'s covered by write and get()'s covered by read. This would allow multiple parallel reads and will be thread-safe. Another is to create something like ConcurrentLinkedHashMap. These strategies should be tested before trying to create a lock-free get() version, which if even possible, would rely deeply on the implementation (such a structure would have to be created from scratch, I believe). I'd expect anyone that is able to create such a thing be familiar enough wiht memory barriers and such issues to be able to deeply explain the problems with double-checked locking off the top of their head (and immediately see such problems in other code) > FIFO Cache (Unsynchronized): 9x times performance boost > --- > > Key: SOLR-665 > URL: https://issues.apache.org/jira/browse/SOLR-665 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 > Environment: JRockit R27 (Java 6) >Reporter: Fuad Efendi > Attachments: FIFOCache.java > > Original Estimate: 672h > Remaining Estimate: 672h > > Attached is modified version of LRUCache where > 1. map = new LinkedHashMap(initialSize, 0.75f, false) - so that > "reordering"/true (performance bottleneck of LRU) is replaced to > "insertion-order"/false (so that it became FIFO) > 2. Almost all (absolutely unneccessary) synchronized statements commented out > See discussion at > http://www.nabble.com/LRUCache---synchronized%21--td16439831.html > Performance metrics (taken from SOLR Admin): > LRU > Requests: 7638 > Average Time-Per-Request: 15300 > Average Request-per-Second: 0.06 > FIFO: > Requests: 3355 > Average Time-Per-Request: 1610 > Average Request-per-Second: 0.11 > Performance increased 9 times which roughly corresponds to a number of CPU in > a system, http://www.tokenizer.org/ (Shopping Search Engine at Tokenizer.org) > Current number of documents: 7494689 > name: filterCache > class:org.apache.solr.search.LRUCache > version: 1.0 > description: LRU Cache(maxSize=1000, initialSize=1000) > stats:lookups : 15966954582 > hits : 16391851546 > hitratio : 0.102 > inserts : 4246120 > evictions : 0 > size : 2668705 > cumulative_lookups : 16415839763 > cumulative_hits : 16411608101 > cumulative_hitratio : 0.99 > cumulative_inserts : 4246246 > cumulative_evictions : 0 > Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-665) FIFO Cache (Unsynchronized): 9x times performance boost
[ https://issues.apache.org/jira/browse/SOLR-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617512#action_12617512 ] Mike Klaas commented on SOLR-665: - I haven't looked at the proposed code at all, but it _is_ possible to design this kind of datastructure, with much care: http://www.ddj.com/hpc-high-performance-computing/208801974 > FIFO Cache (Unsynchronized): 9x times performance boost > --- > > Key: SOLR-665 > URL: https://issues.apache.org/jira/browse/SOLR-665 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 > Environment: JRockit R27 (Java 6) >Reporter: Fuad Efendi > Attachments: FIFOCache.java > > Original Estimate: 672h > Remaining Estimate: 672h > > Attached is modified version of LRUCache where > 1. map = new LinkedHashMap(initialSize, 0.75f, false) - so that > "reordering"/true (performance bottleneck of LRU) is replaced to > "insertion-order"/false (so that it became FIFO) > 2. Almost all (absolutely unneccessary) synchronized statements commented out > See discussion at > http://www.nabble.com/LRUCache---synchronized%21--td16439831.html > Performance metrics (taken from SOLR Admin): > LRU > Requests: 7638 > Average Time-Per-Request: 15300 > Average Request-per-Second: 0.06 > FIFO: > Requests: 3355 > Average Time-Per-Request: 1610 > Average Request-per-Second: 0.11 > Performance increased 9 times which roughly corresponds to a number of CPU in > a system, http://www.tokenizer.org/ (Shopping Search Engine at Tokenizer.org) > Current number of documents: 7494689 > name: filterCache > class:org.apache.solr.search.LRUCache > version: 1.0 > description: LRU Cache(maxSize=1000, initialSize=1000) > stats:lookups : 15966954582 > hits : 16391851546 > hitratio : 0.102 > inserts : 4246120 > evictions : 0 > size : 2668705 > cumulative_lookups : 16415839763 > cumulative_hits : 16411608101 > cumulative_hitratio : 0.99 > cumulative_inserts : 4246246 > cumulative_evictions : 0 > Thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616729#action_12616729 ] Mike Klaas commented on SOLR-139: - [quote]David - storing all data in the search index can be a problem because it can get BIG. Imagine if nutch stored the raw content in the lucene index? (I may be wrong on this) even with Lazy loading, there is a query time cost to having stored fields.[/quote] Splitting it out into another store is much better at scale. A distinct lucene index works relatively well. > Support updateable/modifiable documents > --- > > Key: SOLR-139 > URL: https://issues.apache.org/jira/browse/SOLR-139 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Attachments: Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, getStoredFields.patch, getStoredFields.patch, > getStoredFields.patch, getStoredFields.patch, getStoredFields.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-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-ModifyInputDocuments.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch, > SOLR-269+139-ModifiableDocumentUpdateProcessor.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] Assigned: (SOLR-610) Add support for hl.maxAnalyzedChars=-1 to highlight the whole field
[ https://issues.apache.org/jira/browse/SOLR-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas reassigned SOLR-610: --- Assignee: Mike Klaas > Add support for hl.maxAnalyzedChars=-1 to highlight the whole field > --- > > Key: SOLR-610 > URL: https://issues.apache.org/jira/browse/SOLR-610 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-556-610.patch, SOLR-610-maxanalyzed.patch > > > Add support for specifying negative values for the hl.maxAnalyzedChars > parameter to be able highlight the whole field without having to know its > size. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-610) Add support for hl.maxAnalyzedChars=-1 to highlight the whole field
[ https://issues.apache.org/jira/browse/SOLR-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas resolved SOLR-610. - Resolution: Fixed commited. Thanks lars! > Add support for hl.maxAnalyzedChars=-1 to highlight the whole field > --- > > Key: SOLR-610 > URL: https://issues.apache.org/jira/browse/SOLR-610 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-556-610.patch, SOLR-610-maxanalyzed.patch > > > Add support for specifying negative values for the hl.maxAnalyzedChars > parameter to be able highlight the whole field without having to know its > size. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-556) Highlighting of multi-valued fields returns snippets which span multiple different values
[ https://issues.apache.org/jira/browse/SOLR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas resolved SOLR-556. - Resolution: Fixed committed as part of SOLR-610. thanks Lars! > Highlighting of multi-valued fields returns snippets which span multiple > different values > - > > Key: SOLR-556 > URL: https://issues.apache.org/jira/browse/SOLR-556 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-556-highlight-multivalued.patch, > solr-highlight-multivalued-example.xml > > > When highlighting multi-valued fields, the highlighter sometimes returns > snippets which span multiple values, e.g. with values "foo" and "bar" and > search term "ba" the highlighter will create the snippet "foobar". > Furthermore it sometimes returns smaller snippets than it should, e.g. with > value "foobar" and search term "oo" it will create the snippet "oo" > regardless of hl.fragsize. > I have been unable to determine the real cause for this, or indeed what > actually goes on at all. To reproduce the problem, I've used the following > steps: > * create an index with multi-valued fields, one document should have at least > 3 values for these fields (in my case strings of length between 5 and 15 > Japanese characters -- as far as I can tell plain old ASCII should produce > the same effect though) > * search for part of a value in such a field with highlighting enabled, the > additional parameters I use are hl.fragsize=70, hl.requireFieldMatch=true, > hl.mergeContiguous=true (changing the parameters does not seem to have any > effect on the result though) > * highlighted snippets should show effects described above -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-610) Add support for hl.maxAnalyzedChars=-1 to highlight the whole field
[ https://issues.apache.org/jira/browse/SOLR-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-610: Fix Version/s: 1.3 > Add support for hl.maxAnalyzedChars=-1 to highlight the whole field > --- > > Key: SOLR-610 > URL: https://issues.apache.org/jira/browse/SOLR-610 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-556-610.patch, SOLR-610-maxanalyzed.patch > > > Add support for specifying negative values for the hl.maxAnalyzedChars > parameter to be able highlight the whole field without having to know its > size. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-610) Add support for hl.maxAnalyzedChars=-1 to highlight the whole field
[ https://issues.apache.org/jira/browse/SOLR-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12608878#action_12608878 ] Mike Klaas commented on SOLR-610: - Hi Lars, I was planning on commiting SOLR-556. Would you rather I commit that first, or to produce a unified patch instead? -Mike > Add support for hl.maxAnalyzedChars=-1 to highlight the whole field > --- > > Key: SOLR-610 > URL: https://issues.apache.org/jira/browse/SOLR-610 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Priority: Minor > Attachments: SOLR-610-maxanalyzed.patch > > > Add support for specifying negative values for the hl.maxAnalyzedChars > parameter to be able highlight the whole field without having to know its > size. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-14) Add the ability to preserve the original term when using WordDelimiterFilter
[ https://issues.apache.org/jira/browse/SOLR-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605410#action_12605410 ] Mike Klaas commented on SOLR-14: Also, voting for an issue is a good way to increase its visibility > Add the ability to preserve the original term when using WordDelimiterFilter > > > Key: SOLR-14 > URL: https://issues.apache.org/jira/browse/SOLR-14 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Richard "Trey" Hyde > Attachments: TokenizerFactory.java, WordDelimiterFilter.patch, > WordDelimiterFilter.patch > > > When doing prefix searching, you need to hang on to the original term > othewise you'll miss many matches you should be making. > Data: ABC-12345 > WordDelimiterFitler may change this into > ABC 12345 ABC12345 > A user may enter a search such as > ABC\-123* > Which will fail to find a match given the above scenario. > The attached patch will allow the use of the "preserveOriginal" option to > WordDelimiterFilter and will analyse as > ABC 12345 ABC12345 ABC-12345 > in which case we will get a postive match. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-14) Add the ability to preserve the original term when using WordDelimiterFilter
[ https://issues.apache.org/jira/browse/SOLR-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605403#action_12605403 ] Mike Klaas commented on SOLR-14: Note that it is very easy to use an external TokenFilter, so you could just c&p WDF into your own class and make the changes. (Though I'm not saying that this _shouldn't_ make it in for 1.3) > Add the ability to preserve the original term when using WordDelimiterFilter > > > Key: SOLR-14 > URL: https://issues.apache.org/jira/browse/SOLR-14 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: Richard "Trey" Hyde > Attachments: TokenizerFactory.java, WordDelimiterFilter.patch, > WordDelimiterFilter.patch > > > When doing prefix searching, you need to hang on to the original term > othewise you'll miss many matches you should be making. > Data: ABC-12345 > WordDelimiterFitler may change this into > ABC 12345 ABC12345 > A user may enter a search such as > ABC\-123* > Which will fail to find a match given the above scenario. > The attached patch will allow the use of the "preserveOriginal" option to > WordDelimiterFilter and will analyse as > ABC 12345 ABC12345 ABC-12345 > in which case we will get a postive match. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-556) Highlighting of multi-valued fields returns snippets which span multiple different values
[ https://issues.apache.org/jira/browse/SOLR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603785#action_12603785 ] Mike Klaas commented on SOLR-556: - Hey Lars, Yeah, I'm talking about highlighting 15kB of text in 100-200 character chunks. Maybe I can whip up a perf test for this soon. The reason we probably see this issue differently is that the incorrect behaviour is quite minor for most users (perhaps a bit of punctuation leaking from value to value at most). Once way to correct what you are seeing is to use a tokenizer that creates tokens out of the CJK characters, or things on boundaries. In your case, inserting a fake token when encountering a right bracket [)] would fix the problem, I think. Nevertheless, I think I will probably end up committing your patch after pondering it some more. > Highlighting of multi-valued fields returns snippets which span multiple > different values > - > > Key: SOLR-556 > URL: https://issues.apache.org/jira/browse/SOLR-556 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-556-highlight-multivalued.patch, > solr-highlight-multivalued-example.xml > > > When highlighting multi-valued fields, the highlighter sometimes returns > snippets which span multiple values, e.g. with values "foo" and "bar" and > search term "ba" the highlighter will create the snippet "foobar". > Furthermore it sometimes returns smaller snippets than it should, e.g. with > value "foobar" and search term "oo" it will create the snippet "oo" > regardless of hl.fragsize. > I have been unable to determine the real cause for this, or indeed what > actually goes on at all. To reproduce the problem, I've used the following > steps: > * create an index with multi-valued fields, one document should have at least > 3 values for these fields (in my case strings of length between 5 and 15 > Japanese characters -- as far as I can tell plain old ASCII should produce > the same effect though) > * search for part of a value in such a field with highlighting enabled, the > additional parameters I use are hl.fragsize=70, hl.requireFieldMatch=true, > hl.mergeContiguous=true (changing the parameters does not seem to have any > effect on the result though) > * highlighted snippets should show effects described above -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-556) Highlighting of multi-valued fields returns snippets which span multiple different values
[ https://issues.apache.org/jira/browse/SOLR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603780#action_12603780 ] Mike Klaas commented on SOLR-556: - Thanks for the patch, Lars. I think that the basic approach is sound, though I am a little nervous about the performance implications (especially in the case of phrase highlighting, where we spin up an entirely new spanhighlighter for each value in a multi-valued field). I wonder if I am the only one who highlights large text fields composed of dozens of individual values? > Highlighting of multi-valued fields returns snippets which span multiple > different values > - > > Key: SOLR-556 > URL: https://issues.apache.org/jira/browse/SOLR-556 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-556-highlight-multivalued.patch, > solr-highlight-multivalued-example.xml > > > When highlighting multi-valued fields, the highlighter sometimes returns > snippets which span multiple values, e.g. with values "foo" and "bar" and > search term "ba" the highlighter will create the snippet "foobar". > Furthermore it sometimes returns smaller snippets than it should, e.g. with > value "foobar" and search term "oo" it will create the snippet "oo" > regardless of hl.fragsize. > I have been unable to determine the real cause for this, or indeed what > actually goes on at all. To reproduce the problem, I've used the following > steps: > * create an index with multi-valued fields, one document should have at least > 3 values for these fields (in my case strings of length between 5 and 15 > Japanese characters -- as far as I can tell plain old ASCII should produce > the same effect though) > * search for part of a value in such a field with highlighting enabled, the > additional parameters I use are hl.fragsize=70, hl.requireFieldMatch=true, > hl.mergeContiguous=true (changing the parameters does not seem to have any > effect on the result though) > * highlighted snippets should show effects described above -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-243) Create a hook to allow custom code to create custom IndexReaders
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602860#action_12602860
]
Mike Klaas commented on SOLR-243:
-
Hi John,
Hoss has marked the issue for 1.3, so it will be in the release.
-Mike
> Create a hook to allow custom code to create custom IndexReaders
>
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
> Environment: Solr core
>Reporter: John Wang
>Assignee: Hoss Man
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch, indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch, indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-522) analysis.jsp doesn't show payloads created/modified by tokenizers and tokenfilters
[ https://issues.apache.org/jira/browse/SOLR-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-522: Fix Version/s: 1.3 > analysis.jsp doesn't show payloads created/modified by tokenizers and > tokenfilters > -- > > Key: SOLR-522 > URL: https://issues.apache.org/jira/browse/SOLR-522 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Tricia Williams >Assignee: Mike Klaas >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-522-analysis.jsp.patch, SOLR-522-analysis.jsp.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > Add payload content to the vebose output of the analysis.jsp page for > debugging purposes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-517) highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index
[ https://issues.apache.org/jira/browse/SOLR-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602857#action_12602857 ] Mike Klaas commented on SOLR-517: - Koji: Is this resolved? I seemed to recall that we brought this up on java-dev, but I can't find the thread at the moment. (I don't think that the right thing to do is remove idf fetching of the terms as your patch proposes) > highlighter doesn't work with hl.requireFieldMatch=true on un-optimized index > - > > Key: SOLR-517 > URL: https://issues.apache.org/jira/browse/SOLR-517 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.2, 1.3 >Reporter: Koji Sekiguchi >Priority: Minor > Attachments: SOLR-517.patch, SOLR-517.patch > > > On un-optimized index, highlighter doesn't work with > hl.requireFieldMatch=true. > see: > http://www.nabble.com/hl.requireFieldMatch-and-idf-td16324482.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-460) Improvement to highlighting infrastructure
[ https://issues.apache.org/jira/browse/SOLR-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas closed SOLR-460. --- Resolution: Won't Fix No patch, breaks backward compatibility > Improvement to highlighting infrastructure > -- > > Key: SOLR-460 > URL: https://issues.apache.org/jira/browse/SOLR-460 > Project: Solr > Issue Type: Improvement > Components: highlighter >Affects Versions: 1.3 >Reporter: Sergey Dryganets >Assignee: Otis Gospodnetic >Priority: Minor > > Now I'm write a plugin for SOLR to highlight custom user data > ie my application send to handler on Solr set of documents to highlight in > xml format > handler parse xml, create list of Document (not Lucene object just my > abstraction which content Map > it's enough to properly highlight fields) > So I'm think you can change SolrHighlighter: > public NamedList doHighlighting(DocList docs, Query query, > SolrQueryRequest req, String[] defaultFields) > to > public NamedList doHighlighting(List docs, Query query, > SolrQueryRequest req, String[] defaultFields) > or create some type of provider to retrieve list of abstract Document's > and Highlighter will be more reusable :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-522) analysis.jsp doesn't show payloads created/modified by tokenizers and tokenfilters
[ https://issues.apache.org/jira/browse/SOLR-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas reassigned SOLR-522: --- Assignee: Mike Klaas > analysis.jsp doesn't show payloads created/modified by tokenizers and > tokenfilters > -- > > Key: SOLR-522 > URL: https://issues.apache.org/jira/browse/SOLR-522 > Project: Solr > Issue Type: Improvement > Components: web gui >Reporter: Tricia Williams >Assignee: Mike Klaas >Priority: Trivial > Attachments: SOLR-522-analysis.jsp.patch, SOLR-522-analysis.jsp.patch > > Original Estimate: 0.17h > Remaining Estimate: 0.17h > > Add payload content to the vebose output of the analysis.jsp page for > debugging purposes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-200) Scripts don't work when run as root in ~root and su'ing to a user
[
https://issues.apache.org/jira/browse/SOLR-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas resolved SOLR-200.
-
Resolution: Won't Fix
It doesn't surprise me that "/root" as the indexdir and "/" as solr_home
doesn't work, being root or not. I don't think that this is an important case.
> Scripts don't work when run as root in ~root and su'ing to a user
> -
>
> Key: SOLR-200
> URL: https://issues.apache.org/jira/browse/SOLR-200
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.1.0
>Reporter: Jürgen Hermann
>Priority: Minor
>
> This patch avoids an error due to permission problems when orig_dir is /root
> -orig_dir=$(pwd)
> -cd ${0%/*}/..
> -solr_root=$(pwd)
> -cd ${orig_dir}
> +solr_root=$(cd ${0%/*}/.. && pwd)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-344) New Java API
[
https://issues.apache.org/jira/browse/SOLR-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas closed SOLR-344.
---
Resolution: Invalid
Let's move this discussion to the wiki and mailinglist. It isn't really an
"open issue" for Solr.
> New Java API
>
>
> Key: SOLR-344
> URL: https://issues.apache.org/jira/browse/SOLR-344
> Project: Solr
> Issue Type: Improvement
> Components: clients - java, search, update
>Affects Versions: 1.3
>Reporter: Jonathan Woods
> Attachments: New Java API for Solr.pdf
>
>
> The core Solr codebase urgently needs to expose a new Java API designed for
> use by Java running in Solr's JVM and ultimately by core Solr code itself.
> This API must be (i) object-oriented ('typesafe'), (ii) self-documenting,
> (iii) at the right level of granularity, (iv) designed specifically to expose
> the value which Solr adds over and above Lucene.
> This is an urgent issue for two reasons:
> - Java-Solr integrations represent a use-case which is nearly as important as
> the core Solr use-case in which non-Java clients interact with Solr over HTTP
> - a significant proportion of questions on the mailing lists are clearly from
> people who are attempting such integrations right now.
> This point in Solr development - some way out from the 1.3 release - might be
> the right time to do the development and refactoring necessary to produce
> this API. We can do this without breaking any backward compatibility from
> the point of view of XML/HTTP and JSON-like clients, and without altering the
> core Solr algorithms which make it so efficient. If we do this work now, we
> can significantly speed up the spread of Solr.
> Eventually, this API should be part of core Solr code, not hived off into
> some separate project nor in a non-first-class package space. It should be
> capable of forming the foundation of any new Solr development which doesn't
> need to delve into low level constructs like DocSet and so on - and any new
> development which does need to do just that should be a candidate for
> incorporation into the API at the some level. Whether or not it will ever be
> worth re-writing existing code is a matter of opinion; but the Java API
> should be such that if it had existed before core plug-ins were written, it
> would have been natural to use it when writing them.
> I've attached a PDF which makes the case for this API. Apologies for
> delivering it as an attachment, but I wanted to embed pics and a bit of
> formatting.
> I'll update this issue in the next few days to give a prototype of this API
> to suggest what it might look like at present. This will build on the work
> already done in Solrj and SearchComponents
> (https://issues.apache.org/jira/browse/SOLR-281), and will be a patch on an
> up-to-date revision of Solr trunk.
> [PS:
> 1. Having written most of this, I then properly looked at
> SearchComponents/SOLR-281 and read
> http://www.nabble.com/forum/ViewPost.jtp?post=11050274&framed=y, which says
> much the same thing albeit more quickly! And weeks ago, too. But this
> proposal is angled slightly differently:
> - it focusses on the value of creating an API not only for internal Solr
> consumption, but for local Java clients
> - it focusses on designing a Java API without constantly being hobbled by
> HTTP-Java
> - it's suggesting that the SearchComponents work should result in a Java API
> which can be used as much by third party Java as by ResponseBuilder.
> 2. I've made some attempt to address Hoss's point
> (http://www.nabble.com/search-components-%28plugins%29-tf3898040.html#6551097579454875774)
> - that an API like this would need to maintain enough state e.g. to allow an
> initial search to later be faceted, highlighted etc without going back to the
> start each time - but clearly the proof of the pudding will be in the
> prototype.
> 3. Again, I've just discovered SOLR-212 (DirectSolrConnection). I think all
> my comments about Solrj apply to this, useful though it clearly is.]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-424) The ruby output type produces incorrect output for numeric types without a value
[
https://issues.apache.org/jira/browse/SOLR-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-424:
Eric or Yonik, do you want to mentor this for 1.3?
> The ruby output type produces incorrect output for numeric types without a
> value
>
>
> Key: SOLR-424
> URL: https://issues.apache.org/jira/browse/SOLR-424
> Project: Solr
> Issue Type: Bug
> Components: clients - ruby - flare
>Affects Versions: 1.1.0, 1.2, 1.3
>Reporter: Kurt Schrader
>Priority: Critical
> Fix For: 1.3
>
> Attachments: fix_ruby_output.patch,
> TextResponseWriter-SOLR-424.patch, zero_length_int.patch
>
>
> When parsing the Ruby output returned from Solr, if a numerical value has no
> value in the index, it causes an invalid Ruby hash to be returned. For
> instance:
> {code:xml}
> 'response'=>{'numFound'=>1,'start'=>0,'maxScore'=>4.951244,'docs'=>[
> {
>'subclass_t'=>'Protocol',
>'pk_i'=>1,
>'id'=>'Protocol:1',
>'name_t'=>'Falcipain IC50',
>'group_id_i'=>,
>'score'=>4.951244}]
> }}
> {code}
> is not a valid hash because 'group_id_i' does not resolve to anything. It
> should resolve to nil:
> {code:xml}
> 'response'=>{'numFound'=>1,'start'=>0,'maxScore'=>4.951244,'docs'=>[
> {
>'subclass_t'=>'Protocol',
>'pk_i'=>1,
>'id'=>'Protocol:1',
>'name_t'=>'Falcipain IC50',
>'group_id_i'=>nil,
>'score'=>4.951244}]
> }}
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-489) Added @deprecation Javadoc comments
[ https://issues.apache.org/jira/browse/SOLR-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas reassigned SOLR-489: --- Assignee: Mike Klaas > Added @deprecation Javadoc comments > --- > > Key: SOLR-489 > URL: https://issues.apache.org/jira/browse/SOLR-489 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Sean Timm >Assignee: Mike Klaas >Priority: Trivial > Fix For: 1.3 > > Attachments: deprecationDocumentation.patch > > > In a number of files, @Deprecation annotations were added without > accompanying @deprecation Javadoc comments to explain what to use now. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-545) remove MultiCore "default" core / cleanup DispatchHandlera
[ https://issues.apache.org/jira/browse/SOLR-545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas reassigned SOLR-545: --- Assignee: Ryan McKinley assigning 1.3 multicore stuff to Ryan > remove MultiCore "default" core / cleanup DispatchHandlera > --- > > Key: SOLR-545 > URL: https://issues.apache.org/jira/browse/SOLR-545 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.3 > > > MultiCore should require a core name in the URL. If the core name is > missing, there should be a 404, not a valid core. That is: > http://localhost:8983/solr/select?q=*:* should return 404. > While we are at it, we should cleanup the DispatchHandler. Perhaps the best > approach is to treat single core as multicore with only one core? As is the > tangle of potential paths is ugly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-560) Convert JDK logging to SLF4J
[ https://issues.apache.org/jira/browse/SOLR-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas reassigned SOLR-560: --- Assignee: Ryan McKinley It's Ryan's patch. > Convert JDK logging to SLF4J > > > Key: SOLR-560 > URL: https://issues.apache.org/jira/browse/SOLR-560 > Project: Solr > Issue Type: Wish >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.3 > > Attachments: slf4j-api-1.5.0.jar, slf4j-jdk14-1.5.0.jar, > SOLR-560-slf4j.patch, SOLR-560-slf4j.patch, SOLR-560-slf4j.patch > > > After lots of discussion, we should consider using SLF4j to enable more > flexibility in logging configuration. > See: > http://www.nabble.com/Solr-Logging-td16836646.html > http://www.nabble.com/logging-through-log4j-td13747253.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-243) Create a hook to allow custom code to create custom IndexReaders
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-243:
Do we still want to target 1.3 here? (Seems like there is a lot to do before
it is commit-worthy, based on the comments)
> Create a hook to allow custom code to create custom IndexReaders
>
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
> Environment: Solr core
>Reporter: John Wang
>Assignee: Hoss Man
> Fix For: 1.3
>
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch, indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch, indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-410) Audit the new ResponseBuilder class
[ https://issues.apache.org/jira/browse/SOLR-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602834#action_12602834 ] Mike Klaas commented on SOLR-410: - Ryan, can this be closed? > Audit the new ResponseBuilder class > --- > > Key: SOLR-410 > URL: https://issues.apache.org/jira/browse/SOLR-410 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Ryan McKinley > Fix For: 1.3 > > > In SOLR-281, we added a ResponseBuilder class to help search components > communicate with one another. Before releasing 1.3, we need to make sure > this is the best design and that it is an interface we can support in the > future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-84: --- Fix Version/s: (was: 1.3) > New Solr logo? > -- > > Key: SOLR-84 > URL: https://issues.apache.org/jira/browse/SOLR-84 > Project: Solr > Issue Type: Improvement >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, > logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-f.jpg, > solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, > solr-nick.gif, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, > sslogo-solr2-flare.jpg, sslogo-solr2.jpg, sslogo-solr3.jpg > > > Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) > sarraux-dessous.ch) has reworked his logo proposal to be more "solar". > This can either be the start of a logo contest, or if people like it we could > adopt it. The gradients can make it a bit hard to integrate, not sure if this > is really a problem. > WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-484) Solr Website changes
[ https://issues.apache.org/jira/browse/SOLR-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-484: Fix Version/s: (was: 1.3) > Solr Website changes > > > Key: SOLR-484 > URL: https://issues.apache.org/jira/browse/SOLR-484 > Project: Solr > Issue Type: Bug > Components: documentation >Reporter: Grant Ingersoll >Priority: Minor > > In looking at the Solr website it has many of the same issues that Lucene > Java did when it comes to ASF policies about nightly builds, etc. concerning > the Javadocs > See > http://lucene.markmail.org/message/a7k7kujxkhwjwfy6?q=nightly+developer+releases+list:org%2Eapache%2Elucene%2Ejava-dev+from:%22Doug+Cutting+(JIRA)%22&page=1 > and > http://lucene.markmail.org/message/vaks6omed4l6buth?q=nightly+developer+releases+list:org%2Eapache%2Elucene%2Ejava-dev+from:%22Doug+Cutting+(JIRA)%22&page=1 > This would suggest a change like Hadoop and Lucene Java did to separate out > the main site, release docs (javadocs, any other?) and developer resources. > Currently the javadocs on the main page are the nightly and should be made > less prominent. -- 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 ] Mike Klaas updated SOLR-284: Fix Version/s: (was: 1.3) > 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 > Attachments: libs.zip, rich.patch, rich.patch, rich.patch, > rich.patch, source.zip, test-files.zip, test-files.zip, test.zip > > > 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-351) external value source
[ https://issues.apache.org/jira/browse/SOLR-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-351: Fix Version/s: (was: 1.3) > external value source > - > > Key: SOLR-351 > URL: https://issues.apache.org/jira/browse/SOLR-351 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Yonik Seeley > Attachments: ExternalFileField.patch > > > Need a way to rapidly do a bulk update of a single field for use as a > component in a function query (no need to be able to search on it). > Idea: create an ExternalValueSource fieldType that reads it's values from a > file. The file could be simple id,val records, and stored in the index > directory so it would get replicated. > Values could optionally be updated more often than the searcher > (hashCode/equals should take this into account to prevent caching issues). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-433) MultiCore and SpellChecker replication
[ https://issues.apache.org/jira/browse/SOLR-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-433: Fix Version/s: (was: 1.3) > MultiCore and SpellChecker replication > -- > > Key: SOLR-433 > URL: https://issues.apache.org/jira/browse/SOLR-433 > Project: Solr > Issue Type: Improvement > Components: replication, spellchecker >Affects Versions: 1.3 >Reporter: Otis Gospodnetic > Attachments: RunExecutableListener.patch, solr-433.patch, > spellindexfix.patch > > > With MultiCore functionality coming along, it looks like we'll need to be > able to: > A) snapshot each core's index directory, and > B) replicate any and all cores' complete data directories, not just their > index directories. > Pulled from the "spellchecker and multi-core index replication" thread - > http://markmail.org/message/pj2rjzegifd6zm7m > Otis: > I think that makes sense - distribute everything for a given core, not just > its index. And the spellchecker could then also have its data dir (and only > index/ underneath really) and be replicated in the same fashion. > Right? > Ryan: > Yes, that was my thought. If an arbitrary directory could be distributed, > then you could have > /path/to/dist/index/... > /path/to/dist/spelling-index/... > /path/to/dist/foo > and that would all get put into a snapshot. This would also let you put > multiple cores within a single distribution: > /path/to/dist/core0/index/... > /path/to/dist/core0/spelling-index/... > /path/to/dist/core0/foo > /path/to/dist/core1/index/... > /path/to/dist/core1/spelling-index/... > /path/to/dist/core1/foo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-435) QParser must validate existance/absense of "q" parameter
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-435:
Fix Version/s: (was: 1.3)
> QParser must validate existance/absense of "q" parameter
>
>
> Key: SOLR-435
> URL: https://issues.apache.org/jira/browse/SOLR-435
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 1.3
>Reporter: Ryan McKinley
>
> Each QParser should check if "q" exists or not. For some it will be required
> others not.
> currently it throws a null pointer:
> {code}
> java.lang.NullPointerException
> at org.apache.solr.common.util.StrUtils.splitSmart(StrUtils.java:36)
> at
> org.apache.solr.search.OldLuceneQParser.parse(LuceneQParserPlugin.java:104)
> at org.apache.solr.search.QParser.getQuery(QParser.java:80)
> at
> org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:67)
> at
> org.apache.solr.handler.SearchHandler.handleRequestBody(SearchHandler.java:150)
> ...
> {code}
> see:
> http://www.nabble.com/query-parsing-error-to14124285.html#a14140108
--
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 ] Mike Klaas updated SOLR-284: Affects Version/s: (was: 1.3) Removing from 1.3. No committer has taken ownership. (It might make sense as a contrib, but I can see the argument for not duplicating tika) > 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 > Fix For: 1.3 > > Attachments: libs.zip, rich.patch, rich.patch, rich.patch, > rich.patch, source.zip, test-files.zip, test-files.zip, test.zip > > > 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-572) Spell Checker as a Search Component
[ https://issues.apache.org/jira/browse/SOLR-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602828#action_12602828 ] Mike Klaas commented on SOLR-572: - [quote]Another use case is where Solr is used with indices that are not indices for a narrow domain or that don't have nice, clean, short fields that can be used for populating the SC index. For example, if the index consists of a pile of web pages, I don't think I'd want to use their data (not even their titles) to populate the SC index. I'd really want just a plain dictionary-powered SCRH.[/quote] It works great, actually. That was you get all the abbreviations, jargon, proper names, etc. Thresholding help prevent most of the cruft from appearing in the index. > Spell Checker as a Search Component > --- > > Key: SOLR-572 > URL: https://issues.apache.org/jira/browse/SOLR-572 > Project: Solr > Issue Type: New Feature > Components: spellchecker >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, SOLR-572.patch, > SOLR-572.patch, SOLR-572.patch > > > Expose the Lucene contrib SpellChecker as a Search Component. Provide the > following features: > * Allow creating a spell index on a given field and make it possible to have > multiple spell indices -- one for each field > * Give suggestions on a per-field basis > * Given a multi-word query, give only one consistent suggestion > * Process the query with the same analyzer specified for the source field and > process each token separately > * Allow the user to specify minimum length for a token (optional) > Consistency criteria for a multi-word query can consist of the following: > * Preserve the correct words in the original query as it is > * Never give duplicate words in a suggestion -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-536) Automatic binding of results to Beans (for solrj)
[
https://issues.apache.org/jira/browse/SOLR-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602744#action_12602744
]
Mike Klaas commented on SOLR-536:
-
> This is expensive
> private final Map> infocache =
>Collections.synchronizedMap( new HashMap>() );
> Let us make it
> private final Map> infocache =
>new ConcurrentHashMap>() ;
Expensive? I'd expect the synchronizedMap to be faster and more memory
compact. The ConcurrentHashMap is definitely more concurrent, though.
> Automatic binding of results to Beans (for solrj)
> -
>
> Key: SOLR-536
> URL: https://issues.apache.org/jira/browse/SOLR-536
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Affects Versions: 1.3
>Reporter: Noble Paul
>Assignee: Ryan McKinley
>Priority: Minor
> Fix For: 1.3
>
> Attachments: SOLR-536.patch, SOLR-536.patch, SOLR-536.patch
>
>
> as we are using java5 .we can use annotations to bind SolrDocument to java
> beans directly.
> This can make the usage of solrj a bit simpler
> The QueryResponse class in solrj can have an extra method as follows
> public List getResultBeans(Class klass)
> and the bean can have annotations as
> class MyBean{
> @Field("id") //name is optional
> String id;
> @Field("category")
> List categories
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-556) Highlighting of multi-valued fields returns snippets which span multiple different values
[ https://issues.apache.org/jira/browse/SOLR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602541#action_12602541 ] Mike Klaas commented on SOLR-556: - Ah, I see what the problem is: Although it is impossible for tokens from different values to appear in the same fragment (due to the semantics of MultiValuedTokenFilter), the non-token text (typically, punctuation) from different values can bleed into the same fragment, since lucene's highlighter can only create a new fragment on token boundaries. Unfortunately SOLR-553 was committed a day after you submitted your patch, and rearranges the code slightly so that it no longer applies. Could you sync the patch with trunk? I think the basic approach is sound. > Highlighting of multi-valued fields returns snippets which span multiple > different values > - > > Key: SOLR-556 > URL: https://issues.apache.org/jira/browse/SOLR-556 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: solr-highlight-multivalued-example.xml, > solr-highlight-multivalued.patch > > > When highlighting multi-valued fields, the highlighter sometimes returns > snippets which span multiple values, e.g. with values "foo" and "bar" and > search term "ba" the highlighter will create the snippet "foobar". > Furthermore it sometimes returns smaller snippets than it should, e.g. with > value "foobar" and search term "oo" it will create the snippet "oo" > regardless of hl.fragsize. > I have been unable to determine the real cause for this, or indeed what > actually goes on at all. To reproduce the problem, I've used the following > steps: > * create an index with multi-valued fields, one document should have at least > 3 values for these fields (in my case strings of length between 5 and 15 > Japanese characters -- as far as I can tell plain old ASCII should produce > the same effect though) > * search for part of a value in such a field with highlighting enabled, the > additional parameters I use are hl.fragsize=70, hl.requireFieldMatch=true, > hl.mergeContiguous=true (changing the parameters does not seem to have any > effect on the result though) > * highlighted snippets should show effects described above -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-161) Dangling dash causes stack trace
[
https://issues.apache.org/jira/browse/SOLR-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602038#action_12602038
]
Mike Klaas commented on SOLR-161:
-
> It is really a Lucene query parser bug, but it wouldn't hurt to do s/(.*)-/&/
> as a workaround. Assuming my ed(1) syntax is still > >fresh. Regardless, no
> query string should ever give a stack trace
This might be hard to guarantee. Already there are four issues details
specific ways that dismax that barf on input. A lot of the suggestions above
are of the form of detecting a specific failure mode and correcting it, which
does not guarantee that you will catch them all.
A robust way to do it is parse the query into an AST using a grammar in a way
that matches the query as well as possible (dropping the stuff that doesn't
fit). Unfortunately, this is duplicative of the lucene parsing logic, and it
would be nicer add a "relaxed" mode to lucene rather than pre-parsing the query.
(The reparse+reassemble method is what we use, btw. It is written in python
but it might be possible to translate to java.)
> Dangling dash causes stack trace
>
>
> Key: SOLR-161
> URL: https://issues.apache.org/jira/browse/SOLR-161
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: 1.1.0
> Environment: Java 1.5, Tomcat 5.5.17, Fedora Core 4, Intel
>Reporter: Walter Underwood
>
> I'm running tests from our search logs, and we have a query that ends in a
> dash. That caused a stack trace.
> org.apache.lucene.queryParser.ParseException: Cannot parse 'digging for the
> truth -': Encountered "" at line 1, column 23.
> Was expecting one of:
> "(" ...
> ...
> ...
> ...
> ...
> "[" ...
> "{" ...
> ...
>
> at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:127)
> at
> org.apache.solr.request.DisMaxRequestHandler.handleRequest(DisMaxRequestHandler.java:272)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:595)
> at org.apache.solr.servlet.SolrServlet.doGet(SolrServlet.java:92)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-583) Name Service
[ https://issues.apache.org/jira/browse/SOLR-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-583: Fix Version/s: (was: 1.3) > Name Service > > > Key: SOLR-583 > URL: https://issues.apache.org/jira/browse/SOLR-583 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Jason Rutherglen > > Coordinates distributed search servers. Central point of administration for > a Solr cluster. Enables automatic master slave failover. Should use an open > source SQL database engine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-583) Name Service
[ https://issues.apache.org/jira/browse/SOLR-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598880#action_12598880 ] Mike Klaas commented on SOLR-583: - Jason, it would be better to hash out ideas/future directions on the wiki and solr-dev than to create stubs in JIRA > Name Service > > > Key: SOLR-583 > URL: https://issues.apache.org/jira/browse/SOLR-583 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 >Reporter: Jason Rutherglen > > Coordinates distributed search servers. Central point of administration for > a Solr cluster. Enables automatic master slave failover. Should use an open > source SQL database engine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-506) Enabling HTTP Cache headers should be configurable on a per-handler basis
[ https://issues.apache.org/jira/browse/SOLR-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-506: Fix Version/s: (was: 1.3) > Enabling HTTP Cache headers should be configurable on a per-handler basis > - > > Key: SOLR-506 > URL: https://issues.apache.org/jira/browse/SOLR-506 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar > > HTTP cache headers are needed only for select handler's response and it does > not make much sense to enable it globally for all Solr responses. > Therefore, enabling/disabling cache headers should be configurable on a > per-handler basis. It should be enabled by default on the select request > handler and disabled by default on all others. It should be possible to > override these defaults through configuration as well as through API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-561) Solr replication by Solr (for windows also)
[ https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-561: Fix Version/s: (was: 1.3) > Solr replication by Solr (for windows also) > --- > > Key: SOLR-561 > URL: https://issues.apache.org/jira/browse/SOLR-561 > Project: Solr > Issue Type: New Feature > Components: replication >Affects Versions: 1.3 > Environment: All >Reporter: Noble Paul > > The current replication strategy in solr involves shell scripts . The > following are the drawbacks with the approach > * It does not work with windows > * Replication works as a separate piece not integrated with solr. > * Cannot control replication from solr admin/JMX > * Each operation requires manual telnet to the host > Doing the replication in java has the following advantages > * Platform independence > * Manual steps can be completely eliminated. Everything can be driven from > solrconfig.xml . > ** Adding the url of the master in the slaves should be good enough to enable > replication. Other things like frequency of > snapshoot/snappull can also be configured . All other information can be > automatically obtained. > * Start/stop can be triggered from solr/admin or JMX > * Can get the status/progress while replication is going on. It can also > abort an ongoing replication > * No need to have a login into the machine > This issue can track the implementation of solr replication in java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-551) SOlr replication should include the schema also
[ https://issues.apache.org/jira/browse/SOLR-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-551: Fix Version/s: (was: 1.3) > SOlr replication should include the schema also > --- > > Key: SOLR-551 > URL: https://issues.apache.org/jira/browse/SOLR-551 > Project: Solr > Issue Type: Improvement > Components: replication >Affects Versions: 1.3 >Reporter: Noble Paul > > The current Solr replication just copy the data directory . So if the > schema changes and I do a re-index it will blissfully copy the index > and the slaves will fail because of incompatible schema. > So the steps we follow are > * Stop rsync on slaves > * Update the master with new schema > * re-index data > * forEach slave > ** Kill the slave > ** clean the data directory > ** install the new schema > ** restart > ** do a manual snappull > The amount of work the admin needs to do is quite significant > (depending on the no:of slaves). These are manual steps and very error > prone > The solution : > Make the replication mechanism handle the schema replication also. So > all I need to do is to just change the master and the slaves synch > automatically > What is a good way to implement this? > We have an idea along the following lines > This should involve changes to the snapshooter and snappuller scripts > and the snapinstaller components > Everytime the snapshooter takes a snapshot it must keep the timestamps > of schema.xml and elevate.xml (all the files which might affect the > runtime behavior in slaves) > For subsequent snapshots if the timestamps of any of them is changed > it must copy the all of them also for replication. > The snappuller copies the new directory as usual > The snapinstaller checks if these config files are present , > if yes, > * It can create a temporary core > * install the changed index and configuration > * load it completely and swap it out with the original core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-565) Component to abstract shards from clients
[ https://issues.apache.org/jira/browse/SOLR-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-565: Fix Version/s: (was: 1.3) > Component to abstract shards from clients > - > > Key: SOLR-565 > URL: https://issues.apache.org/jira/browse/SOLR-565 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: patrick o'leary >Priority: Minor > Attachments: distributor_component.patch > > > A component that will remove the need for calling clients to provide the > shards parameter for > a distributed search. > As systems grow, it's better to manage shards with in solr, rather than > managing each client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-563) Contrib area for Solr
[ https://issues.apache.org/jira/browse/SOLR-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-563: Fix Version/s: (was: 1.3) > Contrib area for Solr > - > > Key: SOLR-563 > URL: https://issues.apache.org/jira/browse/SOLR-563 > Project: Solr > Issue Type: Task >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar > Attachments: SOLR-563.patch > > > Add a contrib area for Solr and modify existing build.xml to build, package > and distribute contrib projects also. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-383) Add support for globalization/culture management
[ https://issues.apache.org/jira/browse/SOLR-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas resolved SOLR-383. - Resolution: Fixed Fix Version/s: (was: 1.3) > Add support for globalization/culture management > > > Key: SOLR-383 > URL: https://issues.apache.org/jira/browse/SOLR-383 > Project: Solr > Issue Type: Improvement > Components: clients - C# >Affects Versions: 1.3 >Reporter: Jeff Rodenburg >Assignee: Jeff Rodenburg >Priority: Minor > > SolrSharp should supply configuration and/or programmatic control over > windows culture settings. This is important for working with data being > saved to indexes that carry certain formatting expectations for various types > of fields, both in SolrSharp as well as the solr field counterparts on the > server side. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-579) Extend SimplePost with RecurseDirectories, threads, document encoding , number of docs per commit
[ https://issues.apache.org/jira/browse/SOLR-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-579: Fix Version/s: (was: 1.3) > Extend SimplePost with RecurseDirectories, threads, document encoding , > number of docs per commit > - > > Key: SOLR-579 > URL: https://issues.apache.org/jira/browse/SOLR-579 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.3 > Environment: Applies to all platforms >Reporter: Patrick Debois >Priority: Minor > Original Estimate: 72h > Remaining Estimate: 72h > > -When specifying a directory, simplepost should read also the contents of a > directory > New options for the commandline (some only usefull in DATAMODE= files) > -RECURSEDIRS > Recursive read of directories as an option, this is usefull for > directories with a lot of files where the commandline expansion fails and > xargs is too slow > -DOCENCODING (default = system encoding or UTF-8) > For non utf-8 clients , simplepost should include a way to set the > encoding of the documents posted > -THREADSIZE (default =1 ) > For large volume posts, a threading pool makes sense , using JDK 1.5 > Threadpool model > -DOCSPERCOMMIT (default = 1) > Number of documents after which a commit is done, instead of only at > the end > Note: not to break the existing behaviour of the existing SimplePost tool > (post.sh) might be used in scripts -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-536) Automatic binding of results to Beans (for solrj)
[
https://issues.apache.org/jira/browse/SOLR-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-536:
Fix Version/s: (was: 1.3)
> Automatic binding of results to Beans (for solrj)
> -
>
> Key: SOLR-536
> URL: https://issues.apache.org/jira/browse/SOLR-536
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Affects Versions: 1.3
>Reporter: Noble Paul
>Priority: Minor
> Attachments: SOLR-536.patch
>
>
> as we are using java5 .we can use annotations to bind SolrDocument to java
> beans directly.
> This can make the usage of solrj a bit simpler
> The QueryResponse class in solrj can have an extra method as follows
> public List getResultBeans(Class klass)
> and the bean can have annotations as
> class MyBean{
> @Field("id") //name is optional
> String id;
> @Field("category")
> List categories
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-556) Highlighting of multi-valued fields returns snippets which span multiple different values
[ https://issues.apache.org/jira/browse/SOLR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-556: Fix Version/s: 1.3 > Highlighting of multi-valued fields returns snippets which span multiple > different values > - > > Key: SOLR-556 > URL: https://issues.apache.org/jira/browse/SOLR-556 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Assignee: Mike Klaas >Priority: Minor > Fix For: 1.3 > > Attachments: solr-highlight-multivalued-example.xml, > solr-highlight-multivalued.patch > > > When highlighting multi-valued fields, the highlighter sometimes returns > snippets which span multiple values, e.g. with values "foo" and "bar" and > search term "ba" the highlighter will create the snippet "foobar". > Furthermore it sometimes returns smaller snippets than it should, e.g. with > value "foobar" and search term "oo" it will create the snippet "oo" > regardless of hl.fragsize. > I have been unable to determine the real cause for this, or indeed what > actually goes on at all. To reproduce the problem, I've used the following > steps: > * create an index with multi-valued fields, one document should have at least > 3 values for these fields (in my case strings of length between 5 and 15 > Japanese characters -- as far as I can tell plain old ASCII should produce > the same effect though) > * search for part of a value in such a field with highlighting enabled, the > additional parameters I use are hl.fragsize=70, hl.requireFieldMatch=true, > hl.mergeContiguous=true (changing the parameters does not seem to have any > effect on the result though) > * highlighted snippets should show effects described above -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-553) Highlighter does not match phrase queries correctly
[ https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597657#action_12597657 ] Mike Klaas commented on SOLR-553: - [quote]Added explicit check for usePhraseHighlighter=true to avoid things like usePhraseHighlighter=false to turn it on.[/quote] I'm not sure I follow you here. Just to verify: - the default is to use SpanScorer when the query is a "pure" phrase query - you can force SS with usePhraseHighlighting - queries that are mixed queries with keywords and phrases are still problematic. If this is correct, is there any point in the usePhraseHighlighter parameter? I don't see where it would entail different behaviour. Also, what are the consequences for dismax queries (pure or mixed)? > Highlighter does not match phrase queries correctly > --- > > Key: SOLR-553 > URL: https://issues.apache.org/jira/browse/SOLR-553 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: all >Reporter: Brian Whitman >Assignee: Otis Gospodnetic > Attachments: highlighttest.xml, Solr-553.patch, Solr-553.patch, > Solr-553.patch > > > http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html > Say we search for the band "I Love You But I've Chosen Darkness" > .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E > The highlight returns a snippet that does have the name altogether: > Lights (Live) : I Love You But > I've Chosen Darkness : > But also returns unrelated snips from the same page: > Black Francis Shop "I Think I Love > You" > A correct highlighter should not return snippets that do not match the phrase > exactly. > LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem > from the Lucene end. Solr should get it too. > Related: SOLR-575 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-576) Make DocSetHitCollector public
[ https://issues.apache.org/jira/browse/SOLR-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597288#action_12597288 ] Mike Klaas commented on SOLR-576: - This is reasonable; I have a whole org/apache/solr/search directory structure in my project just to get access to this class. ISTM that it should be documented before being made public, though. > Make DocSetHitCollector public > -- > > Key: SOLR-576 > URL: https://issues.apache.org/jira/browse/SOLR-576 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Priority: Minor > > Make org.apache.solr.search.DocSetHitCollector public for use by other code -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-556) Highlighting of multi-valued fields returns snippets which span multiple different values
[ https://issues.apache.org/jira/browse/SOLR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas reassigned SOLR-556: --- Assignee: Mike Klaas > Highlighting of multi-valued fields returns snippets which span multiple > different values > - > > Key: SOLR-556 > URL: https://issues.apache.org/jira/browse/SOLR-556 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Assignee: Mike Klaas >Priority: Minor > Attachments: solr-highlight-multivalued-example.xml, > solr-highlight-multivalued.patch > > > When highlighting multi-valued fields, the highlighter sometimes returns > snippets which span multiple values, e.g. with values "foo" and "bar" and > search term "ba" the highlighter will create the snippet "foobar". > Furthermore it sometimes returns smaller snippets than it should, e.g. with > value "foobar" and search term "oo" it will create the snippet "oo" > regardless of hl.fragsize. > I have been unable to determine the real cause for this, or indeed what > actually goes on at all. To reproduce the problem, I've used the following > steps: > * create an index with multi-valued fields, one document should have at least > 3 values for these fields (in my case strings of length between 5 and 15 > Japanese characters -- as far as I can tell plain old ASCII should produce > the same effect though) > * search for part of a value in such a field with highlighting enabled, the > additional parameters I use are hl.fragsize=70, hl.requireFieldMatch=true, > hl.mergeContiguous=true (changing the parameters does not seem to have any > effect on the result though) > * highlighted snippets should show effects described above -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-556) Highlighting of multi-valued fields returns snippets which span multiple different values
[ https://issues.apache.org/jira/browse/SOLR-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597226#action_12597226 ] Mike Klaas commented on SOLR-556: - Thanks for the report, Lars. I'll take a look at this shortly. > Highlighting of multi-valued fields returns snippets which span multiple > different values > - > > Key: SOLR-556 > URL: https://issues.apache.org/jira/browse/SOLR-556 > Project: Solr > Issue Type: Bug > Components: highlighter >Affects Versions: 1.3 > Environment: Tomcat 5.5 >Reporter: Lars Kotthoff >Priority: Minor > Attachments: solr-highlight-multivalued-example.xml, > solr-highlight-multivalued.patch > > > When highlighting multi-valued fields, the highlighter sometimes returns > snippets which span multiple values, e.g. with values "foo" and "bar" and > search term "ba" the highlighter will create the snippet "foobar". > Furthermore it sometimes returns smaller snippets than it should, e.g. with > value "foobar" and search term "oo" it will create the snippet "oo" > regardless of hl.fragsize. > I have been unable to determine the real cause for this, or indeed what > actually goes on at all. To reproduce the problem, I've used the following > steps: > * create an index with multi-valued fields, one document should have at least > 3 values for these fields (in my case strings of length between 5 and 15 > Japanese characters -- as far as I can tell plain old ASCII should produce > the same effect though) > * search for part of a value in such a field with highlighting enabled, the > additional parameters I use are hl.fragsize=70, hl.requireFieldMatch=true, > hl.mergeContiguous=true (changing the parameters does not seem to have any > effect on the result though) > * highlighted snippets should show effects described above -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-553) Highlighter does not match phrase queries correctly
[ https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596914#action_12596914 ] Mike Klaas commented on SOLR-553: - What do people think of making span highlighting the default behaviour if the query contains phrases? It might be better to have the default behaviour that which people expect, even if it is technically different output from 1.2. > Highlighter does not match phrase queries correctly > --- > > Key: SOLR-553 > URL: https://issues.apache.org/jira/browse/SOLR-553 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: all >Reporter: Brian Whitman > Attachments: highlighttest.xml, Solr-553.patch > > > http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html > Say we search for the band "I Love You But I've Chosen Darkness" > .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E > The highlight returns a snippet that does have the name altogether: > Lights (Live) : I Love You But > I've Chosen Darkness : > But also returns unrelated snips from the same page: > Black Francis Shop "I Think I Love > You" > A correct highlighter should not return snippets that do not match the phrase > exactly. > LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem > from the Lucene end. Solr should get it too. > Related: SOLR-575 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-559) use Lucene updateDocument, deleteDocuments
[ https://issues.apache.org/jira/browse/SOLR-559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595714#action_12595714 ] Mike Klaas commented on SOLR-559: - This patch should probably remove all references to "maxPendingDeletes", including in the example solrconfig.xml. > use Lucene updateDocument, deleteDocuments > -- > > Key: SOLR-559 > URL: https://issues.apache.org/jira/browse/SOLR-559 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley >Priority: Minor > Attachments: SOLR-559.patch > > > Use Lucene updateDocument and deleteDocuments calls for the update handler -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-553) Highlighter does not match phrase queries correctly
[ https://issues.apache.org/jira/browse/SOLR-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-553: Issue Type: New Feature (was: Bug) Changed to feature request, since the current behaviour is expected. I'd be happy to review a patch to use SpanScorer in Solr, though. > Highlighter does not match phrase queries correctly > --- > > Key: SOLR-553 > URL: https://issues.apache.org/jira/browse/SOLR-553 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: all >Reporter: Brian Whitman > > http://www.nabble.com/highlighting-pt2%3A-returning-tokens-out-of-order-from-PhraseQuery-to16156718.html > Say we search for the band "I Love You But I've Chosen Darkness" > .../selectrows=100&q=%22I%20Love%20You%20But%20I\'ve%20Chosen%20Darkness%22&fq=type:html&hl=true&hl.fl=content&hl.fragsize=500&hl.snippets=5&hl.simple.pre=%3Cspan%3E&hl.simple.post=%3C/span%3E > The highlight returns a snippet that does have the name altogether: > Lights (Live) : I Love You But > I've Chosen Darkness : > But also returns unrelated snips from the same page: > Black Francis Shop "I Think I Love > You" > A correct highlighter should only return > Lights (Live) : I Love You But I've Chosen Darkness > And no snippets that do not match the phrase exactly. > LUCENE-794 (not yet committed, but seems to be ready) fixes up the problem > from the Lucene end. Solr should get it too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-516) Add hl.alternateFieldLen parameter, to set max length for hl.alternateField
[ https://issues.apache.org/jira/browse/SOLR-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas reassigned SOLR-516: --- Assignee: Mike Klaas > Add hl.alternateFieldLen parameter, to set max length for hl.alternateField > --- > > Key: SOLR-516 > URL: https://issues.apache.org/jira/browse/SOLR-516 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Koji Sekiguchi >Assignee: Mike Klaas >Priority: Trivial > Attachments: SOLR-516-solr-ruby.patch, SOLR-516.patch, SOLR-516.patch > > > USE CASE: > You have a document that is composed of (short) title and (long) body fields > and want body to be highlighted. > In order to avoid highlighted body field to be empty, you can use > hl.alternateField parameter. > Although you want to set f.body.hl.alternateField=body, you may set > f.body.hl.alternateField=title, > because response time is awful when the body values are big. But the title > field provides users with > information smaller than body field. > In this case, you can use f.body.hl.alternateFieldLen=100 to limit the body > length to 100 characters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-516) Add hl.alternateFieldLen parameter, to set max length for hl.alternateField
[ https://issues.apache.org/jira/browse/SOLR-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas resolved SOLR-516. - Resolution: Fixed > Add hl.alternateFieldLen parameter, to set max length for hl.alternateField > --- > > Key: SOLR-516 > URL: https://issues.apache.org/jira/browse/SOLR-516 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Koji Sekiguchi >Assignee: Mike Klaas >Priority: Trivial > Attachments: SOLR-516-solr-ruby.patch, SOLR-516.patch, SOLR-516.patch > > > USE CASE: > You have a document that is composed of (short) title and (long) body fields > and want body to be highlighted. > In order to avoid highlighted body field to be empty, you can use > hl.alternateField parameter. > Although you want to set f.body.hl.alternateField=body, you may set > f.body.hl.alternateField=title, > because response time is awful when the body values are big. But the title > field provides users with > information smaller than body field. > In this case, you can use f.body.hl.alternateFieldLen=100 to limit the body > length to 100 characters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-516) Add hl.alternateFieldLen parameter, to set max length for hl.alternateField
[ https://issues.apache.org/jira/browse/SOLR-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12587754#action_12587754 ] Mike Klaas commented on SOLR-516: - A quite reasonable addition, thanks!. I commited the core patch but named the parameter hl.maxAlternateFieldLength. Since it is so long anyway, it doesn't hurt to be explicit. I have zero familiarity with the ruby side of Solr, so I will leave the issue open for the ruby client patch to be reviewed and applied. > Add hl.alternateFieldLen parameter, to set max length for hl.alternateField > --- > > Key: SOLR-516 > URL: https://issues.apache.org/jira/browse/SOLR-516 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Koji Sekiguchi >Priority: Trivial > Attachments: SOLR-516-solr-ruby.patch, SOLR-516.patch, SOLR-516.patch > > > USE CASE: > You have a document that is composed of (short) title and (long) body fields > and want body to be highlighted. > In order to avoid highlighted body field to be empty, you can use > hl.alternateField parameter. > Although you want to set f.body.hl.alternateField=body, you may set > f.body.hl.alternateField=title, > because response time is awful when the body values are big. But the title > field provides users with > information smaller than body field. > In this case, you can use f.body.hl.alternateFieldLen=100 to limit the body > length to 100 characters. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-527) An XML commit only request handler
[ https://issues.apache.org/jira/browse/SOLR-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585243#action_12585243 ] Mike Klaas commented on SOLR-527: - Is this a generally-useful feature? I'm not sure how often this use case would occur. > An XML commit only request handler > -- > > Key: SOLR-527 > URL: https://issues.apache.org/jira/browse/SOLR-527 > Project: Solr > Issue Type: New Feature > Components: update >Affects Versions: 1.3 >Reporter: Sean Timm >Priority: Trivial > Attachments: ReadOnlyUpdateProcessorFactory.java, > ReadOnlyUpdateProcessorFactory.java, SOLR-527.patch > > > This request handler only permits messages. It is provided as one > way to prevent adds and deletes on a Solr slave machine that could > potentially be accessed by outside parties where a firewall or other access > control is either not possible or not desired. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-386) Configurable SolrHighlighter implementation
[ https://issues.apache.org/jira/browse/SOLR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas resolved SOLR-386. - Resolution: Fixed Commited in r639490. Thanks Tricia! > Configurable SolrHighlighter implementation > --- > > Key: SOLR-386 > URL: https://issues.apache.org/jira/browse/SOLR-386 > Project: Solr > Issue Type: Improvement > Components: highlighter >Affects Versions: 1.3 >Reporter: Eli Levine >Assignee: Mike Klaas > Attachments: SOLR-386-SolrHighlighter.patch, > SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch, > SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch > > > It would be great if SolrCore allowed the highlighter class to be > configurable. A good way would be to add a +class+ attribute to the > element in solrconfig.xml, similar to how the RequestHandler > instance is initialized in SorCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-386) Configurable SolrHighlighter implementation
[ https://issues.apache.org/jira/browse/SOLR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-386: Summary: Configurable SolrHighlighter implementation (was: Add confuguration to specify SolrHighlighter implementation) > Configurable SolrHighlighter implementation > --- > > Key: SOLR-386 > URL: https://issues.apache.org/jira/browse/SOLR-386 > Project: Solr > Issue Type: Improvement > Components: highlighter >Affects Versions: 1.3 >Reporter: Eli Levine >Assignee: Mike Klaas > Attachments: SOLR-386-SolrHighlighter.patch, > SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch, > SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch > > > It would be great if SolrCore allowed the highlighter class to be > configurable. A good way would be to add a +class+ attribute to the > element in solrconfig.xml, similar to how the RequestHandler > instance is initialized in SorCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-488) Solr does not generate highlights when uniqueId field is not defined in the schema
[
https://issues.apache.org/jira/browse/SOLR-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas resolved SOLR-488.
-
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Mike Klaas
The principal issue is fixed in 1.3.
Thanks Tomer.
> Solr does not generate highlights when uniqueId field is not defined in the
> schema
> --
>
> Key: SOLR-488
> URL: https://issues.apache.org/jira/browse/SOLR-488
> Project: Solr
> Issue Type: Improvement
> Components: highlighter
>Affects Versions: 1.2
> Environment: Windows Vista Business (x86, x64), latest Ubuntu server,
> Apache Tomcat 6.0.14
>Reporter: Tomer Gabel
>Assignee: Mike Klaas
> Fix For: 1.3
>
> Attachments: linkfield.HighlightingUtils.patch
>
>
> Solr does not generate highlights when there is no uniqueId field defined in
> the schema. I believe the reason for this is that it's very difficult to
> modify or extend the XmlWriter behavior, which is why highlights reside in
> their own "section" in the response XML and subsequently need to be "linked"
> to their respective documents via the uniqueId field.
> Our schema does not define a uniqueId for various reasons but we still need
> highlights; the solution we came up with was to provide a user-definable
> "link field," which is the document field whose value resides in the {{ name="215">}} elements in the generated output. I will presently attach a
> patch which adds a "hl.link" query parameter, which takes a field name and
> uses that as the "link field." If the parameter is not specified the original
> behavior is used, so backwards compatibility is maintained.
> As an aside, we've found this technique to be useful because our custom
> handlers add a lot of information to each document, and the way the response
> writer is implemented makes it nigh impossible to add information to any
> specific document within the response. I should probably open an issue which
> calls to reimplement this aspect of 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-386) Add confuguration to specify SolrHighlighter implementation
[ https://issues.apache.org/jira/browse/SOLR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577163#action_12577163 ] Mike Klaas commented on SOLR-386: - Tricia: thanks for the changes. I think that your decisions make sense--I'll be sure to followup by the end of the week. > Add confuguration to specify SolrHighlighter implementation > --- > > Key: SOLR-386 > URL: https://issues.apache.org/jira/browse/SOLR-386 > Project: Solr > Issue Type: Improvement > Components: highlighter >Affects Versions: 1.3 >Reporter: Eli Levine >Assignee: Mike Klaas > Attachments: SOLR-386-SolrHighlighter.patch, > SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch, > SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch > > > It would be great if SolrCore allowed the highlighter class to be > configurable. A good way would be to add a +class+ attribute to the > element in solrconfig.xml, similar to how the RequestHandler > instance is initialized in SorCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-386) Add confuguration to specify SolrHighlighter implementation
[ https://issues.apache.org/jira/browse/SOLR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574337#action_12574337 ] Mike Klaas commented on SOLR-386: - Hi Tricia, I'm not sure that I would ever use SolrHighlighter overriding (if I had the need, I probably would just make a separate search component). However, several people want this functionality and it has relatively low implementation/maintenance cost. There are a few things that need to be done to get the patch committed. First, the unnecessary whitespace changes in SolrCore shouldn't be in the diff (it makes it really hard to see the changes, and might make it hard to apply/revert). Also, I'm skeptical of using interfaces for this type of thing, for maintenance reasons. Perhaps we could move to one of the approaches that Grant suggested? Thanks again for the contribution, and sorry it took so long > Add confuguration to specify SolrHighlighter implementation > --- > > Key: SOLR-386 > URL: https://issues.apache.org/jira/browse/SOLR-386 > Project: Solr > Issue Type: Improvement > Components: highlighter >Affects Versions: 1.3 >Reporter: Eli Levine >Assignee: Mike Klaas > Attachments: SOLR-386-SolrHighlighter.patch, > SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch, > SOLR-386-SolrHighlighter.patch > > > It would be great if SolrCore allowed the highlighter class to be > configurable. A good way would be to add a +class+ attribute to the > element in solrconfig.xml, similar to how the RequestHandler > instance is initialized in SorCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-488) Solr does not generate highlights when uniqueId field is not defined in the schema
[
https://issues.apache.org/jira/browse/SOLR-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573080#action_12573080
]
Mike Klaas commented on SOLR-488:
-
Perhaps I should have been more clear: it is very unlikely that there will be a
bugfix release for 1.2, so the best that can be done is to look at the closed
issues in JIRA for the highlighter to find the change that fixed the bug in the
current version.
As for uniqueKey, it is about more than finding duplicates at document
insertion time. It is also a unique identifier for each document used for
federated search, highlighting, and other places (exactly what you are looking
for). If you want to turn off Solr's duplicate detection, just add
allowDups="true" to the you send to solr.
> Solr does not generate highlights when uniqueId field is not defined in the
> schema
> --
>
> Key: SOLR-488
> URL: https://issues.apache.org/jira/browse/SOLR-488
> Project: Solr
> Issue Type: Improvement
> Components: highlighter
>Affects Versions: 1.2
> Environment: Windows Vista Business (x86, x64), latest Ubuntu server,
> Apache Tomcat 6.0.14
>Reporter: Tomer Gabel
> Attachments: linkfield.HighlightingUtils.patch
>
>
> Solr does not generate highlights when there is no uniqueId field defined in
> the schema. I believe the reason for this is that it's very difficult to
> modify or extend the XmlWriter behavior, which is why highlights reside in
> their own "section" in the response XML and subsequently need to be "linked"
> to their respective documents via the uniqueId field.
> Our schema does not define a uniqueId for various reasons but we still need
> highlights; the solution we came up with was to provide a user-definable
> "link field," which is the document field whose value resides in the {{ name="215">}} elements in the generated output. I will presently attach a
> patch which adds a "hl.link" query parameter, which takes a field name and
> uses that as the "link field." If the parameter is not specified the original
> behavior is used, so backwards compatibility is maintained.
> As an aside, we've found this technique to be useful because our custom
> handlers add a lot of information to each document, and the way the response
> writer is implemented makes it nigh impossible to add information to any
> specific document within the response. I should probably open an issue which
> calls to reimplement this aspect of 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-488) Solr does not generate highlights when uniqueId field is not defined in the schema
[
https://issues.apache.org/jira/browse/SOLR-488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572312#action_12572312
]
Mike Klaas commented on SOLR-488:
-
Thanks for the patch!
Tomer, I just tested this scenario under trunk (1.3dev), and Solr _does_
highlight documents if no uniqueKey is specified. It is true that the
highlight data is not labeled, but it is guaranteed to appear in the same order
as the documents in the section, so they are identifiable.
Why do you propose a query-time "link" field? Do you need to be able to vary
the field from request to request?
Also, it would be helpful to know why uniqueKey is not sufficient for this
purpose.
> Solr does not generate highlights when uniqueId field is not defined in the
> schema
> --
>
> Key: SOLR-488
> URL: https://issues.apache.org/jira/browse/SOLR-488
> Project: Solr
> Issue Type: Improvement
> Components: highlighter
>Affects Versions: 1.2
> Environment: Windows Vista Business (x86, x64), latest Ubuntu server,
> Apache Tomcat 6.0.14
>Reporter: Tomer Gabel
> Attachments: linkfield.HighlightingUtils.patch
>
>
> Solr does not generate highlights when there is no uniqueId field defined in
> the schema. I believe the reason for this is that it's very difficult to
> modify or extend the XmlWriter behavior, which is why highlights reside in
> their own "section" in the response XML and subsequently need to be "linked"
> to their respective documents via the uniqueId field.
> Our schema does not define a uniqueId for various reasons but we still need
> highlights; the solution we came up with was to provide a user-definable
> "link field," which is the document field whose value resides in the {{ name="215">}} elements in the generated output. I will presently attach a
> patch which adds a "hl.link" query parameter, which takes a field name and
> uses that as the "link field." If the parameter is not specified the original
> behavior is used, so backwards compatibility is maintained.
> As an aside, we've found this technique to be useful because our custom
> handlers add a lot of information to each document, and the way the response
> writer is implemented makes it nigh impossible to add information to any
> specific document within the response. I should probably open an issue which
> calls to reimplement this aspect of Solr.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-487) Add configuration option for maxDocBytesToAnalyze to solr-config.xml
[ https://issues.apache.org/jira/browse/SOLR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas resolved SOLR-487. - Resolution: Fixed Thanks for the patch, but this functionality is already in trunk (1.3). http://wiki.apache.org/solr/HighlightingParameters has a list of what's new in the next version (a lot has changed since 1.2 in the Highlighter world) > Add configuration option for maxDocBytesToAnalyze to solr-config.xml > > > Key: SOLR-487 > URL: https://issues.apache.org/jira/browse/SOLR-487 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: Not that it matters, but: Windows Vista Business (x86, > x64), latest Ubuntu server, Tomcat 6.0.14 >Reporter: Tomer Gabel >Priority: Trivial > Attachments: maxdocsize.HighlightingUtils.patch, > maxdocsize.SolrConfig.patch > > > My team has hit the maxDocBytesToAnalyze limitation a while back and decided > to add a quick configuration parameter to solr-config.xml. I'll attach a > patch momentarily (based on Solr 1.2.0 source code) that includes the > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-487) Add configuration option for maxDocBytesToAnalyze to solr-config.xml
[ https://issues.apache.org/jira/browse/SOLR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas closed SOLR-487. --- > Add configuration option for maxDocBytesToAnalyze to solr-config.xml > > > Key: SOLR-487 > URL: https://issues.apache.org/jira/browse/SOLR-487 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: Not that it matters, but: Windows Vista Business (x86, > x64), latest Ubuntu server, Tomcat 6.0.14 >Reporter: Tomer Gabel >Assignee: Mike Klaas >Priority: Trivial > Attachments: maxdocsize.HighlightingUtils.patch, > maxdocsize.SolrConfig.patch > > > My team has hit the maxDocBytesToAnalyze limitation a while back and decided > to add a quick configuration parameter to solr-config.xml. I'll attach a > patch momentarily (based on Solr 1.2.0 source code) that includes the > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-487) Add configuration option for maxDocBytesToAnalyze to solr-config.xml
[ https://issues.apache.org/jira/browse/SOLR-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-487: Assignee: Mike Klaas > Add configuration option for maxDocBytesToAnalyze to solr-config.xml > > > Key: SOLR-487 > URL: https://issues.apache.org/jira/browse/SOLR-487 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 1.2 > Environment: Not that it matters, but: Windows Vista Business (x86, > x64), latest Ubuntu server, Tomcat 6.0.14 >Reporter: Tomer Gabel >Assignee: Mike Klaas >Priority: Trivial > Attachments: maxdocsize.HighlightingUtils.patch, > maxdocsize.SolrConfig.patch > > > My team has hit the maxDocBytesToAnalyze limitation a while back and decided > to add a quick configuration parameter to solr-config.xml. I'll attach a > patch momentarily (based on Solr 1.2.0 source code) that includes the > implementation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-474) audit docs for Spellchecker
[
https://issues.apache.org/jira/browse/SOLR-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-474:
Assignee: Mike Klaas
Summary: audit docs for Spellchecker (was: audit docs for Highlighter)
> audit docs for Spellchecker
> ---
>
> Key: SOLR-474
> URL: https://issues.apache.org/jira/browse/SOLR-474
> Project: Solr
> Issue Type: Task
>Affects Versions: 1.3
>Reporter: Hoss Man
>Assignee: Mike Klaas
> Fix For: 1.3
>
>
> according to this troubling comment from Mike, the highlighter javadocs (and
> wiki) may not reflect reality...
> http://www.nabble.com/spellcheckhandler-to14627712.html#a14627712
> {quote}
> Multi-word spell checking is available only with extendedResults=true, and
> only in trunk. I
> believe that the current javadocs are incorrect on this point.
> {quote}
> we should audit/fix this before 1.3
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-84: --- Fix Version/s: 1.3 > New Solr logo? > -- > > Key: SOLR-84 > URL: https://issues.apache.org/jira/browse/SOLR-84 > Project: Solr > Issue Type: Improvement >Reporter: Bertrand Delacretaz >Priority: Minor > Fix For: 1.3 > > Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, > logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-f.jpg, > solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, > solr-nick.gif, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, > sslogo-solr2-flare.jpg, sslogo-solr2.jpg, sslogo-solr3.jpg > > > Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) > sarraux-dessous.ch) has reworked his logo proposal to be more "solar". > This can either be the start of a logo contest, or if people like it we could > adopt it. The gradients can make it a bit hard to integrate, not sure if this > is really a problem. > WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-386) Add confuguration to specify SolrHighlighter implementation
[ https://issues.apache.org/jira/browse/SOLR-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas reassigned SOLR-386: --- Assignee: Mike Klaas > Add confuguration to specify SolrHighlighter implementation > --- > > Key: SOLR-386 > URL: https://issues.apache.org/jira/browse/SOLR-386 > Project: Solr > Issue Type: Improvement > Components: highlighter >Affects Versions: 1.3 >Reporter: Eli Levine >Assignee: Mike Klaas > Attachments: SOLR-386-SolrHighlighter.patch, > SOLR-386-SolrHighlighter.patch, SOLR-386-SolrHighlighter.patch > > > It would be great if SolrCore allowed the highlighter class to be > configurable. A good way would be to add a +class+ attribute to the > element in solrconfig.xml, similar to how the RequestHandler > instance is initialized in SorCore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-406) Allow SolrHighlighter to get parameters from code instead of request
[ https://issues.apache.org/jira/browse/SOLR-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas resolved SOLR-406. - Resolution: Won't Fix Assignee: Mike Klaas Won't fix: an acceptable solution exists in the linked thread. > Allow SolrHighlighter to get parameters from code instead of request > > > Key: SOLR-406 > URL: https://issues.apache.org/jira/browse/SOLR-406 > Project: Solr > Issue Type: Improvement > Components: highlighter >Reporter: Doug Daniels >Assignee: Mike Klaas >Priority: Minor > Attachments: SOLR-406-SolrHighlighter-params.patch > > > I'd like to specify whether to highlight, which fields to highlight, etc in > the code rather than through the request parameters. I can't find a way to > do that right now, as the doHighlighting method pulls SolrParams directly > from the request, and SolrParams don't seem to support modification. > For discussion, see > http://www.nabble.com/forum/ViewPost.jtp?post=13612249&framed=y -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-407) Uncached filter query parameters
[ https://issues.apache.org/jira/browse/SOLR-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-407: Fix Version/s: (was: 1.3) > Uncached filter query parameters > > > Key: SOLR-407 > URL: https://issues.apache.org/jira/browse/SOLR-407 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Minor > Attachments: fq.nocache.patch > > > Add a fq.nocache parameter (that may be specified multiple times) that adds > filter clauses to the query which are not cached. Further, these filters are > embedded directly into the BooleanQuery, which should be more efficient when > filters are not reused. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-457) A multi threaded implementation for solrJ
[ https://issues.apache.org/jira/browse/SOLR-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-457: Fix Version/s: (was: 1.3) > A multi threaded implementation for solrJ > - > > Key: SOLR-457 > URL: https://issues.apache.org/jira/browse/SOLR-457 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.3 >Reporter: patrick o'leary >Priority: Minor > Attachments: multithreaded-solrj.patch > > > Provide a multi threaded implementation of CommonsHttpSolrServer > For usage with distributed searching in solr-303 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-383) Add support for globalization/culture management
[ https://issues.apache.org/jira/browse/SOLR-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561107#action_12561107 ] Mike Klaas commented on SOLR-383: - Jeff, can this issue be closed? > Add support for globalization/culture management > > > Key: SOLR-383 > URL: https://issues.apache.org/jira/browse/SOLR-383 > Project: Solr > Issue Type: Improvement > Components: clients - C# >Affects Versions: 1.3 >Reporter: Jeff Rodenburg >Assignee: Jeff Rodenburg >Priority: Minor > Fix For: 1.3 > > > SolrSharp should supply configuration and/or programmatic control over > windows culture settings. This is important for working with data being > saved to indexes that carry certain formatting expectations for various types > of fields, both in SolrSharp as well as the solr field counterparts on the > server side. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-293) Add "minPartLength" to WordDelimiterFilter
[ https://issues.apache.org/jira/browse/SOLR-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-293: Fix Version/s: (was: 1.3) > Add "minPartLength" to WordDelimiterFilter > -- > > Key: SOLR-293 > URL: https://issues.apache.org/jira/browse/SOLR-293 > Project: Solr > Issue Type: New Feature > Components: update >Affects Versions: 1.3 >Reporter: Mike Klaas >Assignee: Mike Klaas >Priority: Minor > > WDF is handy but over-tokenizes when faced with short word parts: > A9 > R2D2 > mp3 > This creates one- or two- character tokens which are extremely slow to query > as the doc freq is so high (this is contributing to a significant portion of > our slowest queries). > This patch adds a "minPartLength" option that disables generation of parts > below a certain length. It is recommended to use it with catenateAll, so as > to not lose tokens. > I'll add factory options and tests if we decide to include this (and are > happy with the parameter name). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-267) log handler + query + hits
[ https://issues.apache.org/jira/browse/SOLR-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-267: Fix Version/s: (was: 1.3) > log handler + query + hits > -- > > Key: SOLR-267 > URL: https://issues.apache.org/jira/browse/SOLR-267 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Will Johnson >Priority: Minor > Attachments: LogQueryHitCounts.patch, LogQueryHitCounts.patch, > LogQueryHitCounts.patch, LogQueryHitCounts.patch, LogQueryHitCounts.patch, > LogQueryHitCounts.patch, LogQueryHitCounts.patch > > > adds a logger to log handler, query string and hit counts for each query -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-430) SpellcheckerRequest / Response
[ https://issues.apache.org/jira/browse/SOLR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Klaas updated SOLR-430: Fix Version/s: (was: 1.3) > SpellcheckerRequest / Response > -- > > Key: SOLR-430 > URL: https://issues.apache.org/jira/browse/SOLR-430 > Project: Solr > Issue Type: New Feature > Components: clients - java, spellchecker >Affects Versions: 1.3 >Reporter: Matthew Runo > > SolrJ should support at a minimum a basic SpellcheckRequest and Response. > Response should return a set of strings, the suggestions returned by the > SpellcheckQueryHandler. > Request should accept the basic commands that SC accepts over HTTP. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-243) Create a hook to allow custom code to create custom IndexReaders
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Klaas updated SOLR-243:
Fix Version/s: (was: 1.3)
> Create a hook to allow custom code to create custom IndexReaders
>
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
> Environment: Solr core
>Reporter: John Wang
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
