[jira] Created: (SOLR-621) Add a getAll method to NamedList
Add a getAll method to NamedList Key: SOLR-621 URL: https://issues.apache.org/jira/browse/SOLR-621 Project: Solr Issue Type: Improvement Reporter: Noble Paul Priority: Trivial It would be convenient to have a List getAll(String name); method in NamedList -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-614) lesser noise in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-614: Fix Version/s: 1.3 It would be better to do it before 1.3 because this impacts the way users write their solrconfig files. Once 1.3 is released it is hard to change the configuration > lesser noise in solrconfig.xml > -- > > Key: SOLR-614 > URL: https://issues.apache.org/jira/browse/SOLR-614 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.3 > > Attachments: SOLR-614.patch > > > All the components initialized by Solr have an init(NamedList args) > initializer. This leads us to writing the configuration needed for the > component in the NamedList xml format. People familiar with Solr may know the > format but most of what is written is noise than information. For users who > are not familiar w/ the format find it too difficult to understand why they > have to write it this way. Moreover , it is not a very efficient way to > configure . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-620) Velocity Response Writer
[ https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611424#action_12611424 ] Erik Hatcher commented on SOLR-620: --- There are a zillion bells and whistles that can be added to this, lots of Velocity parameters that can be controlled. We'll probably want to have some custom Solr macros to make templating life a lot easier. For example, we'll need to make navigating the DocList easier. > Velocity Response Writer > > > Key: SOLR-620 > URL: https://issues.apache.org/jira/browse/SOLR-620 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Attachments: SOLR-620.jars.zip, SOLR-620.patch > > > Add a Velocity - http://velocity.apache.org - response writer, making it > possible to generate a decent search UI straight from Solr itself. Designed > to work standalone or in conjunction with the JSON response writer (or > SolrJS) for Ajaxy things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-620) Velocity Response Writer
[ https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-620: -- Attachment: SOLR-620.jars.zip The JARs used to build this example (probably not the most current versions, but what I happened to have laying around). > Velocity Response Writer > > > Key: SOLR-620 > URL: https://issues.apache.org/jira/browse/SOLR-620 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Attachments: SOLR-620.jars.zip, SOLR-620.patch > > > Add a Velocity - http://velocity.apache.org - response writer, making it > possible to generate a decent search UI straight from Solr itself. Designed > to work standalone or in conjunction with the JSON response writer (or > SolrJS) for Ajaxy things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-620) Velocity Response Writer
[ https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-620: -- Attachment: SOLR-620.patch First draft - very basic operation. Must also add Velocity, Commons Lang, and Commons Collections to the classpath. Example: http://localhost:8983/solr/select?q=ipod&wt=velocity With an optional template parameter, specifying the template name under conf/velocity (&template=default) > Velocity Response Writer > > > Key: SOLR-620 > URL: https://issues.apache.org/jira/browse/SOLR-620 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Erik Hatcher >Assignee: Erik Hatcher >Priority: Minor > Attachments: SOLR-620.patch > > > Add a Velocity - http://velocity.apache.org - response writer, making it > possible to generate a decent search UI straight from Solr itself. Designed > to work standalone or in conjunction with the JSON response writer (or > SolrJS) for Ajaxy things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-620) Velocity Response Writer
Velocity Response Writer Key: SOLR-620 URL: https://issues.apache.org/jira/browse/SOLR-620 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Add a Velocity - http://velocity.apache.org - response writer, making it possible to generate a decent search UI straight from Solr itself. Designed to work standalone or in conjunction with the JSON response writer (or SolrJS) for Ajaxy things. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Whitman updated SOLR-303: --- Attachment: shards.start_rows.patch Attaching patch to add a &shards.start and &shards.rows optional parameter. If set, they override distributed search's intelligence on setting start and rows per shard. If you set &shards.start=10 and &shards.rows=10, each shard will be queried with &start=10 and &rows=10 and you'll get back N*10 results (set &rows on the main query to get it all.) [Not a java developer, my patch works but may violate good taste/style] > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards.start_rows.patch, shards_qt.patch, > solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- 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-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611376#action_12611376 ] Brian Whitman commented on SOLR-303: Understood. Can I suggest a third alternative? two new params: named &d.rows and &d.start with the implication that these get sent unchanged to each of the shards. You may get back up to N*d.rows, where N is the # of shards. That leaves the paging management up to the client. Our use case is millions of documents across many shards, and we often do queries that are "get all document of type X." There may be 5m type X documents. Doing a &rows=500 is unpredictable so we've previously done a loop of incrementing start by a 1000 and getting 1000 rows each time. But with this distributed setup, each successive batch query takes slightly longer, and by the time we've gotten to the 5,001,000 batch queries are timing out and breaking anyway. > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611372#action_12611372
]
Yonik Seeley commented on SOLR-303:
---
{quote}
http://localhost:8983/solr/select?shards=[4 shards]&q=*:*&start=5000&rows=1000
Seems to request &rows=6000 from all the shards?
{quote}
It's a feature.
To retrieve documents 5000-6000, one must find the first 6000 documents then
take the last 1000.
Since it's possible that all top 6000 documents could come from a single shard,
the top 6000 documents must be collected from each and merged.
There are alternatives:
1) Optimistically request less than 6000 documents per shard and re-query if we
are wrong
2) Add an optional mode that treats documents across shards in the same
position as equal, so if you had 10 shards, you would simply get the top 100
docs starting at 500. This might be OK for some applications.
In general, search engines are optimized at retrieving the top 10 of something,
and bad at retrieving the top 10 starting at a big number. Limit the depth
people can page, or restructure queries to avoid the latter case.
> Distributed Search over HTTP
>
>
> Key: SOLR-303
> URL: https://issues.apache.org/jira/browse/SOLR-303
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Sharad Agarwal
>Assignee: Yonik Seeley
> Fix For: 1.3
>
> Attachments: distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed_add_tests_for_intended_behavior.patch,
> distributed_facet_count_bugfix.patch, distributed_pjaol.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch,
> fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch
>
>
> Searching over multiple shards and aggregating results.
> Motivated by http://wiki.apache.org/solr/DistributedSearch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-303) Distributed Search over HTTP
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12607106#action_12607106
]
bwhitman edited comment on SOLR-303 at 7/7/08 2:57 PM:
Putting &debugQuery on a query with shards that returns 0 results will NPE:
(removing NPE code block so it stops wrapping the page)
was (Author: bwhitman):
Putting &debugQuery on a query with shards that returns 0 results will NPE:
{code}
INFO: webapp=/solr path=/select
params={shards=localhost:8983/solr,localhost:8984/solr,localhost:8985/solr,localhost:8986/solr&debugQuery=true&q=i_tag:894&rows=100}
status=500 QTime=8
Jun 22, 2008 12:45:38 PM org.apache.solr.common.SolrException log
SEVERE: java.lang.NullPointerException
at
org.apache.solr.handler.component.DebugComponent.finishStage(DebugComponent.java:133)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:257)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:125)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:965)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:272)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
{code}
> Distributed Search over HTTP
>
>
> Key: SOLR-303
> URL: https://issues.apache.org/jira/browse/SOLR-303
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Sharad Agarwal
>Assignee: Yonik Seeley
> Fix For: 1.3
>
> Attachments: distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed_add_tests_for_intended_behavior.patch,
> distributed_facet_count_bugfix.patch, distributed_pjaol.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch,
> fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch
>
>
> Searching over multiple shards and aggregating results.
> Motivated by http://wiki.apache.org/solr/DistributedSearch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611368#action_12611368
]
Brian Whitman commented on SOLR-303:
Anyone notice something like this:
http://localhost:8983/solr/select?shards={4 shards}&q=*:*&start=5000&rows=1000
Seems to request &rows=6000 from all the shards? (likewise,
start=1&rows=1000 sends rows=11000 to all the shards?)
The shards all say:
INFO: webapp=/solr path=/select
params={fl=id,score&start=0&q=*:*&isShard=true&wt=javabin&fsv=true&rows=6000&version=2.2}
hits=6000 status=0 QTime=175
And the host I called select on says:
INFO: webapp=/solr path=/search params={start=5000&q=*:*&rows=1000} status=0
QTime=1192
And the QTime goes up the higher &start goes. (QTime for start=5000 was 200,
QTime for start=5 was 4500, start=50 had 35000!)
Bug or feature?
> Distributed Search over HTTP
>
>
> Key: SOLR-303
> URL: https://issues.apache.org/jira/browse/SOLR-303
> Project: Solr
> Issue Type: New Feature
> Components: search
>Reporter: Sharad Agarwal
>Assignee: Yonik Seeley
> Fix For: 1.3
>
> Attachments: distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed.patch, distributed.patch, distributed.patch,
> distributed.patch, distributed_add_tests_for_intended_behavior.patch,
> distributed_facet_count_bugfix.patch, distributed_pjaol.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch,
> fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch,
> fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch
>
>
> Searching over multiple shards and aggregating results.
> Motivated by http://wiki.apache.org/solr/DistributedSearch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-605) Programatically register SolrEventListeners
[ https://issues.apache.org/jira/browse/SOLR-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611334#action_12611334 ] Ryan McKinley commented on SOLR-605: but yes, I agree -- these just need more clarification *when* you can modify them > Programatically register SolrEventListeners > --- > > Key: SOLR-605 > URL: https://issues.apache.org/jira/browse/SOLR-605 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-605-RegisterEventListeners.patch, SOLR-605.patch > > > Currently all eventListeners need to be registered via solrconfig.xml -- it > would be nice to programatically register classes for these events too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-605) Programatically register SolrEventListeners
[
https://issues.apache.org/jira/browse/SOLR-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611333#action_12611333
]
Ryan McKinley commented on SOLR-605:
check the [existing
javadocs|http://lucene.apache.org/solr/api/org/apache/solr/schema/IndexSchema.html#getFieldTypes()]
{panel}
Provides direct access to the Map containing all Field Types in the index,
keyed on fild type name.
Modifying this Map (or any item in it) will affect the real schema
{panel}
> Programatically register SolrEventListeners
> ---
>
> Key: SOLR-605
> URL: https://issues.apache.org/jira/browse/SOLR-605
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Trivial
> Fix For: 1.3
>
> Attachments: SOLR-605-RegisterEventListeners.patch, SOLR-605.patch
>
>
> Currently all eventListeners need to be registered via solrconfig.xml -- it
> would be nice to programatically register classes for these events too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-605) Programatically register SolrEventListeners
[ https://issues.apache.org/jira/browse/SOLR-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611328#action_12611328 ] Yonik Seeley commented on SOLR-605: --- bq. I'm afraid that can of worms has been open (at least) since solr 1.1 Nah... just the lack of javadoc that they shouldn't be modified. > Programatically register SolrEventListeners > --- > > Key: SOLR-605 > URL: https://issues.apache.org/jira/browse/SOLR-605 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-605-RegisterEventListeners.patch, SOLR-605.patch > > > Currently all eventListeners need to be registered via solrconfig.xml -- it > would be nice to programatically register classes for these events too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-605) Programatically register SolrEventListeners
[
https://issues.apache.org/jira/browse/SOLR-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611321#action_12611321
]
Ryan McKinley commented on SOLR-605:
bq. w/o opening up the can of worms of a mutable IndexSchema
I'm afraid that can of worms has been open (at least) since solr 1.1
{code:java}
public Map getFields() { return fields; }
public Map getFieldTypes() { return fieldTypes; }
{code}
> Programatically register SolrEventListeners
> ---
>
> Key: SOLR-605
> URL: https://issues.apache.org/jira/browse/SOLR-605
> Project: Solr
> Issue Type: New Feature
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
>Priority: Trivial
> Fix For: 1.3
>
> Attachments: SOLR-605-RegisterEventListeners.patch, SOLR-605.patch
>
>
> Currently all eventListeners need to be registered via solrconfig.xml -- it
> would be nice to programatically register classes for these events too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-605) Programatically register SolrEventListeners
[ https://issues.apache.org/jira/browse/SOLR-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611306#action_12611306 ] Yonik Seeley commented on SOLR-605: --- bq. 1. add javadoc comments saying "not threadsafe, intended for use in inform()" Since these are new methods, I think this is probably the right approach. It allows extensions to modify the schema w/o opening up the can of worms of a mutable IndexSchema. > Programatically register SolrEventListeners > --- > > Key: SOLR-605 > URL: https://issues.apache.org/jira/browse/SOLR-605 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-605-RegisterEventListeners.patch, SOLR-605.patch > > > Currently all eventListeners need to be registered via solrconfig.xml -- it > would be nice to programatically register classes for these events too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-605) Programatically register SolrEventListeners
[ https://issues.apache.org/jira/browse/SOLR-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611296#action_12611296 ] Ryan McKinley commented on SOLR-605: true -- likewise with SOLR-619 -- however all these calls will be safe within inform( SolrCore ) for SolrCoreAware classes. Options I see: 1. add javadoc comments saying "not threadsafe, intended for use in inform()" 2. change implementations from HashMap -> ConcurrentHashMap & List -> Collections.synchronized() 3. (bad) remove the functionality Is there any way for an arbitrary thread (say in a RequestHandler) to block indexing? If so, this could be offered as an option in addition to #1 for the rare event where you need to modify the listeners/schema after startup. > Programatically register SolrEventListeners > --- > > Key: SOLR-605 > URL: https://issues.apache.org/jira/browse/SOLR-605 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-605-RegisterEventListeners.patch, SOLR-605.patch > > > Currently all eventListeners need to be registered via solrconfig.xml -- it > would be nice to programatically register classes for these events too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-619) Register copyField at runtime
[ https://issues.apache.org/jira/browse/SOLR-619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611277#action_12611277 ] Yonik Seeley commented on SOLR-619: --- This patch has thread safety issues if the new API were to be used from more than one thread, or concurrently with searching. > Register copyField at runtime > - > > Key: SOLR-619 > URL: https://issues.apache.org/jira/browse/SOLR-619 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-619-RuntimeSchema.patch > > > In order to enable runtime schema manipulation, it would be nice to register > copy fields manually rather then requiring them to be registered via > schema.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-605) Programatically register SolrEventListeners
[ https://issues.apache.org/jira/browse/SOLR-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611272#action_12611272 ] Yonik Seeley commented on SOLR-605: --- I think there may be some thread safety issues here wrt commitCallbacks and optimizeCallbacks that could result in a concurrent modification exception if these new APIs are used concurrently with indexing. > Programatically register SolrEventListeners > --- > > Key: SOLR-605 > URL: https://issues.apache.org/jira/browse/SOLR-605 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-605-RegisterEventListeners.patch, SOLR-605.patch > > > Currently all eventListeners need to be registered via solrconfig.xml -- it > would be nice to programatically register classes for these events too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-619) Register copyField at runtime
[ https://issues.apache.org/jira/browse/SOLR-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-619: --- Attachment: SOLR-619-RuntimeSchema.patch This patch moves the copyField registration out of a for loop and into a public function. The downside to this approach is that the dynamicCopyField array is resized for each new dynamic copy field rather then building a List, then converting to an array. Since this is only at startup and is likely an unmesuarable change (unless you have LOTS of dynamic copy fields), this seems like an ok tradeoff. > Register copyField at runtime > - > > Key: SOLR-619 > URL: https://issues.apache.org/jira/browse/SOLR-619 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-619-RuntimeSchema.patch > > > In order to enable runtime schema manipulation, it would be nice to register > copy fields manually rather then requiring them to be registered via > schema.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-605) Programatically register SolrEventListeners
[ https://issues.apache.org/jira/browse/SOLR-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-605. Resolution: Fixed > Programatically register SolrEventListeners > --- > > Key: SOLR-605 > URL: https://issues.apache.org/jira/browse/SOLR-605 > Project: Solr > Issue Type: New Feature >Reporter: Ryan McKinley >Assignee: Ryan McKinley >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-605-RegisterEventListeners.patch, SOLR-605.patch > > > Currently all eventListeners need to be registered via solrconfig.xml -- it > would be nice to programatically register classes for these events too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-619) Register copyField at runtime
Register copyField at runtime - Key: SOLR-619 URL: https://issues.apache.org/jira/browse/SOLR-619 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Priority: Minor Fix For: 1.3 In order to enable runtime schema manipulation, it would be nice to register copy fields manually rather then requiring them to be registered via schema.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-618) Improve Distributed Search debugQuery support
[ https://issues.apache.org/jira/browse/SOLR-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611237#action_12611237 ] Yonik Seeley commented on SOLR-618: --- debugQuery is currently only used in the GET_FIELDS phase, which has various limitations: - doesn't happen on any shard without a document selected - if no documents are selected, then no shards will be queried resulting in empty debug info - doesn't count timing in the important CPU intensive query phase > Improve Distributed Search debugQuery support > - > > Key: SOLR-618 > URL: https://issues.apache.org/jira/browse/SOLR-618 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.3 >Reporter: Yonik Seeley >Priority: Minor > > Improve Distributed Search debugQuery support -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-618) Improve Distributed Search debugQuery support
Improve Distributed Search debugQuery support - Key: SOLR-618 URL: https://issues.apache.org/jira/browse/SOLR-618 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: Yonik Seeley Priority: Minor Improve Distributed Search debugQuery support -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-303) Distributed Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611230#action_12611230 ] Yonik Seeley commented on SOLR-303: --- Fixed "debugQuery on a query with shards that returns 0 results will NPE". There are still some issues with debugQuery=true, but it's not critical since it is just debugging. I'll open another issue for that. > Distributed Search over HTTP > > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed.patch, distributed.patch, distributed.patch, > distributed.patch, distributed_add_tests_for_intended_behavior.patch, > distributed_facet_count_bugfix.patch, distributed_pjaol.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.patch, fedsearch.patch, fedsearch.stu.patch, > fedsearch.stu.patch, shards_qt.patch, solr-dist-faceting-non-ascii-all.patch > > > Searching over multiple shards and aggregating results. > Motivated by http://wiki.apache.org/solr/DistributedSearch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
