[jira] Created: (SOLR-1754) Legacy numeric types do not check input for bad syntax
Legacy numeric types do not check input for bad syntax -- Key: SOLR-1754 URL: https://issues.apache.org/jira/browse/SOLR-1754 Project: Solr Issue Type: Bug Affects Versions: 1.4 Reporter: Lance Norskog Fix For: 1.5 The legacy numeric types do not check their input values for valid input. A text string is accepted as input for any of these types: IntField, LongField, FloatField, DoubleField. DateField checks its input. In general this is a no-fix, except: that IntField is a necessary memory type because it cuts memory use in sorting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1742) uniqueKey must be string type otherwise "missing core name in path" error is rendered
[ https://issues.apache.org/jira/browse/SOLR-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829451#action_12829451 ] Lance Norskog commented on SOLR-1742: - I just tried this and the old 'pint' type works as a unique key. The QueryElevationComponent complains and you have to turn it off, but that's all that happened. The type has to be set to 'pint' before you add the document. > uniqueKey must be string type otherwise "missing core name in path" error is > rendered > - > > Key: SOLR-1742 > URL: https://issues.apache.org/jira/browse/SOLR-1742 > Project: Solr > Issue Type: Bug > Components: Build > Environment: all >Reporter: Marcin > Fix For: 1.5 > > > How to replicate: > - create index with schema where you uniqueKet is integer > - set your unique key type to integer > - deploy your index > under http://host:8080/solr/admin/ - you will get "missing core name in path" > Workaround: > - change type of your uniqueKet to srting > - undeploy and deploy index > Its quite confusing as 1.5 is not properly reporting errors and you need to > be lucky to find that reason on your own. > cheers, > /Marcin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1670) synonymfilter/map repeat bug
[
https://issues.apache.org/jira/browse/SOLR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829399#action_12829399
]
Lance Norskog commented on SOLR-1670:
-
bq. Not at the semantic level (for overlapping tokens). For instance, it would
be incorrect for someone to rely on a specific ordering for overlapping tokens
- order has never been guaranteed by any TokenFilters that do produce
overlapping tokens, and in fact the ordering for some has changed in the past
as the implementation changed.
Is this part of the TokenFilter contract documented somewhere?
> synonymfilter/map repeat bug
>
>
> Key: SOLR-1670
> URL: https://issues.apache.org/jira/browse/SOLR-1670
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Robert Muir
>Assignee: Yonik Seeley
> Attachments: SOLR-1670.patch, SOLR-1670.patch, SOLR-1670_test.patch
>
>
> as part of converting tests for SOLR-1657, I ran into a problem with
> synonymfilter
> the test for 'repeats' has a flaw, it uses this assertTokEqual construct
> which does not really validate that two lists of token are equal, it just
> stops at the shorted one.
> {code}
> // repeats
> map.add(strings("a b"), tokens("ab"), orig, merge);
> map.add(strings("a b"), tokens("ab"), orig, merge);
> assertTokEqual(getTokList(map,"a b",false), tokens("ab"));
> /* in reality the result from getTokList is ab ab ab! */
> {code}
> when converted to assertTokenStreamContents this problem surfaced. attached
> is an additional assertion to the existing testcase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1750) SystemStatsRequestHandler - replacement for stats.jsp
[
https://issues.apache.org/jira/browse/SOLR-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829354#action_12829354
]
Simon Rosenthal commented on SOLR-1750:
---
+1 on SolrStatsRequestHandler
You might want to consider either omitting or making optional the Lucene
Fieldcache stats; they can often be *very* slow to be generated ( see
http://www.lucidimagination.com/search/document/5ba908577d2e4c25/stats_page_slow_in_latest_nightly#2f40166c25f9bfa0
). One use case for this request handler that I can see is high frequency
(every few seconds) monitoring as part of performance testing, for which a
fast response is pretty mandatory.
> SystemStatsRequestHandler - replacement for stats.jsp
> -
>
> Key: SOLR-1750
> URL: https://issues.apache.org/jira/browse/SOLR-1750
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SystemStatsRequestHandler.java
>
>
> stats.jsp is cool and all, but suffers from escaping issues, and also is not
> accessible from SolrJ or other standard Solr APIs.
> Here's a request handler that emits everything stats.jsp does.
> For now, it needs to be registered in solrconfig.xml like this:
> {code}
> class="solr.SystemStatsRequestHandler" />
> {code}
> But will register this in AdminHandlers automatically before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-1163) Solr Explorer - A generic GWT client for Solr
If you're looking for the new version, then no, I haven't created a
patch for it yet. The old one you can find in JIRA and applying it will
create the contrib folder for it.
Uri
Pradeep Pujari wrote:
I checked contrib directory. I did not find this patch. Do you have commited
this code?
Pradeep.
--- On Wed, 1/27/10, Uri Boness (JIRA) wrote:
From: Uri Boness (JIRA)
Subject: [jira] Commented: (SOLR-1163) Solr Explorer - A generic GWT client for
Solr
To: solr-dev@lucene.apache.org
Date: Wednesday, January 27, 2010, 10:22 AM
[
https://issues.apache.org/jira/browse/SOLR-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805601#action_12805601
]
Uri Boness commented on SOLR-1163:
--
Actually I've been working on a new version for the
explorer which I plan to put soon as a patch here.
Solr Explorer - A generic GWT client for Solr
-
Key: SOLR-1163
URL: https://issues.apache.org/jira/browse/SOLR-1163
Project: Solr
Issue Type: New
Feature
Components: web gui
Affects Versions: 1.3
Reporter: Uri
Boness
Attachments:
graphics.zip, solr-explorer.patch, solr-explorer.patch
The attached patch is a GWT generic client for solr.
It is currently standalone, meaning that once built, one can
open the generated HTML file in a browser and communicate
with any deployed solr. It is configured with it's own
configuration file, where one can configure the solr
instance/core to connect to. Since it's currently standalone
and completely client side based, it uses JSON with padding
(cross-side scripting) to connect to remote solr servers.
Some of the supported features:
- Simple query search
- Sorting - one can dynamically define new sort
criterias
- Search results are rendered very much like Google
search results are rendered. It is also possible to view all
stored field values for every hit.
- Custom hit rendering - It is possible to show
thumbnails (images) per hit and also customize a view for a
hit based on html templates
- Faceting - one can dynamically define field and
query facets via the UI. it is also possible to
pre-configure these facets in the configuration file.
- Highlighting - you can dynamically configure
highlighting. it can also be pre-configured in the
configuration file
- Spellchecking - you can dynamically configure spell
checking. Can also be done in the configuration file.
Supports collation. It is also possible to send "build" and
"reload" commands.
- Data import handler - if used, it is possible to
send a "full-import" and "status" command ("delta-import" is
not implemented yet, but it's easy to add)
- Console - For development time, there's a small
console which can help to better understand what's going on
behind the scenes. One can use it to:
** view the client logs
** browse the solr scheme
** View a break down of the current search context
** View a break down of the query URL that is sent to
solr
** View the raw JSON response returning from Solr
This client is actually a platform that can be greatly
extended for more things. The goal is to have a client where
the explorer part is just one view of it. Other future views
include: Monitoring, Administration, Query Builder,
DataImportHandler configuration, and more...
To get a better view of what's currently possible.
We've set up a public version of this client at:
http://search.jteam.nl/explorer. This client is
configured with one solr instance where crawled YouTube
movies where indexed. You can also check out a screencast
for this deployed client: http://search.jteam.nl/help
The patch created a new folder in the contrib.
directory. Since the patch doesn't contain binaries, an
additional zip file is provides that needs to be extract to
add all the required graphics. This module is maven2 based
and is configured in such a way that all GWT related
tools/libraries are automatically downloaded when the
modules is compiled. One of the artifacts of the build is a
war file which can be deployed in any servlet container.
NOTE: this client works best on WebKit based browsers
(for performance reason) but also works on firefox and ie
7+. That said, it should be taken into account that it is
still under development.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue
online.
Re: Solr Expert
possibly. - Original Message From: sean khan To: solr-dev@lucene.apache.org Sent: Wed, February 3, 2010 2:37:26 PM Subject: Solr Expert hi there, I am interested in leveraging your skills to settup and operate a solr instance, is this the right forum to post this request ? Is there anyone interested who knows Solr very well and can install, configure solr for our use case. sean
Solr Expert
hi there, I am interested in leveraging your skills to settup and operate a solr instance, is this the right forum to post this request ? Is there anyone interested who knows Solr very well and can install, configure solr for our use case. sean
DB Connection
I looked at some of the references to see if this has been explained or not, but I didn't see anything regarding it. I was wondering, quite simply, if the SQL Server connection from Solr during indexing is kept alive for all subsequent delta-import requests, or does it reopen the connection each time and close it after it's finished? Thanks kindly. -CJ Developer -- View this message in context: http://old.nabble.com/DB-Connection-tp27441937p27441937.html Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Commented: (SOLR-1301) Solr + Hadoop
[ https://issues.apache.org/jira/browse/SOLR-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829200#action_12829200 ] Jason Rutherglen commented on SOLR-1301: In production the latest patch does not leave temporary files behind... Though before we had failed tasks, so perhaps there's still a bug, we won't know until we run out of disk space again. > Solr + Hadoop > - > > Key: SOLR-1301 > URL: https://issues.apache.org/jira/browse/SOLR-1301 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Andrzej Bialecki > Fix For: 1.5 > > Attachments: commons-logging-1.0.4.jar, > commons-logging-api-1.0.4.jar, hadoop-0.19.1-core.jar, hadoop.patch, > log4j-1.2.15.jar, README.txt, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, SOLR-1301.patch, > SOLR-1301.patch, SolrRecordWriter.java > > > This patch contains a contrib module that provides distributed indexing > (using Hadoop) to Solr EmbeddedSolrServer. The idea behind this module is > twofold: > * provide an API that is familiar to Hadoop developers, i.e. that of > OutputFormat > * avoid unnecessary export and (de)serialization of data maintained on HDFS. > SolrOutputFormat consumes data produced by reduce tasks directly, without > storing it in intermediate files. Furthermore, by using an > EmbeddedSolrServer, the indexing task is split into as many parts as there > are reducers, and the data to be indexed is not sent over the network. > Design > -- > Key/value pairs produced by reduce tasks are passed to SolrOutputFormat, > which in turn uses SolrRecordWriter to write this data. SolrRecordWriter > instantiates an EmbeddedSolrServer, and it also instantiates an > implementation of SolrDocumentConverter, which is responsible for turning > Hadoop (key, value) into a SolrInputDocument. This data is then added to a > batch, which is periodically submitted to EmbeddedSolrServer. When reduce > task completes, and the OutputFormat is closed, SolrRecordWriter calls > commit() and optimize() on the EmbeddedSolrServer. > The API provides facilities to specify an arbitrary existing solr.home > directory, from which the conf/ and lib/ files will be taken. > This process results in the creation of as many partial Solr home directories > as there were reduce tasks. The output shards are placed in the output > directory on the default filesystem (e.g. HDFS). Such part-N directories > can be used to run N shard servers. Additionally, users can specify the > number of reduce tasks, in particular 1 reduce task, in which case the output > will consist of a single shard. > An example application is provided that processes large CSV files and uses > this API. It uses a custom CSV processing to avoid (de)serialization overhead. > This patch relies on hadoop-core-0.19.1.jar - I attached the jar to this > issue, you should put it in contrib/hadoop/lib. > Note: the development of this patch was sponsored by an anonymous contributor > and approved for release under Apache License. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1750) SystemStatsRequestHandler - replacement for stats.jsp
[
https://issues.apache.org/jira/browse/SOLR-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829199#action_12829199
]
Steven Rowe commented on SOLR-1750:
---
bq. "stats" is a bit overloaded (StatsComponent). as is "system"
(SystemInfoHandler).
I swear when I read this, before I suggested SIRH, you had written
"SystemStatsHandler" instead of "SystemInfoHandler". Not sure how you changed
it without a red "edited" annotation in the header for your comment Et tu,
Atlassian?
Anyway, pathological paranoia aside, SIRH is too close to SystemInfoHandler - I
hereby begin the process of formally withdrawing it from consideration. Ok,
done.
stats.xsl creates a title prefix "Solr Statistics" - how about
SolrStatsRequestHandler?
> SystemStatsRequestHandler - replacement for stats.jsp
> -
>
> Key: SOLR-1750
> URL: https://issues.apache.org/jira/browse/SOLR-1750
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SystemStatsRequestHandler.java
>
>
> stats.jsp is cool and all, but suffers from escaping issues, and also is not
> accessible from SolrJ or other standard Solr APIs.
> Here's a request handler that emits everything stats.jsp does.
> For now, it needs to be registered in solrconfig.xml like this:
> {code}
> class="solr.SystemStatsRequestHandler" />
> {code}
> But will register this in AdminHandlers automatically before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (SOLR-1163) Solr Explorer - A generic GWT client for Solr
I checked contrib directory. I did not find this patch. Do you have commited
this code?
Pradeep.
--- On Wed, 1/27/10, Uri Boness (JIRA) wrote:
> From: Uri Boness (JIRA)
> Subject: [jira] Commented: (SOLR-1163) Solr Explorer - A generic GWT client
> for Solr
> To: solr-dev@lucene.apache.org
> Date: Wednesday, January 27, 2010, 10:22 AM
>
> [
> https://issues.apache.org/jira/browse/SOLR-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12805601#action_12805601
> ]
>
> Uri Boness commented on SOLR-1163:
> --
>
> Actually I've been working on a new version for the
> explorer which I plan to put soon as a patch here.
>
> > Solr Explorer - A generic GWT client for Solr
> > -
> >
> >
> Key: SOLR-1163
> >
> URL: https://issues.apache.org/jira/browse/SOLR-1163
> >
> Project: Solr
> > Issue Type: New
> Feature
> > Components: web gui
> > Affects Versions: 1.3
> > Reporter: Uri
> Boness
> > Attachments:
> graphics.zip, solr-explorer.patch, solr-explorer.patch
> >
> >
> > The attached patch is a GWT generic client for solr.
> It is currently standalone, meaning that once built, one can
> open the generated HTML file in a browser and communicate
> with any deployed solr. It is configured with it's own
> configuration file, where one can configure the solr
> instance/core to connect to. Since it's currently standalone
> and completely client side based, it uses JSON with padding
> (cross-side scripting) to connect to remote solr servers.
> Some of the supported features:
> > - Simple query search
> > - Sorting - one can dynamically define new sort
> criterias
> > - Search results are rendered very much like Google
> search results are rendered. It is also possible to view all
> stored field values for every hit.
> > - Custom hit rendering - It is possible to show
> thumbnails (images) per hit and also customize a view for a
> hit based on html templates
> > - Faceting - one can dynamically define field and
> query facets via the UI. it is also possible to
> pre-configure these facets in the configuration file.
> > - Highlighting - you can dynamically configure
> highlighting. it can also be pre-configured in the
> configuration file
> > - Spellchecking - you can dynamically configure spell
> checking. Can also be done in the configuration file.
> Supports collation. It is also possible to send "build" and
> "reload" commands.
> > - Data import handler - if used, it is possible to
> send a "full-import" and "status" command ("delta-import" is
> not implemented yet, but it's easy to add)
> > - Console - For development time, there's a small
> console which can help to better understand what's going on
> behind the scenes. One can use it to:
> > ** view the client logs
> > ** browse the solr scheme
> > ** View a break down of the current search context
> > ** View a break down of the query URL that is sent to
> solr
> > ** View the raw JSON response returning from Solr
> > This client is actually a platform that can be greatly
> extended for more things. The goal is to have a client where
> the explorer part is just one view of it. Other future views
> include: Monitoring, Administration, Query Builder,
> DataImportHandler configuration, and more...
> > To get a better view of what's currently possible.
> We've set up a public version of this client at:
> http://search.jteam.nl/explorer. This client is
> configured with one solr instance where crawled YouTube
> movies where indexed. You can also check out a screencast
> for this deployed client: http://search.jteam.nl/help
> > The patch created a new folder in the contrib.
> directory. Since the patch doesn't contain binaries, an
> additional zip file is provides that needs to be extract to
> add all the required graphics. This module is maven2 based
> and is configured in such a way that all GWT related
> tools/libraries are automatically downloaded when the
> modules is compiled. One of the artifacts of the build is a
> war file which can be deployed in any servlet container.
> > NOTE: this client works best on WebKit based browsers
> (for performance reason) but also works on firefox and ie
> 7+. That said, it should be taken into account that it is
> still under development.
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue
> online.
>
>
[jira] Updated: (SOLR-1753) StatsComponent throws java.lang.NullPointerException when getting statistics for facets in distributed search
[ https://issues.apache.org/jira/browse/SOLR-1753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Janne Majaranta updated SOLR-1753: -- Attachment: SOLR-1753.patch The attached patch seems to fix the issue. Seems a bit too easy however. Am I missing something ? > StatsComponent throws java.lang.NullPointerException when getting statistics > for facets in distributed search > - > > Key: SOLR-1753 > URL: https://issues.apache.org/jira/browse/SOLR-1753 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4, 1.5 > Environment: Windows >Reporter: Janne Majaranta > Attachments: SOLR-1753.patch > > > When using the StatsComponent with a sharded request and getting statistics > over facets, a NullPointerException is thrown. > Stacktrace: > java.lang.NullPointerException at > org.apache.solr.handler.component.StatsValues.accumulate(StatsValues.java:54) > at > org.apache.solr.handler.component.StatsValues.accumulate(StatsValues.java:82) > at > org.apache.solr.handler.component.StatsComponent.handleResponses(StatsComponent.java:116) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:290) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316) at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) > at > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at > java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1753) StatsComponent throws java.lang.NullPointerException when getting statistics for facets in distributed search
StatsComponent throws java.lang.NullPointerException when getting statistics for facets in distributed search - Key: SOLR-1753 URL: https://issues.apache.org/jira/browse/SOLR-1753 Project: Solr Issue Type: Bug Affects Versions: 1.4, 1.5 Environment: Windows Reporter: Janne Majaranta When using the StatsComponent with a sharded request and getting statistics over facets, a NullPointerException is thrown. Stacktrace: java.lang.NullPointerException at org.apache.solr.handler.component.StatsValues.accumulate(StatsValues.java:54) at org.apache.solr.handler.component.StatsValues.accumulate(StatsValues.java:82) at org.apache.solr.handler.component.StatsComponent.handleResponses(StatsComponent.java:116) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:290) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: indexing a csv file with a multivalued field
On Tue, Feb 2, 2010 at 11:03 PM, Seffie Schwartz wrote: > I am not having luck doing this. Even though I am specifying -F > fieldname.separator='|' the fields are > stored as one field not as multi fields. If I specify -F > f.fieldname.separator='|' I get a null pointer exception; How are you sending the command to Solr? Can you show the full command / URL? I don't know what the "-F" is in what you have provided, but your separator should look like f..separator=| (note the lack of quotes around the pipe... your example included quotes) -Yonik http://www.lucidimagination.com
[jira] Commented: (SOLR-1750) SystemStatsRequestHandler - replacement for stats.jsp
[
https://issues.apache.org/jira/browse/SOLR-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829144#action_12829144
]
Steven Rowe commented on SOLR-1750:
---
bq. Any thoughts on the naming of this beast?
How about SysInfoRequestHandler - bonus: SIRH evokes [RFK's
assassin|http://en.wikipedia.org/wiki/Sirhan_Sirhan]
> SystemStatsRequestHandler - replacement for stats.jsp
> -
>
> Key: SOLR-1750
> URL: https://issues.apache.org/jira/browse/SOLR-1750
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SystemStatsRequestHandler.java
>
>
> stats.jsp is cool and all, but suffers from escaping issues, and also is not
> accessible from SolrJ or other standard Solr APIs.
> Here's a request handler that emits everything stats.jsp does.
> For now, it needs to be registered in solrconfig.xml like this:
> {code}
> class="solr.SystemStatsRequestHandler" />
> {code}
> But will register this in AdminHandlers automatically before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1752) SolrJ fails with exception when passing document ADD and DELETEs in the same request using XML request writer (but not binary request writer)
SolrJ fails with exception when passing document ADD and DELETEs in the same
request using XML request writer (but not binary request writer)
-
Key: SOLR-1752
URL: https://issues.apache.org/jira/browse/SOLR-1752
Project: Solr
Issue Type: Bug
Components: clients - java, update
Affects Versions: 1.4
Reporter: Jayson Minard
Priority: Blocker
Add this test to SolrExampleTests.java and it will fail when using the XML
Request Writer (now default), but not if you change the SolrExampleJettyTest to
use the BinaryRequestWriter.
{code}
public void testAddDeleteInSameRequest() throws Exception {
SolrServer server = getSolrServer();
SolrInputDocument doc3 = new SolrInputDocument();
doc3.addField( "id", "id3", 1.0f );
doc3.addField( "name", "doc3", 1.0f );
doc3.addField( "price", 10 );
UpdateRequest up = new UpdateRequest();
up.add( doc3 );
up.deleteById("id001");
up.setWaitFlush(false);
up.setWaitSearcher(false);
up.process( server );
}
{code}
terminates with exception:
{code}
Feb 3, 2010 8:55:34 AM org.apache.solr.common.SolrException log
SEVERE: org.apache.solr.common.SolrException: Illegal to have multiple roots
(start tag in epilog?).
at [row,col {unknown-source}]: [1,125]
at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:72)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:54)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
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.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
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.content(HttpConnection.java:835)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:723)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:202)
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)
Caused by: com.ctc.wstx.exc.WstxParsingException: Illegal to have multiple
roots (start tag in epilog?).
at [row,col {unknown-source}]: [1,125]
at
com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:630)
at com.ctc.wstx.sr.StreamScanner.throwParseError(StreamScanner.java:461)
at
com.ctc.wstx.sr.BasicStreamReader.handleExtraRoot(BasicStreamReader.java:2155)
at
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2070)
at
com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2647)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1019)
at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:90)
at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:69)
... 18 more
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1670) synonymfilter/map repeat bug
[
https://issues.apache.org/jira/browse/SOLR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829097#action_12829097
]
Robert Muir commented on SOLR-1670:
---
bq. Not at the semantic level (for overlapping tokens).
Another way to look at it is that a tokenstream is just a sequence of tokens,
and posInc is just another attribute.
your description of semantics makes sense in terms of how it is used by the
indexer, but the order of these tokens can matter if someone uses a custom
tokenfilter, it might matter for some custom attributes, and it might matter
for a different consumer, its different behavior. i have made an effort to
preserve all the behavior of all these tokenstreams when converting to the new
api. I really don't want to break anything.
> synonymfilter/map repeat bug
>
>
> Key: SOLR-1670
> URL: https://issues.apache.org/jira/browse/SOLR-1670
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Robert Muir
>Assignee: Yonik Seeley
> Attachments: SOLR-1670.patch, SOLR-1670.patch, SOLR-1670_test.patch
>
>
> as part of converting tests for SOLR-1657, I ran into a problem with
> synonymfilter
> the test for 'repeats' has a flaw, it uses this assertTokEqual construct
> which does not really validate that two lists of token are equal, it just
> stops at the shorted one.
> {code}
> // repeats
> map.add(strings("a b"), tokens("ab"), orig, merge);
> map.add(strings("a b"), tokens("ab"), orig, merge);
> assertTokEqual(getTokList(map,"a b",false), tokens("ab"));
> /* in reality the result from getTokList is ab ab ab! */
> {code}
> when converted to assertTokenStreamContents this problem surfaced. attached
> is an additional assertion to the existing testcase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1670) synonymfilter/map repeat bug
[
https://issues.apache.org/jira/browse/SOLR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829094#action_12829094
]
Yonik Seeley commented on SOLR-1670:
bq. I guess all along my problem is that tokenstreams are ordered by
definition.
Not at the semantic level (for overlapping tokens). For instance, it would be
incorrect for someone to rely on a specific ordering for overlapping tokens -
order has never been guaranteed by any TokenFilters that do produce overlapping
tokens, and in fact the ordering for some has changed in the past as the
implementation changed.
> synonymfilter/map repeat bug
>
>
> Key: SOLR-1670
> URL: https://issues.apache.org/jira/browse/SOLR-1670
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Robert Muir
>Assignee: Yonik Seeley
> Attachments: SOLR-1670.patch, SOLR-1670.patch, SOLR-1670_test.patch
>
>
> as part of converting tests for SOLR-1657, I ran into a problem with
> synonymfilter
> the test for 'repeats' has a flaw, it uses this assertTokEqual construct
> which does not really validate that two lists of token are equal, it just
> stops at the shorted one.
> {code}
> // repeats
> map.add(strings("a b"), tokens("ab"), orig, merge);
> map.add(strings("a b"), tokens("ab"), orig, merge);
> assertTokEqual(getTokList(map,"a b",false), tokens("ab"));
> /* in reality the result from getTokList is ab ab ab! */
> {code}
> when converted to assertTokenStreamContents this problem surfaced. attached
> is an additional assertion to the existing testcase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1670) synonymfilter/map repeat bug
[
https://issues.apache.org/jira/browse/SOLR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829092#action_12829092
]
Robert Muir commented on SOLR-1670:
---
bq. Order of overlapping tokens is unimportant in every TokenFilter used in
Solr that I know about. Order-sensitivity is the exception, no?
I guess all along my problem is that tokenstreams are ordered by definition. if
this order does not matter, a test that uses actual queries would make more
sense.
The problem was that the test constructions previously used by this filter were
used in other places where they really shouldn't have been, and the laxness hid
real bugs (such as this very issue itself!!!).
This is all I am trying to avoid. There is nothing wrong with Steven's
patch/test construction, just trying to err on the side of caution.
> synonymfilter/map repeat bug
>
>
> Key: SOLR-1670
> URL: https://issues.apache.org/jira/browse/SOLR-1670
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Robert Muir
>Assignee: Yonik Seeley
> Attachments: SOLR-1670.patch, SOLR-1670.patch, SOLR-1670_test.patch
>
>
> as part of converting tests for SOLR-1657, I ran into a problem with
> synonymfilter
> the test for 'repeats' has a flaw, it uses this assertTokEqual construct
> which does not really validate that two lists of token are equal, it just
> stops at the shorted one.
> {code}
> // repeats
> map.add(strings("a b"), tokens("ab"), orig, merge);
> map.add(strings("a b"), tokens("ab"), orig, merge);
> assertTokEqual(getTokList(map,"a b",false), tokens("ab"));
> /* in reality the result from getTokList is ab ab ab! */
> {code}
> when converted to assertTokenStreamContents this problem surfaced. attached
> is an additional assertion to the existing testcase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1748) RawResponseWriter doesn't close Reader
[
https://issues.apache.org/jira/browse/SOLR-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-1748:
--
Attachment: SOLR-1748.patch
> RawResponseWriter doesn't close Reader
> --
>
> Key: SOLR-1748
> URL: https://issues.apache.org/jira/browse/SOLR-1748
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Mark Miller
> Fix For: 1.5
>
> Attachments: SOLR-1748.patch
>
>
> {code}
> IOUtils.copy( content.getReader(), writer );
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1745) MoreLikeThisHandler gets a Reader from a ContentStream and doesn't close it
[ https://issues.apache.org/jira/browse/SOLR-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1745: -- Attachment: SOLR-1745.patch > MoreLikeThisHandler gets a Reader from a ContentStream and doesn't close it > --- > > Key: SOLR-1745 > URL: https://issues.apache.org/jira/browse/SOLR-1745 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1745.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1747) DumpRequestHandler doesn't close Stream
[
https://issues.apache.org/jira/browse/SOLR-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-1747:
--
Attachment: SOLR-1747.patch
> DumpRequestHandler doesn't close Stream
> ---
>
> Key: SOLR-1747
> URL: https://issues.apache.org/jira/browse/SOLR-1747
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Mark Miller
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1747.patch
>
>
> {code}
> stream.add( "stream", IOUtils.toString( content.getStream() ) );
> {code}
> IOUtils.toString won't close the stream for you.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1670) synonymfilter/map repeat bug
[
https://issues.apache.org/jira/browse/SOLR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829088#action_12829088
]
Yonik Seeley commented on SOLR-1670:
bq. is it possible to only expose the 'unsorted' one to synonyms test (such as
in the synonyms test file itself, rather than base token stream test case?)
Order of overlapping tokens is unimportant in every TokenFilter used in Solr
that I know about. Order-sensitivity is the exception, no?
> synonymfilter/map repeat bug
>
>
> Key: SOLR-1670
> URL: https://issues.apache.org/jira/browse/SOLR-1670
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Robert Muir
>Assignee: Yonik Seeley
> Attachments: SOLR-1670.patch, SOLR-1670.patch, SOLR-1670_test.patch
>
>
> as part of converting tests for SOLR-1657, I ran into a problem with
> synonymfilter
> the test for 'repeats' has a flaw, it uses this assertTokEqual construct
> which does not really validate that two lists of token are equal, it just
> stops at the shorted one.
> {code}
> // repeats
> map.add(strings("a b"), tokens("ab"), orig, merge);
> map.add(strings("a b"), tokens("ab"), orig, merge);
> assertTokEqual(getTokList(map,"a b",false), tokens("ab"));
> /* in reality the result from getTokList is ab ab ab! */
> {code}
> when converted to assertTokenStreamContents this problem surfaced. attached
> is an additional assertion to the existing testcase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[ https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829087#action_12829087 ] Chris A. Mattmann commented on SOLR-1602: - Hey Erik: You just forgot to press the easy button! :P http://bit.ly/zog3s Cheers, Chris > Refactor SOLR package structure to include o.a.solr.response and move > QueryResponseWriters in there > --- > > Key: SOLR-1602 > URL: https://issues.apache.org/jira/browse/SOLR-1602 > Project: Solr > Issue Type: Improvement > Components: Response Writers >Affects Versions: 1.2, 1.3, 1.4 > Environment: independent of environment (code structure) >Reporter: Chris A. Mattmann >Assignee: Ryan McKinley > Fix For: 1.5 > > Attachments: SOLR-1602.Mattmann.112509.patch.txt, > SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config > > > Currently all o.a.solr.request.QueryResponseWriter implementations are > curiously located in the o.a.solr.request package. Not only is this package > getting big (30+ classes), a lot of them are misplaced. There should be a > first-class o.a.solr.response package, and the response related classes > should be given a home there. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1744) Streams retrieved from ContenStream#getStream are not always closed
[ https://issues.apache.org/jira/browse/SOLR-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1744: -- Attachment: SOLR-1744.patch Also includes fix for SOLR-1746 > Streams retrieved from ContenStream#getStream are not always closed > --- > > Key: SOLR-1744 > URL: https://issues.apache.org/jira/browse/SOLR-1744 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Mark Miller > Fix For: 1.5 > > Attachments: SOLR-1744.patch > > > Doesn't look like BinaryUpdateRequestHandler or CommonsHttpSolrServer close > streams. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1718) Carriage return should submit query admin form
[ https://issues.apache.org/jira/browse/SOLR-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829082#action_12829082 ] David Smiley commented on SOLR-1718: bq. It sounds like what you are really suggesting is that we change the /admin/index.jsp form to use a instead of a for the "q" param, and not that we add special (javascript) logic to the form to submit if someone presses Enter inside the existing ... which i have a lot less objection to then going out of our way to violate standard form convention. Yes. > Carriage return should submit query admin form > -- > > Key: SOLR-1718 > URL: https://issues.apache.org/jira/browse/SOLR-1718 > Project: Solr > Issue Type: Improvement > Components: web gui >Affects Versions: 1.4 >Reporter: David Smiley >Priority: Minor > > Hitting the carriage return on the keyboard should submit the search query on > the admin front screen. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1670) synonymfilter/map repeat bug
[
https://issues.apache.org/jira/browse/SOLR-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829079#action_12829079
]
Steven Rowe commented on SOLR-1670:
---
bq. is it possible to expose the 'unsorted' one to synonyms test (such as in
the synonyms test file itself, rather than base token stream test case?)
I wrote it the way I did to reduce code duplication/maintenance effort, e.g.
the upcoming sync with Lucene's changes in this area.
I'm thinking it should be possible to refactor the current method to serve both
the sorted case and an external unsorted case. I'll work on it.
> synonymfilter/map repeat bug
>
>
> Key: SOLR-1670
> URL: https://issues.apache.org/jira/browse/SOLR-1670
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Robert Muir
>Assignee: Yonik Seeley
> Attachments: SOLR-1670.patch, SOLR-1670.patch, SOLR-1670_test.patch
>
>
> as part of converting tests for SOLR-1657, I ran into a problem with
> synonymfilter
> the test for 'repeats' has a flaw, it uses this assertTokEqual construct
> which does not really validate that two lists of token are equal, it just
> stops at the shorted one.
> {code}
> // repeats
> map.add(strings("a b"), tokens("ab"), orig, merge);
> map.add(strings("a b"), tokens("ab"), orig, merge);
> assertTokEqual(getTokList(map,"a b",false), tokens("ab"));
> /* in reality the result from getTokList is ab ab ab! */
> {code}
> when converted to assertTokenStreamContents this problem surfaced. attached
> is an additional assertion to the existing testcase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1729) Date Facet now override time parameter
[ https://issues.apache.org/jira/browse/SOLR-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829077#action_12829077 ] Yonik Seeley commented on SOLR-1729: bq. Sounds like DateField would the best candidate for holding the ThreadLocal? It might be nice to provide a public static method like public static long getNow() for code that needs the value of NOW w/o going through date math (the ms() function for one) The other question is how the value is set to a particular value passed in on the request (for distributed search sync say). It seems a bit awkward to have something global like SolrCore.execute checking and setting "NOW"... an alternative that could help solve other problems is to have SolrCore.execute set a ThreadLocal that things like getNow() could check for a NOW param if it's thread local was not yet set. Another thing to think about: unlike the DateFormatter threadLocal, a NOW threadLocal changes behavior - so it needs to be well defined, and not just a local cache no one else knows about. Example: say that we parallelize some things in the future and spin of multiple threads... if the threadLocal for NOW is not communicated to each thread, they would all come up with their own values again. > Date Facet now override time parameter > -- > > Key: SOLR-1729 > URL: https://issues.apache.org/jira/browse/SOLR-1729 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 > Environment: Solr 1.4 >Reporter: Peter Sturge >Priority: Minor > Attachments: FacetParams.java, SimpleFacets.java > > > This PATCH introduces a new query parameter that tells a (typically, but not > necessarily) remote server what time to use as 'NOW' when calculating date > facets for a query (and, for the moment, date facets *only*) - overriding the > default behaviour of using the local server's current time. > This gets 'round a problem whereby an explicit time range is specified in a > query (e.g. timestamp:[then0 TO then1]), and date facets are required for the > given time range (in fact, any explicit time range). > Because DateMathParser performs all its calculations from 'NOW', remote > callers have to work out how long ago 'then0' and 'then1' are from 'now', and > use the relative-to-now values in the facet.date.xxx parameters. If a remote > server has a different opinion of NOW compared to the caller, the results > will be skewed (e.g. they are in a different time-zone, not time-synced etc.). > This becomes particularly salient when performing distributed date faceting > (see SOLR-1709), where multiple shards may all be running with different > times, and the faceting needs to be aligned. > The new parameter is called 'facet.date.now', and takes as a parameter a > (stringified) long that is the number of milliseconds from the epoch (1 Jan > 1970 00:00) - i.e. the returned value from a System.currentTimeMillis() call. > This was chosen over a formatted date to delineate it from a 'searchable' > time and to avoid superfluous date parsing. This makes the value generally a > programatically-set value, but as that is where the use-case is for this type > of parameter, this should be ok. > NOTE: This parameter affects date facet timing only. If there are other areas > of a query that rely on 'NOW', these will not interpret this value. This is a > broader issue about setting a 'query-global' NOW that all parts of query > analysis can share. > Source files affected: > FacetParams.java (holds the new constant FACET_DATE_NOW) > SimpleFacets.java getFacetDateCounts() NOW parameter modified > This PATCH is mildly related to SOLR-1709 (Distributed Date Faceting), but as > it's a general change for date faceting, it was deemed deserving of its own > patch. I will be updating SOLR-1709 in due course to include the use of this > new parameter, after some rfc acceptance. > A possible enhancement to this is to detect facet.date fields, look for and > match these fields in queries (if they exist), and potentially determine > automatically the required time skew, if any. There are a whole host of > reasons why this could be problematic to implement, so an explicit > facet.date.now parameter is the safest route. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1751) SpatialSearch: documented example is not working
SpatialSearch: documented example is not working
Key: SOLR-1751
URL: https://issues.apache.org/jira/browse/SOLR-1751
Project: Solr
Issue Type: Bug
Affects Versions: 1.5
Environment: Windows
Reporter: Brainski
Fix For: 1.5
I downloaded the nightly build from 03. February 2010 and tried the example as
documented under:
http://wiki.apache.org/solr/SpatialSearch
I imported all documents under exampledocs in the index.
Then I tried the following search request:
http://localhost:8983/solr/select/?q=_val_:"recip(dist(2, store,
point(34.0232,-81.0664)),1,1,0)"&fl=*,score
--
This leads to the following error:
HTTP ERROR: 400
org.apache.lucene.queryParser.ParseException: Cannot parse
'_val_:"recip(dist(2, store, point(34.0232,-81.0664)),1,1,0)"': Unknown
function point in FunctionQuery('recip(dist(2, store,
point(34.0232,-81.0664)),1,1,0)', pos=27)
RequestURI=/solr/select/
--
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1750) SystemStatsRequestHandler - replacement for stats.jsp
[
https://issues.apache.org/jira/browse/SOLR-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829052#action_12829052
]
Erik Hatcher commented on SOLR-1750:
Also, food for thought, when (hopefully not if) the VelocityResponseWriter is
moved into core, we can deprecate stats.jsp and skin the output of this request
handler for a similar pleasant view like stats.jsp+client-side xsl does now.
> SystemStatsRequestHandler - replacement for stats.jsp
> -
>
> Key: SOLR-1750
> URL: https://issues.apache.org/jira/browse/SOLR-1750
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SystemStatsRequestHandler.java
>
>
> stats.jsp is cool and all, but suffers from escaping issues, and also is not
> accessible from SolrJ or other standard Solr APIs.
> Here's a request handler that emits everything stats.jsp does.
> For now, it needs to be registered in solrconfig.xml like this:
> {code}
> class="solr.SystemStatsRequestHandler" />
> {code}
> But will register this in AdminHandlers automatically before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1750) SystemStatsRequestHandler - replacement for stats.jsp
[
https://issues.apache.org/jira/browse/SOLR-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829050#action_12829050
]
Erik Hatcher commented on SOLR-1750:
I'll commit this in the near future.
Any thoughts on the naming of this beast? "stats" is a bit overloaded
(StatsComponent). as is "system" (SystemInfoHandler).
> SystemStatsRequestHandler - replacement for stats.jsp
> -
>
> Key: SOLR-1750
> URL: https://issues.apache.org/jira/browse/SOLR-1750
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SystemStatsRequestHandler.java
>
>
> stats.jsp is cool and all, but suffers from escaping issues, and also is not
> accessible from SolrJ or other standard Solr APIs.
> Here's a request handler that emits everything stats.jsp does.
> For now, it needs to be registered in solrconfig.xml like this:
> {code}
> class="solr.SystemStatsRequestHandler" />
> {code}
> But will register this in AdminHandlers automatically before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1750) SystemStatsRequestHandler - replacement for stats.jsp
[
https://issues.apache.org/jira/browse/SOLR-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher updated SOLR-1750:
---
Attachment: SystemStatsRequestHandler.java
> SystemStatsRequestHandler - replacement for stats.jsp
> -
>
> Key: SOLR-1750
> URL: https://issues.apache.org/jira/browse/SOLR-1750
> Project: Solr
> Issue Type: Improvement
> Components: web gui
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SystemStatsRequestHandler.java
>
>
> stats.jsp is cool and all, but suffers from escaping issues, and also is not
> accessible from SolrJ or other standard Solr APIs.
> Here's a request handler that emits everything stats.jsp does.
> For now, it needs to be registered in solrconfig.xml like this:
> {code}
> class="solr.SystemStatsRequestHandler" />
> {code}
> But will register this in AdminHandlers automatically before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1750) SystemStatsRequestHandler - replacement for stats.jsp
SystemStatsRequestHandler - replacement for stats.jsp
-
Key: SOLR-1750
URL: https://issues.apache.org/jira/browse/SOLR-1750
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Trivial
Fix For: 1.5
Attachments: SystemStatsRequestHandler.java
stats.jsp is cool and all, but suffers from escaping issues, and also is not
accessible from SolrJ or other standard Solr APIs.
Here's a request handler that emits everything stats.jsp does.
For now, it needs to be registered in solrconfig.xml like this:
{code}
{code}
But will register this in AdminHandlers automatically before committing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1602) Refactor SOLR package structure to include o.a.solr.response and move QueryResponseWriters in there
[
https://issues.apache.org/jira/browse/SOLR-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829044#action_12829044
]
Erik Hatcher commented on SOLR-1602:
I've encountered an issue with this refactoring, with some local toy request
handlers I had laying around:
{code}
//..
import org.apache.solr.request.SolrQueryResponse;
public class HighlightingHandler extends RequestHandlerBase {
@Override
public void handleRequestBody(SolrQueryRequest req, SolrQueryResponse rsp)
throws Exception
// ...
{code}
This class no longer compiled. Nor if I had a binary version of this and
upgraded Solr would it have run.
I'm just sayin.
No big deal for me, as I'm refactoring my code. I guess it's the price you
have to pay for change. But deprecating simply wasn't good enough to keep
things that were working working.
> Refactor SOLR package structure to include o.a.solr.response and move
> QueryResponseWriters in there
> ---
>
> Key: SOLR-1602
> URL: https://issues.apache.org/jira/browse/SOLR-1602
> Project: Solr
> Issue Type: Improvement
> Components: Response Writers
>Affects Versions: 1.2, 1.3, 1.4
> Environment: independent of environment (code structure)
>Reporter: Chris A. Mattmann
>Assignee: Ryan McKinley
> Fix For: 1.5
>
> Attachments: SOLR-1602.Mattmann.112509.patch.txt,
> SOLR-1602.Mattmann.112509_02.patch.txt, upgrade_solr_config
>
>
> Currently all o.a.solr.request.QueryResponseWriter implementations are
> curiously located in the o.a.solr.request package. Not only is this package
> getting big (30+ classes), a lot of them are misplaced. There should be a
> first-class o.a.solr.response package, and the response related classes
> should be given a home there. Patch forthcoming.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1729) Date Facet now override time parameter
[ https://issues.apache.org/jira/browse/SOLR-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829043#action_12829043 ] Peter Sturge commented on SOLR-1729: Hi Chris, Thanks for your comments - I hope I didn't sound like your comments were taken wrongly - I absolutely count on comments from you and other experts to make sure I'm not missing some important functionality and/or side effect. You know the code base far better than I, so its great that you take the time to point out all the different bits and peices that need addressing. I can certainly understand the need to address the 'core-global' isssues raised by you and Yonik for storing a ThreadLocal 'query-global' 'NOW'. I suppose the main issue in implementing the thread-local route is that we'd have to make sure we found every place in the query core that references now, and point those references to the new variable? If the 'code-at-large' [hopefully] always calls the date math routines for finding 'NOW', great, it should be relatively straightforward. If there are any stray e.g. System.currentTimeMillis(), then it's a bit more fiddly, but still do-able. ??it's all handled internally by DateField?? Sounds like DateField would the best candidate for holding the ThreadLocal? The query handler code can set the variable of its DateField instance if it's set in a query parameter, otherwise it just defaults to it's own local (UTC) time. Could be done similarly to DateField.ThreadLocalDateFormat, perhaps? > Date Facet now override time parameter > -- > > Key: SOLR-1729 > URL: https://issues.apache.org/jira/browse/SOLR-1729 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 > Environment: Solr 1.4 >Reporter: Peter Sturge >Priority: Minor > Attachments: FacetParams.java, SimpleFacets.java > > > This PATCH introduces a new query parameter that tells a (typically, but not > necessarily) remote server what time to use as 'NOW' when calculating date > facets for a query (and, for the moment, date facets *only*) - overriding the > default behaviour of using the local server's current time. > This gets 'round a problem whereby an explicit time range is specified in a > query (e.g. timestamp:[then0 TO then1]), and date facets are required for the > given time range (in fact, any explicit time range). > Because DateMathParser performs all its calculations from 'NOW', remote > callers have to work out how long ago 'then0' and 'then1' are from 'now', and > use the relative-to-now values in the facet.date.xxx parameters. If a remote > server has a different opinion of NOW compared to the caller, the results > will be skewed (e.g. they are in a different time-zone, not time-synced etc.). > This becomes particularly salient when performing distributed date faceting > (see SOLR-1709), where multiple shards may all be running with different > times, and the faceting needs to be aligned. > The new parameter is called 'facet.date.now', and takes as a parameter a > (stringified) long that is the number of milliseconds from the epoch (1 Jan > 1970 00:00) - i.e. the returned value from a System.currentTimeMillis() call. > This was chosen over a formatted date to delineate it from a 'searchable' > time and to avoid superfluous date parsing. This makes the value generally a > programatically-set value, but as that is where the use-case is for this type > of parameter, this should be ok. > NOTE: This parameter affects date facet timing only. If there are other areas > of a query that rely on 'NOW', these will not interpret this value. This is a > broader issue about setting a 'query-global' NOW that all parts of query > analysis can share. > Source files affected: > FacetParams.java (holds the new constant FACET_DATE_NOW) > SimpleFacets.java getFacetDateCounts() NOW parameter modified > This PATCH is mildly related to SOLR-1709 (Distributed Date Faceting), but as > it's a general change for date faceting, it was deemed deserving of its own > patch. I will be updating SOLR-1709 in due course to include the use of this > new parameter, after some rfc acceptance. > A possible enhancement to this is to detect facet.date fields, look for and > match these fields in queries (if they exist), and potentially determine > automatically the required time skew, if any. There are a whole host of > reasons why this could be problematic to implement, so an explicit > facet.date.now parameter is the safest route. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: indexing a csv file with a multivalued field
you probably can write an UpdateProcessor to achieve this On Wed, Feb 3, 2010 at 9:33 AM, Seffie Schwartz wrote: > I am not having luck doing this. Even though I am specifying -F > fieldname.separator='|' the fields are > stored as one field not as multi fields. If I specify -F > f.fieldname.separator='|' I get a null pointer exception; > > > -- - Noble Paul | Systems Architect| AOL | http://aol.com
