[jira] Commented: (SOLR-1292) show lucene fieldcache entries and sizes
[ https://issues.apache.org/jira/browse/SOLR-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752952#action_12752952 ] Hoss Man commented on SOLR-1292: this does everything the issue summary suggests in a very simple way ... but personally i think we should also use FieldCache.setInfoStream and and log an error anytime anything is written to that stream -- but i'm not sure if it's worth adding an option for that ... if it was always on it could (concievably) have a noticeable effect on static warming of many small field caches. > show lucene fieldcache entries and sizes > > > Key: SOLR-1292 > URL: https://issues.apache.org/jira/browse/SOLR-1292 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1292.patch > > > See LUCENE-1749, FieldCache introspection API -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1292) show lucene fieldcache entries and sizes
[ https://issues.apache.org/jira/browse/SOLR-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1292: --- Attachment: SOLR-1292.patch rough start ... adds a hardcoded MBean that just wraps FieldCache.getEntries() and FieldCacheSanityChecker in it's getStatistics() method. > show lucene fieldcache entries and sizes > > > Key: SOLR-1292 > URL: https://issues.apache.org/jira/browse/SOLR-1292 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley >Assignee: Mark Miller >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1292.patch > > > See LUCENE-1749, FieldCache introspection API -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1255) An attempt to visit the replication admin page when its not a defined handler should display an approp message
[ https://issues.apache.org/jira/browse/SOLR-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752922#action_12752922 ] Noble Paul commented on SOLR-1255: -- bq.why not let multiple instances exist? I am fine with the idea of multiple ReplicationHandler instances (as it is now). I was suggesting that let us attack that issue separately. > An attempt to visit the replication admin page when its not a defined handler > should display an approp message > -- > > Key: SOLR-1255 > URL: https://issues.apache.org/jira/browse/SOLR-1255 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Noble Paul >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1255.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1396) standardize the updateprocessorchain syntax
[
https://issues.apache.org/jira/browse/SOLR-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752921#action_12752921
]
Noble Paul commented on SOLR-1396:
--
it is not enough to have simple configuration. we need standardized parsing
also. I have modified SolrConfig in such a way that we must not need to write
any xml parsing for new components as long as we stick to the standard syntax
(SOLR-1198). Going forward SolrConfig implementation should be pluggable and
be xml independent, we should have a simplified interface for SolrConfig so
that users can read it from anywhere (xml, zookeeper,db etct etc)
> standardize the updateprocessorchain syntax
> ---
>
> Key: SOLR-1396
> URL: https://issues.apache.org/jira/browse/SOLR-1396
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
> Fix For: 1.4
>
>
> updateprocessorChain follows a non-standard syntax in solr . Usually, all the
> components are initialized as top level components and they are assembled and
> used using a NamedList syntax .for example search components.
> I propose to change it as follows
> {code:xml}
> class="solr.UpdateRequestProcessorChain">
>
> custom
> runUpdate
> log
>
>
> class="solr.CustomUpdateRequestProcessorFactory" >
>
> x1
> x2
>
>
>
>
>
> {code}
> The wiki documentation says this was supposed to be reviewed. If possible we
> should clean it up in 1.4 itself. We can support the old syntax 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-1273) rectify confusing "Replication" and "Distribution" links on solr admin screen
[ https://issues.apache.org/jira/browse/SOLR-1273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1273: --- Fix Version/s: (was: 1.4) I still think it would be a good idea in the long run to have a more unified approach to these two pages, but as a short term improvement to the situation, i've added links to the wiki so people can at least understand what each page is, and find docs that immediately point them to using the other if it's not hte one their looking for. Committed revision 812772. > rectify confusing "Replication" and "Distribution" links on solr admin screen > - > > Key: SOLR-1273 > URL: https://issues.apache.org/jira/browse/SOLR-1273 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Hoss Man >Priority: Minor > > Sine 1.0, the Solr Admin screen has had a "Distribution" link which points to > "distributiondump.jsp" and displays stats according to data files created by > the snappuller/snapinstaller scripts > With the new java based replication, when a ReplicationHandler is enabled, we > now have a "Replication" link on the admin page pointing to > "replication/index.jsp" which displays stats/status for java based > replication. > In at least one instance, these two different links confused a user... > http://www.nabble.com/Replication-In-1.4-to24356158.html#a24356158 > We need to rectify this confusion prior to releasing 1.4. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1255) An attempt to visit the replication admin page when its not a defined handler should display an approp message
[ https://issues.apache.org/jira/browse/SOLR-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752901#action_12752901 ] Hoss Man commented on SOLR-1255: FWIW... bq. Isn't better if we enhance the replicationhandler so that one instance should be good enough for all usecases and disallow multiple instances That's like saying should we enhance SearhHandler so one instance is good enough for all usecases -- why try to shoehorn thins like this? why not let multiple instances exist? that's a major feature of the RequestHandler API, that you can have multiple instances, and configure them differently. > An attempt to visit the replication admin page when its not a defined handler > should display an approp message > -- > > Key: SOLR-1255 > URL: https://issues.apache.org/jira/browse/SOLR-1255 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Noble Paul >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1255.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1396) standardize the updateprocessorchain syntax
[
https://issues.apache.org/jira/browse/SOLR-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752899#action_12752899
]
Hoss Man commented on SOLR-1396:
bq. This is for standardization. the searchcomponent has a similar configuration
but search components _are_ a pluggable, and have a generic init(NamedList)
method ... so do request handlers, and i think what you are refering to is the
way the component list for a SearchHandler instance is specified -- in that
case named arrays are included in the broader NamedList of the init method to
distibguish what it is (because some RequestHandlers could have all sorts of
other init params.
but if updateRequestProcessorChain isn't going to be pluggable (as you said: we
don't need a class attribute) then we don't need to worry about providing
generalized init param support for it ... so we can keep the syntax simple.
really it just comes down to whether or not update processors can really be
refrenced by name and reused in multiple chains. if they can't this is all
moot, but if they can then it would certianly make sense to give them names,
and break them out like you describe, and then keep the chains simple...
{code}
signature
logger
runupdate
{code}
> standardize the updateprocessorchain syntax
> ---
>
> Key: SOLR-1396
> URL: https://issues.apache.org/jira/browse/SOLR-1396
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
> Fix For: 1.4
>
>
> updateprocessorChain follows a non-standard syntax in solr . Usually, all the
> components are initialized as top level components and they are assembled and
> used using a NamedList syntax .for example search components.
> I propose to change it as follows
> {code:xml}
> class="solr.UpdateRequestProcessorChain">
>
> custom
> runUpdate
> log
>
>
> class="solr.CustomUpdateRequestProcessorFactory" >
>
> x1
> x2
>
>
>
>
>
> {code}
> The wiki documentation says this was supposed to be reviewed. If possible we
> should clean it up in 1.4 itself. We can support the old syntax too
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1410) remove deprecated custom encoding support in russian/greek analysis
[ https://issues.apache.org/jira/browse/SOLR-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-1410. Resolution: Fixed > remove deprecated custom encoding support in russian/greek analysis > --- > > Key: SOLR-1410 > URL: https://issues.apache.org/jira/browse/SOLR-1410 > Project: Solr > Issue Type: Task > Components: Analysis >Reporter: Robert Muir >Assignee: Hoss Man >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1410.patch > > > In this case, analyzers have strange encoding support and it has been > deprecated in lucene. > For example someone using CP1251 in the russian analyzer is simply storing Ж > as 0xC6, its being represented as Æ > LUCENE-1793: Deprecate the custom encoding support in the Greek and Russian > Analyzers. If you need to index text in these encodings, please use Java's > character set conversion facilities (InputStreamReader, etc) during I/O, > so that Lucene can analyze this text as Unicode instead. > I noticed in solr, the factories for these tokenstreams allow these > configuration options, which are deprecated in 2.9 to be removed in 3.0 > Let me know the policy (how do you deprecate a config option in solr exactly, > log a warning, etc?) and I'd be happy to create a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1410) remove deprecated custom encoding support in russian/greek analysis
[ https://issues.apache.org/jira/browse/SOLR-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752890#action_12752890 ] Hoss Man commented on SOLR-1410: Committed revision 812760. thanks robert > remove deprecated custom encoding support in russian/greek analysis > --- > > Key: SOLR-1410 > URL: https://issues.apache.org/jira/browse/SOLR-1410 > Project: Solr > Issue Type: Task > Components: Analysis >Reporter: Robert Muir >Assignee: Hoss Man >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1410.patch > > > In this case, analyzers have strange encoding support and it has been > deprecated in lucene. > For example someone using CP1251 in the russian analyzer is simply storing Ж > as 0xC6, its being represented as Æ > LUCENE-1793: Deprecate the custom encoding support in the Greek and Russian > Analyzers. If you need to index text in these encodings, please use Java's > character set conversion facilities (InputStreamReader, etc) during I/O, > so that Lucene can analyze this text as Unicode instead. > I noticed in solr, the factories for these tokenstreams allow these > configuration options, which are deprecated in 2.9 to be removed in 3.0 > Let me know the policy (how do you deprecate a config option in solr exactly, > log a warning, etc?) and I'd be happy to create a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1417) solrj DocumentObjectBinder prints to stdout rather than using slf4j
[
https://issues.apache.org/jira/browse/SOLR-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul resolved SOLR-1417.
--
Resolution: Fixed
committed r812759 . The logging was just done for debugging purposes
Thanks Ilan
> solrj DocumentObjectBinder prints to stdout rather than using slf4j
> ---
>
> Key: SOLR-1417
> URL: https://issues.apache.org/jira/browse/SOLR-1417
> Project: Solr
> Issue Type: Bug
> Components: clients - java
>Affects Versions: 1.4
>Reporter: Ilan Rabinovitch
>Priority: Minor
>
> We have nnoticed that in trunk the inject method of DocumentObjectBinder [1]
> for solrj logs to standard out using System.out.println if any variables in
> the returned result have a null value. Since system.out is not configurable
> this can get quite spammy on the console.
> Should this be logging at the INFO/DEBUG level using slf4j instead?
> The system.out.println statement was added on 2009-07-14 as part of SOLR-1129
> (r794144).
> ---
> [1]
> src/solrj/org/apache/solr/client/solrj/beans/DocumentObjectBinder.java:316
> (r794144)
> void inject(T obj, SolrDocument sdoc) {
> Object val = getFieldValue(sdoc);
> if(val == null) {
> System.out.println("val null for "+ name);
> return;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1255) An attempt to visit the replication admin page when its not a defined handler should display an approp message
[ https://issues.apache.org/jira/browse/SOLR-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1255. -- Resolution: Fixed we have fixed the main issue and the issue of handling multiple replicationhandler instances can be handled in a separate issue > An attempt to visit the replication admin page when its not a defined handler > should display an approp message > -- > > Key: SOLR-1255 > URL: https://issues.apache.org/jira/browse/SOLR-1255 > Project: Solr > Issue Type: Bug >Reporter: Mark Miller >Assignee: Noble Paul >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1255.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-1275: Assignee: (was: Noble Paul) > Add expungeDeletes to DirectUpdateHandler2 > -- > > Key: SOLR-1275 > URL: https://issues.apache.org/jira/browse/SOLR-1275 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1275.patch, SOLR-1275.patch, SOLR-1275.patch, > SOLR-1275.patch, SOLR-1275.patch, SOLR-1275.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > expungeDeletes is a useful method somewhat like optimize is offered by > IndexWriter that can be implemented in DirectUpdateHandler2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752880#action_12752880 ] Noble Paul commented on SOLR-1275: -- here is some confusion on whether the testcase is right/good enough. Yonik may have a final word on this > Add expungeDeletes to DirectUpdateHandler2 > -- > > Key: SOLR-1275 > URL: https://issues.apache.org/jira/browse/SOLR-1275 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Assignee: Noble Paul >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1275.patch, SOLR-1275.patch, SOLR-1275.patch, > SOLR-1275.patch, SOLR-1275.patch, SOLR-1275.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > expungeDeletes is a useful method somewhat like optimize is offered by > IndexWriter that can be implemented in DirectUpdateHandler2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1415) Issue with starting example
[ https://issues.apache.org/jira/browse/SOLR-1415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-1415. Resolution: Cannot Reproduce confirm yonik's Can't Reproduce i suspect this is from an unclean build after the TokenizerFactory signature change a little while back (from TokenStream to Tokenizer as the return type) > Issue with starting example > --- > > Key: SOLR-1415 > URL: https://issues.apache.org/jira/browse/SOLR-1415 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 > Environment: Linux >Reporter: Bill Bell > > Build from trunk. Get this error. > SEVERE: java.lang.AbstractMethodError: > org.apache.solr.analysis.WhitespaceTokenizerFactory.create(Ljava/io/Reader;)Lorg/apache/lucene/analysis/Tokenizer; > at > org.apache.solr.analysis.TokenizerChain.getStream(TokenizerChain.java:69) > at > org.apache.solr.analysis.SolrAnalyzer.reusableTokenStream(SolrAnalyzer.java:74) > at > org.apache.solr.schema.IndexSchema$SolrIndexAnalyzer.reusableTokenStream(IndexSchema.java:364) > at > org.apache.lucene.queryParser.QueryParser.getFieldQuery(QueryParser.java:543) > at > org.apache.solr.search.SolrQueryParser.getFieldQuery(SolrQueryParser.java:117) > at > org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1425) > at > org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1313) > at > org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1241) > at > org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1230) > at > org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:176) > at > org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:78) > at org.apache.solr.search.QParser.getQuery(QParser.java:131) > at > org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:89) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:174) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) > at > org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:52) > at org.apache.solr.core.SolrCore$3.call(SolrCore.java:1129) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1410) remove deprecated custom encoding support in russian/greek analysis
[ https://issues.apache.org/jira/browse/SOLR-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1410: --- Fix Version/s: 1.4 Assignee: Hoss Man > remove deprecated custom encoding support in russian/greek analysis > --- > > Key: SOLR-1410 > URL: https://issues.apache.org/jira/browse/SOLR-1410 > Project: Solr > Issue Type: Task > Components: Analysis >Reporter: Robert Muir >Assignee: Hoss Man >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1410.patch > > > In this case, analyzers have strange encoding support and it has been > deprecated in lucene. > For example someone using CP1251 in the russian analyzer is simply storing Ж > as 0xC6, its being represented as Æ > LUCENE-1793: Deprecate the custom encoding support in the Greek and Russian > Analyzers. If you need to index text in these encodings, please use Java's > character set conversion facilities (InputStreamReader, etc) during I/O, > so that Lucene can analyze this text as Unicode instead. > I noticed in solr, the factories for these tokenstreams allow these > configuration options, which are deprecated in 2.9 to be removed in 3.0 > Let me know the policy (how do you deprecate a config option in solr exactly, > log a warning, etc?) and I'd be happy to create a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1417) solrj DocumentObjectBinder prints to stdout rather than using slf4j
solrj DocumentObjectBinder prints to stdout rather than using slf4j
---
Key: SOLR-1417
URL: https://issues.apache.org/jira/browse/SOLR-1417
Project: Solr
Issue Type: Bug
Components: clients - java
Affects Versions: 1.4
Reporter: Ilan Rabinovitch
Priority: Minor
We have nnoticed that in trunk the inject method of DocumentObjectBinder [1]
for solrj logs to standard out using System.out.println if any variables in the
returned result have a null value. Since system.out is not configurable this
can get quite spammy on the console.
Should this be logging at the INFO/DEBUG level using slf4j instead?
The system.out.println statement was added on 2009-07-14 as part of SOLR-1129
(r794144).
---
[1] src/solrj/org/apache/solr/client/solrj/beans/DocumentObjectBinder.java:316
(r794144)
void inject(T obj, SolrDocument sdoc) {
Object val = getFieldValue(sdoc);
if(val == null) {
System.out.println("val null for "+ name);
return;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1410) remove deprecated custom encoding support in russian/greek analysis
[ https://issues.apache.org/jira/browse/SOLR-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752868#action_12752868 ] Robert Muir commented on SOLR-1410: --- are there any issues with this... care if i set version 1.4? really hoping to remove these pseudo-charsets after the lucene 2.9 release :) > remove deprecated custom encoding support in russian/greek analysis > --- > > Key: SOLR-1410 > URL: https://issues.apache.org/jira/browse/SOLR-1410 > Project: Solr > Issue Type: Task > Components: Analysis >Reporter: Robert Muir >Priority: Minor > Attachments: SOLR-1410.patch > > > In this case, analyzers have strange encoding support and it has been > deprecated in lucene. > For example someone using CP1251 in the russian analyzer is simply storing Ж > as 0xC6, its being represented as Æ > LUCENE-1793: Deprecate the custom encoding support in the Greek and Russian > Analyzers. If you need to index text in these encodings, please use Java's > character set conversion facilities (InputStreamReader, etc) during I/O, > so that Lucene can analyze this text as Unicode instead. > I noticed in solr, the factories for these tokenstreams allow these > configuration options, which are deprecated in 2.9 to be removed in 3.0 > Let me know the policy (how do you deprecate a config option in solr exactly, > log a warning, etc?) and I'd be happy to create a patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr development with IntelliJIDEA - looking for advice
: However, a section in the source tree with ready-made configuration files : for each IDE would be handy. this was discussed once upon a time ... the problem is that while it's easy for committers to accept contributions from users for config files for their favorite IDEs, making sure the config files are kept up to date is infeasible (both in terms of IDEs changing over time, and solr changing over time) and having those files in the source tree could imply that they werre endorsed or maintained. a decision was made that it would be better to just have contributors share configuration tips/examples via the wiki... http://wiki.apache.org/solr/HowToContribute#head-71ebe6163d8fffbd0cbd6261edcae2bb0e138798 : : On Tue, Sep 8, 2009 at 4:18 PM, Chris Hostetter wrote: : : > : > : is IntelliJIDEA is a free java IDE? Why can not use Eclipse, which is : > perhaps more popular and free? : > : > please, no holy wars about editors/IDEs on the list. : > : > Asking for help configuring a particular IDE to work with solr is on : > topic; interogating someone about why they use IDE X instead of Y is not. : > If you don't approave of someones choice of IDE, just ignore the message. : > : > (likewise for servlet containers) : > : > -Hoss : > : > : : : -- : Lance Norskog : goks...@gmail.com : -Hoss
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
On Tue, Sep 8, 2009 at 7:46 PM, Chris Hostetter wrote: > The modifiedUTF8 boolean only influence the numeric length returned as the > "s" option ... the actaully "val" string is still written "as is" by the > servlet container. Yep. A code point (unicode character) outside of the BMP (basic multilingual plane, fits in 16 bits) is represented as two java chars - a surrogate pair. It's a single logical character - see String.codePointAt(). In correct UTF-8 it should be encoded as a single code point... but Jetty is ignoring the fact that it's a surrogate pair and encoding each Java char as it's own code point... this is often called modified-UTF8 or CESU-8. So... say you have this incorrect CESU-8 that is masquerading as UTF-8: all is not lost. - A decoder can unambiguously recognize that the characters decoded actually form a surrogate pair and correctly decode - but I don't know if there are aby requirements to do so (doubt it), and I don't know which do so. - A decoder decoding into UTF-16 (like Java Strings) will correctly decode anyway, even if treating each code point in the pair as separate. PHP5 doesn't even do unicode, so it won't care. PHP6 apparently has unicode support - don't know much about it. Bottom line - if we correctly encapsulate whatever the servlet container is writing, it's certainly possible for clients to use the output correctly. > you've also changed the behavior so that even when > false==modifiedUTF8, the length is now computed differently then before > the patch (using UnicodeUtil.UTF16toUTF8) ... it's this second change i > don't understand based on the context of the bug: why does the length > value need to be computed differnetly for non-jetty implemntations? It will be the same length for non-jetty implementations - I just rewrote the entire method and used the Lucene UTF16toUTF8 for performance reasons. (bad developer, bad!) -Yonik http://www.lucidimagination.com
[jira] Commented: (SOLR-1071) spellcheck.extendedResults returns an invalid JSON response when count > 1
[
https://issues.apache.org/jira/browse/SOLR-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752841#action_12752841
]
Uri Boness commented on SOLR-1071:
--
cool! thanks for the effort Yonik. I've updated the wiki so you can focus on
the release ;-)
> spellcheck.extendedResults returns an invalid JSON response when count > 1
> --
>
> Key: SOLR-1071
> URL: https://issues.apache.org/jira/browse/SOLR-1071
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 1.3
>Reporter: Uri Boness
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1071.patch, SpellCheckComponent_fix.patch,
> SpellCheckComponent_new_structure.patch,
> SpellCheckComponent_new_structure_incl_test.patch
>
>
> When: wt=json & spellcheck.extendedResults=true & spellcheck.count > 1, the
> suggestions are returned in the following format:
> "suggestions":[
> "amsterdm",{
>"numFound":5,
>"startOffset":0,
>"endOffset":8,
>"origFreq":0,
>"suggestion":{
> "frequency":8498,
> "word":"amsterdam"},
>"suggestion":{
> "frequency":1,
> "word":"amsterd"},
>"suggestion":{
> "frequency":8,
> "word":"amsterdams"},
>"suggestion":{
> "frequency":1,
> "word":"amstedam"},
>"suggestion":{
> "frequency":22,
> "word":"amsterdamse"}},
> "beak",{
>"numFound":5,
>"startOffset":9,
>"endOffset":13,
>"origFreq":0,
>"suggestion":{
> "frequency":379,
> "word":"beek"},
>"suggestion":{
> "frequency":26,
> "word":"beau"},
>"suggestion":{
> "frequency":26,
> "word":"baak"},
>"suggestion":{
> "frequency":15,
> "word":"teak"},
>"suggestion":{
> "frequency":11,
> "word":"beuk"}},
> "correctlySpelled",false,
> "collation","amsterdam beek"]}}
> This is an invalid json as each term is associated with a JSON object which
> holds multiple "suggestion" attributes. When working with a JSON library only
> the last "suggestion" attribute is picked up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Lucene RC2
Depends on if changes supports trunk or releases I guess. I think it's dangerous to start down that line with trunk myself. It's one of the caveats trunk users endure - I don't consider them when I make changes in a dev cycle. It's the same way I'm not leaving deprecated methods for them. We have enough responsibilty with back compatible than to give trunk any priority over released versions IMO. A classic change file lists release changes - personally I think it's awkward to buck that convention and expose the dev history of a feature in a release changes. - Mark http://www.lucidimagination.com (mobile) On Sep 8, 2009, at 8:05 PM, Chris Hostetter wrote: : Thats how we have been attempting to handle it in Lucene - : update the previous issue with credits and merge the change : info. There are tricky situations - someone can get credit for : a huge issue when they just found a minor bug much later - : but that seems to fit in line with our generous credit model : anyway - if you really want to know, go to the JIRA issues. If : the same person found the bug and posted a patch before it : went in, they would be on the credit line anyway. If they find : it after release, they get a new bug fix credit. ... "eh" If a big feature is added, and then someone fins/fixes a small bug with it later, i dont' see anything wrong with having two enteries in the CHANGEs about this ... likewise if a feature is added and then a a bunch of extensions are made to it ... at a certain point if you keep collapsing things just because they are related you wind up with one long paragraph about how "lucene" changed between releases instead of a nice bulleted list. the big key i think is not having things that contradict ... if a bullet says we added XY&Z, but then a latter bullet says Z was removed and replaced with Q, we should just remove Z from the first bullet ... but that doesn't neccessarily mean Q needs to replace Z in that bullet .. Q can still be it's own bullet. -Hoss
Re: Solr development with IntelliJIDEA - looking for advice
Indeed! However, a section in the source tree with ready-made configuration files for each IDE would be handy. On Tue, Sep 8, 2009 at 4:18 PM, Chris Hostetter wrote: > > : is IntelliJIDEA is a free java IDE? Why can not use Eclipse, which is > perhaps more popular and free? > > please, no holy wars about editors/IDEs on the list. > > Asking for help configuring a particular IDE to work with solr is on > topic; interogating someone about why they use IDE X instead of Y is not. > If you don't approave of someones choice of IDE, just ignore the message. > > (likewise for servlet containers) > > -Hoss > > -- Lance Norskog goks...@gmail.com
Re: Lucene RC2
: Thats how we have been attempting to handle it in Lucene - : update the previous issue with credits and merge the change : info. There are tricky situations - someone can get credit for : a huge issue when they just found a minor bug much later - : but that seems to fit in line with our generous credit model : anyway - if you really want to know, go to the JIRA issues. If : the same person found the bug and posted a patch before it : went in, they would be on the credit line anyway. If they find : it after release, they get a new bug fix credit. ... "eh" If a big feature is added, and then someone fins/fixes a small bug with it later, i dont' see anything wrong with having two enteries in the CHANGEs about this ... likewise if a feature is added and then a a bunch of extensions are made to it ... at a certain point if you keep collapsing things just because they are related you wind up with one long paragraph about how "lucene" changed between releases instead of a nice bulleted list. the big key i think is not having things that contradict ... if a bullet says we added XY&Z, but then a latter bullet says Z was removed and replaced with Q, we should just remove Z from the first bullet ... but that doesn't neccessarily mean Q needs to replace Z in that bullet .. Q can still be it's own bullet. -Hoss
Re: svn commit: r808988 - in /lucene/solr/trunk: CHANGES.txt src/java/org/apache/solr/request/PHPSerializedResponseWriter.java
: > : + static boolean modifiedUTF8 = System.getProperty("jetty.home") != null;
: >
: > ...that seems really hackish to me, particularly since for all we know
: > there are other servlet containers that might have the same problem.
:
: Yeah, it is.
: But it's not really a valid option, it's a bug/limitation in the
: servlet container IMO. It would also suck to bloat configuration (and
: users brains) with options that don't really control anything, except
: that they must correctly match it up with how their servlet container
: behaves. And this doesn't actually fix everything - it simply makes
: it such that encapsulation at the transport layer isn't broken - the
: end user will still be getting back incorrect UTF8.
my suggestion for adding an explicit option for the modifiedUTF8 behavior
to the phps response writer was on the (miss)understanding that the value
was always correct, it was just the length calculation that was being done
wrong by jetty (and correct by other implementations) so if we noticed we
were running in jetty we'd replace the length calculation with our own
(which might be less efficient).
but i guess i don't really understand the patch ... actually, the more i
look at it the less i understand it
The modifiedUTF8 boolean only influence the numeric length returned as the
"s" option ... the actaully "val" string is still written "as is" by the
servlet container. you've also changed the behavior so that even when
false==modifiedUTF8, the length is now computed differently then before
the patch (using UnicodeUtil.UTF16toUTF8) ... it's this second change i
don't understand based on the context of the bug: why does the length
value need to be computed differnetly for non-jetty implemntations?
: containers hands and do it all ourselves. Or just don't support any
: servlet containers that can't handle code points outside the BMP? Or
I'm in favor of this approach .. if the container can't correctly output
some characters, i see no reason to hide the bug -- if somebody else wants
to code arround the bug by doing it all in solr that's fine, but untill
then i don't see an advantage in outputing the correct number of bytes for
a garbage string -- anybody who really cares is going to need to switch to
a differnet servlet container anyway.
: is there simply a Jetty config option we've been missing. It's hard
: to believe that such a popular servlet container can't handle this.
hey, i don't even understand the bug enough to know what to search for to
try and find an option.
-Hoss
Re: Lucene RC2
> but that "update" doesn't need to be purely additive, it can be an >"edit" of an existing item in which case diffing the two versions of >CHANGES.txt will still tell you what you need to know. Thats how we have been attempting to handle it in Lucene - update the previous issue with credits and merge the change info. There are tricky situations - someone can get credit for a huge issue when they just found a minor bug much later - but that seems to fit in line with our generous credit model anyway - if you really want to know, go to the JIRA issues. If the same person found the bug and posted a patch before it went in, they would be on the credit line anyway. If they find it after release, they get a new bug fix credit. We could also just merge down at the end as part of release. Or kind of run the middle ground, or do nothing. First option makes the most sense to me though. - Mark Chris Hostetter wrote: > : think thats important. It just seems the Changes log should read what > : changed from 1.3 or else its a little confusing. You could make another > : argument with so many on trunk - but in my mind, the only thing those > : going from 1.3 to 1.4 should need to worry about is upgraded to 2.9 - > : not follow the whole dev path as changes invalidate changes. Not a big > > it's equally important that people experimenting with trunk/nightlys have > an easy way to distibguish what's changed between the version their using > and the current version, so CHANGES.txt should be updated for every change > -- but that "update" doesn't need to be purely additive, it can be an > "edit" of an existing item in which case diffing the two versions of > CHANGES.txt will still tell you what you need to know. > > > > -Hoss > > -- - Mark http://www.lucidimagination.com
Re: Solr development with IntelliJIDEA - looking for advice
: is IntelliJIDEA is a free java IDE? Why can not use Eclipse, which is perhaps more popular and free? please, no holy wars about editors/IDEs on the list. Asking for help configuring a particular IDE to work with solr is on topic; interogating someone about why they use IDE X instead of Y is not. If you don't approave of someones choice of IDE, just ignore the message. (likewise for servlet containers) -Hoss
Re: Lucene RC2
: think thats important. It just seems the Changes log should read what : changed from 1.3 or else its a little confusing. You could make another : argument with so many on trunk - but in my mind, the only thing those : going from 1.3 to 1.4 should need to worry about is upgraded to 2.9 - : not follow the whole dev path as changes invalidate changes. Not a big it's equally important that people experimenting with trunk/nightlys have an easy way to distibguish what's changed between the version their using and the current version, so CHANGES.txt should be updated for every change -- but that "update" doesn't need to be purely additive, it can be an "edit" of an existing item in which case diffing the two versions of CHANGES.txt will still tell you what you need to know. -Hoss
[jira] Resolved: (SOLR-1071) spellcheck.extendedResults returns an invalid JSON response when count > 1
[
https://issues.apache.org/jira/browse/SOLR-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley resolved SOLR-1071.
Resolution: Fixed
> spellcheck.extendedResults returns an invalid JSON response when count > 1
> --
>
> Key: SOLR-1071
> URL: https://issues.apache.org/jira/browse/SOLR-1071
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 1.3
>Reporter: Uri Boness
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1071.patch, SpellCheckComponent_fix.patch,
> SpellCheckComponent_new_structure.patch,
> SpellCheckComponent_new_structure_incl_test.patch
>
>
> When: wt=json & spellcheck.extendedResults=true & spellcheck.count > 1, the
> suggestions are returned in the following format:
> "suggestions":[
> "amsterdm",{
>"numFound":5,
>"startOffset":0,
>"endOffset":8,
>"origFreq":0,
>"suggestion":{
> "frequency":8498,
> "word":"amsterdam"},
>"suggestion":{
> "frequency":1,
> "word":"amsterd"},
>"suggestion":{
> "frequency":8,
> "word":"amsterdams"},
>"suggestion":{
> "frequency":1,
> "word":"amstedam"},
>"suggestion":{
> "frequency":22,
> "word":"amsterdamse"}},
> "beak",{
>"numFound":5,
>"startOffset":9,
>"endOffset":13,
>"origFreq":0,
>"suggestion":{
> "frequency":379,
> "word":"beek"},
>"suggestion":{
> "frequency":26,
> "word":"beau"},
>"suggestion":{
> "frequency":26,
> "word":"baak"},
>"suggestion":{
> "frequency":15,
> "word":"teak"},
>"suggestion":{
> "frequency":11,
> "word":"beuk"}},
> "correctlySpelled",false,
> "collation","amsterdam beek"]}}
> This is an invalid json as each term is associated with a JSON object which
> holds multiple "suggestion" attributes. When working with a JSON library only
> the last "suggestion" attribute is picked up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1071) spellcheck.extendedResults returns an invalid JSON response when count > 1
[
https://issues.apache.org/jira/browse/SOLR-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752793#action_12752793
]
Yonik Seeley commented on SOLR-1071:
Committed! The Solr release schedule is tight enough, I'll update the wiki
docs during the Solr code freeze (unless someone beats me to it).
> spellcheck.extendedResults returns an invalid JSON response when count > 1
> --
>
> Key: SOLR-1071
> URL: https://issues.apache.org/jira/browse/SOLR-1071
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 1.3
>Reporter: Uri Boness
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1071.patch, SpellCheckComponent_fix.patch,
> SpellCheckComponent_new_structure.patch,
> SpellCheckComponent_new_structure_incl_test.patch
>
>
> When: wt=json & spellcheck.extendedResults=true & spellcheck.count > 1, the
> suggestions are returned in the following format:
> "suggestions":[
> "amsterdm",{
>"numFound":5,
>"startOffset":0,
>"endOffset":8,
>"origFreq":0,
>"suggestion":{
> "frequency":8498,
> "word":"amsterdam"},
>"suggestion":{
> "frequency":1,
> "word":"amsterd"},
>"suggestion":{
> "frequency":8,
> "word":"amsterdams"},
>"suggestion":{
> "frequency":1,
> "word":"amstedam"},
>"suggestion":{
> "frequency":22,
> "word":"amsterdamse"}},
> "beak",{
>"numFound":5,
>"startOffset":9,
>"endOffset":13,
>"origFreq":0,
>"suggestion":{
> "frequency":379,
> "word":"beek"},
>"suggestion":{
> "frequency":26,
> "word":"beau"},
>"suggestion":{
> "frequency":26,
> "word":"baak"},
>"suggestion":{
> "frequency":15,
> "word":"teak"},
>"suggestion":{
> "frequency":11,
> "word":"beuk"}},
> "correctlySpelled",false,
> "collation","amsterdam beek"]}}
> This is an invalid json as each term is associated with a JSON object which
> holds multiple "suggestion" attributes. When working with a JSON library only
> the last "suggestion" attribute is picked up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Indexing MySQL db using script
This question should be directed to the solr-user mailing list. However, look at this wiki page: http://wiki.apache.org/solr/DataImportHandler Eric On Sep 8, 2009, at 5:15 PM, kedardes wrote: Hi, I'm trying to find a way to index an external MySQL db so that searches made against the solr engine will bring back results from that db. I already have a script to index a different CMS db (non open source) and have noticed the Data Import Handler mentioned in these forums. Is there a simple example of the steps required to set this up? Thanks. -- View this message in context: http://www.nabble.com/Indexing-MySQL-db-using-script-tp25354356p25354356.html Sent from the Solr - Dev mailing list archive at Nabble.com. - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Co-Author: Solr 1.4 Enterprise Search Server available from http://www.packtpub.com/solr-1-4-enterprise-search-server Free/Busy: http://tinyurl.com/eric-cal
Indexing MySQL db using script
Hi, I'm trying to find a way to index an external MySQL db so that searches made against the solr engine will bring back results from that db. I already have a script to index a different CMS db (non open source) and have noticed the Data Import Handler mentioned in these forums. Is there a simple example of the steps required to set this up? Thanks. -- View this message in context: http://www.nabble.com/Indexing-MySQL-db-using-script-tp25354356p25354356.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: replace numbers with bullets in CHANGES
: Just one of those things we inherited from Lucene, but it does seem to : make sense to just use a bullet (*) instead of numbering. : I don't see any reason to change the current CHANGES for 1.4, but : perhaps going forward after that? oh, *HELL* yes ... why didn't we ever think of this before? -Hoss
[jira] Issue Comment Edited: (SOLR-1300) need to exlcude downloaded clustering libs from release packages
[
https://issues.apache.org/jira/browse/SOLR-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752729#action_12752729
]
Grant Ingersoll edited comment on SOLR-1300 at 9/8/09 1:42 PM:
---
Hmm, part of the problem, I think, lies in:
{noformat}
{noformat}
Where we blindly include all of contrib. Still looking...
was (Author: gsingers):
Hmm, part of the problem, I think, lies in:
{quote}
{quote}
Where we blindly include all of contrib. Still looking...
> need to exlcude downloaded clustering libs from release packages
>
>
> Key: SOLR-1300
> URL: https://issues.apache.org/jira/browse/SOLR-1300
> Project: Solr
> Issue Type: Task
>Reporter: Hoss Man
>Assignee: Grant Ingersoll
> Fix For: 1.4
>
>
> As noted by grant...
> http://www.nabble.com/Re%3A-cleaning-up-example-p24469638.html
> the build file for the clustering contrib downloads some optional jars that
> can't be included in the release. Yonik/Hoss simplified the build files, but
> as a side effect *all* libs are included in the dist (even the ones that
> shouldn't be)
> we need to exclude them (one way or another) before we release 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1300) need to exlcude downloaded clustering libs from release packages
[
https://issues.apache.org/jira/browse/SOLR-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752729#action_12752729
]
Grant Ingersoll commented on SOLR-1300:
---
Hmm, part of the problem, I think, lies in:
{quote}
{quote}
Where we blindly include all of contrib. Still looking...
> need to exlcude downloaded clustering libs from release packages
>
>
> Key: SOLR-1300
> URL: https://issues.apache.org/jira/browse/SOLR-1300
> Project: Solr
> Issue Type: Task
>Reporter: Hoss Man
>Assignee: Grant Ingersoll
> Fix For: 1.4
>
>
> As noted by grant...
> http://www.nabble.com/Re%3A-cleaning-up-example-p24469638.html
> the build file for the clustering contrib downloads some optional jars that
> can't be included in the release. Yonik/Hoss simplified the build files, but
> as a side effect *all* libs are included in the dist (even the ones that
> shouldn't be)
> we need to exclude them (one way or another) before we release 1.4.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1300) need to exlcude downloaded clustering libs from release packages
[ https://issues.apache.org/jira/browse/SOLR-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned SOLR-1300: - Assignee: Grant Ingersoll > need to exlcude downloaded clustering libs from release packages > > > Key: SOLR-1300 > URL: https://issues.apache.org/jira/browse/SOLR-1300 > Project: Solr > Issue Type: Task >Reporter: Hoss Man >Assignee: Grant Ingersoll > Fix For: 1.4 > > > As noted by grant... > http://www.nabble.com/Re%3A-cleaning-up-example-p24469638.html > the build file for the clustering contrib downloads some optional jars that > can't be included in the release. Yonik/Hoss simplified the build files, but > as a side effect *all* libs are included in the dist (even the ones that > shouldn't be) > we need to exclude them (one way or another) before we release 1.4. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1407) SpellingQueryConverter now disallows underscores and digits in field names (but allows all UTF-8 letters)
[ https://issues.apache.org/jira/browse/SOLR-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752697#action_12752697 ] Grant Ingersoll commented on SOLR-1407: --- Does anyone have a patch for this? > SpellingQueryConverter now disallows underscores and digits in field names > (but allows all UTF-8 letters) > - > > Key: SOLR-1407 > URL: https://issues.apache.org/jira/browse/SOLR-1407 > Project: Solr > Issue Type: Improvement > Components: spellchecker >Affects Versions: 1.3 >Reporter: David Bowen >Assignee: Shalin Shekhar Mangar >Priority: Trivial > Fix For: 1.4 > > Attachments: SpellingQueryConverter.java, SpellingQueryConverter.java > > > SpellingQueryConverter was extended to cover the full UTF-8 range instead of > handling US-ASCII only, but in the process it was broken for field names that > contain underscores or digits. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1275) Add expungeDeletes to DirectUpdateHandler2
[ https://issues.apache.org/jira/browse/SOLR-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752696#action_12752696 ] Grant Ingersoll commented on SOLR-1275: --- What's the status on this one? > Add expungeDeletes to DirectUpdateHandler2 > -- > > Key: SOLR-1275 > URL: https://issues.apache.org/jira/browse/SOLR-1275 > Project: Solr > Issue Type: Improvement > Components: update >Affects Versions: 1.3 >Reporter: Jason Rutherglen >Assignee: Noble Paul >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1275.patch, SOLR-1275.patch, SOLR-1275.patch, > SOLR-1275.patch, SOLR-1275.patch, SOLR-1275.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > expungeDeletes is a useful method somewhat like optimize is offered by > IndexWriter that can be implemented in DirectUpdateHandler2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1411) SolrJ SolrCell Request
[ https://issues.apache.org/jira/browse/SOLR-1411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll updated SOLR-1411: -- Attachment: SOLR-1411.patch Some refactoring of UpdateRequest to share common code with SolrCellRequest. > SolrJ SolrCell Request > -- > > Key: SOLR-1411 > URL: https://issues.apache.org/jira/browse/SOLR-1411 > Project: Solr > Issue Type: Improvement >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-1411.patch, SOLR-1411.patch > > > Create a SolrRequest for SolrJ that can add Solr Cell documents (PDF, Word, > etc.) to Solr for indexing. > Patch shortly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1380) Extend StatsComponent to MultiValued Fields
[ https://issues.apache.org/jira/browse/SOLR-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752638#action_12752638 ] Harish Agarwal commented on SOLR-1380: -- Grant - thanks for looking it over. Let me know if I can help with incorporating it into the trunk (don't have commit access, but if issues come up, I can help debug). I def. agree that the near copy/paste is not a great solution. In my opinion, the Stats and Facet components should be integrated, this would provide an easy way to remove that and other redundancies, as well as allow for added functionality. What do you think? > Extend StatsComponent to MultiValued Fields > --- > > Key: SOLR-1380 > URL: https://issues.apache.org/jira/browse/SOLR-1380 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: Harish Agarwal >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1380.patch, SOLR-1380.patch, SOLR-1380.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > The StatsComponent does not work on multivalued fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-868) Prepare solrjs trunk to be integrated into contrib
[ https://issues.apache.org/jira/browse/SOLR-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752634#action_12752634 ] Grant Ingersoll commented on SOLR-868: -- I'm going to pull the Reuters demo for the release. > Prepare solrjs trunk to be integrated into contrib > -- > > Key: SOLR-868 > URL: https://issues.apache.org/jira/browse/SOLR-868 > Project: Solr > Issue Type: Task >Affects Versions: 1.4 >Reporter: Matthias Epheser >Assignee: Ryan McKinley > Fix For: 1.4 > > Attachments: javascript_contrib.zip, reutersimporter.jar, > SOLR-868-testdata.patch, solrjs.zip > > > This patch includes a zipfile snapshot of current solrjs trunk. The folder > structure is applied to standard solr layout. It can be extracted to > "contrib/javascript". > it includes a build.xml: > * ant dist -> creates a single js file and a jar that holds velocity > templates. > * ant docs -> creates js docs. test in browser: doc/index.html > * ant example-init -> (depends ant dist on solr root) copies the current > built of solr.war and solr-velocity.jar to example/testsolr/.. > * ant example-start -> starts the testsolr server on port 8983 > * ant example-import -> imports 3000 test data rows (requires a started > testserver) > Point your browser to example/testClientside.html > ,example/testServerSide.html or test/reuters/index.html to see it working. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-868) Prepare solrjs trunk to be integrated into contrib
[ https://issues.apache.org/jira/browse/SOLR-868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned SOLR-868: Assignee: Grant Ingersoll (was: Ryan McKinley) > Prepare solrjs trunk to be integrated into contrib > -- > > Key: SOLR-868 > URL: https://issues.apache.org/jira/browse/SOLR-868 > Project: Solr > Issue Type: Task >Affects Versions: 1.4 >Reporter: Matthias Epheser >Assignee: Grant Ingersoll > Fix For: 1.4 > > Attachments: javascript_contrib.zip, reutersimporter.jar, > SOLR-868-testdata.patch, solrjs.zip > > > This patch includes a zipfile snapshot of current solrjs trunk. The folder > structure is applied to standard solr layout. It can be extracted to > "contrib/javascript". > it includes a build.xml: > * ant dist -> creates a single js file and a jar that holds velocity > templates. > * ant docs -> creates js docs. test in browser: doc/index.html > * ant example-init -> (depends ant dist on solr root) copies the current > built of solr.war and solr-velocity.jar to example/testsolr/.. > * ant example-start -> starts the testsolr server on port 8983 > * ant example-import -> imports 3000 test data rows (requires a started > testserver) > Point your browser to example/testClientside.html > ,example/testServerSide.html or test/reuters/index.html to see it working. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1380) Extend StatsComponent to MultiValued Fields
[ https://issues.apache.org/jira/browse/SOLR-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752629#action_12752629 ] Grant Ingersoll commented on SOLR-1380: --- This looks pretty good in a first pass. I think it can go in. Not totally thrilled about the UninvertedField near copy/paste, but don't see a good alternative at the moment. > Extend StatsComponent to MultiValued Fields > --- > > Key: SOLR-1380 > URL: https://issues.apache.org/jira/browse/SOLR-1380 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: Harish Agarwal >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1380.patch, SOLR-1380.patch, SOLR-1380.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > The StatsComponent does not work on multivalued fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: solr 1.4 release schedule
I can be RM unless someone else is dying to do it. On Sep 8, 2009, at 11:06 AM, Yonik Seeley wrote: My day-job colleagues and I are all traveling this week (company get-together) so that may slow things down a bit for some of us, and perhaps cause the goal of releasing Solr 1 week after Lucene to slip a little. Still, if there are any issues that are assigned to you, and that you can't get to this week (including the weekend) please un-assign yourself as a signal that someone else should try and take it up. [moving release discussion to solr-dev] OK... how about going into code freeze by the end of the week? Again, if you have an issue that you won't get to, please un-assign yourself. -Yonik http://www.lucidimagination.com
solr 1.4 release schedule
> My day-job colleagues and I are all traveling this week (company > get-together) so that may slow things down a bit for some of us, and > perhaps cause the goal of releasing Solr 1 week after Lucene to slip a > little. Still, if there are any issues that are assigned to you, and > that you can't get to this week (including the weekend) please > un-assign yourself as a signal that someone else should try and take > it up. [moving release discussion to solr-dev] OK... how about going into code freeze by the end of the week? Again, if you have an issue that you won't get to, please un-assign yourself. -Yonik http://www.lucidimagination.com
getTextContent() caused my local solr build failed
All the follwing ".getTextContent()" failed , which caused my local solr build
failed, althogh it is just sync-ed with the SVN build.
list.add(nodeList.item(i).getTextContent());
assertEquals("prefix-proptwo-suffix", nl.item(0).getTextContent());
Node node = solrConfig.getNode("propTest", true);
assertEquals("prefix-proptwo-suffix", node.getTextContent());
Any hints on how to solve it are highly appreciated.
Thanks.
2009-09-08
Yue ZHANG
- Beijing
[jira] Assigned: (SOLR-1380) Extend StatsComponent to MultiValued Fields
[ https://issues.apache.org/jira/browse/SOLR-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll reassigned SOLR-1380: - Assignee: Grant Ingersoll > Extend StatsComponent to MultiValued Fields > --- > > Key: SOLR-1380 > URL: https://issues.apache.org/jira/browse/SOLR-1380 > Project: Solr > Issue Type: Improvement > Components: search >Affects Versions: 1.4 >Reporter: Harish Agarwal >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1380.patch, SOLR-1380.patch, SOLR-1380.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > The StatsComponent does not work on multivalued fields. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1379) Add RAMDirectoryFactory
[
https://issues.apache.org/jira/browse/SOLR-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll updated SOLR-1379:
--
Fix Version/s: (was: 1.4)
1.5
> Add RAMDirectoryFactory
> ---
>
> Key: SOLR-1379
> URL: https://issues.apache.org/jira/browse/SOLR-1379
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Alex Baranov
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1379.patch, SOLR-1379.patch
>
>
> Implement class RAMDirectoryFactory to make possible using RAMDirectory by
> adding the next configuration in solrconfig.xml:
> {code} class="org.apache.solr.core.RAMDirectoryFactory"/>{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-1379) Add RAMDirectoryFactory
[
https://issues.apache.org/jira/browse/SOLR-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752543#action_12752543
]
Grant Ingersoll commented on SOLR-1379:
---
{quote}
The scenario with loading index into the RAM from the disk can be determined by
the the combination of all of the next requirements:
* Index is updated not through the Solr
* Index is very large (more than 100mil documents, containing more than 50
fields)
* Index updates affect about half of the documents each month.
* Search should be performed extremely fast
Since updates touch a lot of documents this can affect the user while OS
caches are renewed (according to our tests this can result in a lag of 5+
minutes while commit is happening). Also we need to optimize the index after
such huge updates which is also causes all caches to be recreated, etc. To
avoid the lag we can load the index into a RAM and reload it on a scheduled
basis using core reload feature (new index is used only after it is warmed up,
etc.).
In addition to that, the test results for RAMDirectory and FSDirectory are
different if the user load is significant (e.g. 30+ concurrent requests):
RAMDirectory is faster. Even when we used mounted RAM disk as a storage for
index and used FSDirectory this performed 2.5-3 times worse than RAMDirectory.
{quote}
Can you share your performance tests? Also, not sure why a very large index is
a use case _for_ RAMDirectory implementation.
Finally, storing the Directories in a Map doesn't seem like a good idea.
I think we should mark this for 1.5, so it can be revisited then.
> Add RAMDirectoryFactory
> ---
>
> Key: SOLR-1379
> URL: https://issues.apache.org/jira/browse/SOLR-1379
> Project: Solr
> Issue Type: New Feature
>Affects Versions: 1.3
>Reporter: Alex Baranov
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1379.patch, SOLR-1379.patch
>
>
> Implement class RAMDirectoryFactory to make possible using RAMDirectory by
> adding the next configuration in solrconfig.xml:
> {code} class="org.apache.solr.core.RAMDirectoryFactory"/>{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-1330) the details command shows current replication status when no replication is going on
[ https://issues.apache.org/jira/browse/SOLR-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akshay K. Ukey updated SOLR-1330: - Attachment: SOLR-1330.patch Patch in sync with trunk. > the details command shows current replication status when no replication is > going on > > > Key: SOLR-1330 > URL: https://issues.apache.org/jira/browse/SOLR-1330 > Project: Solr > Issue Type: Bug > Components: replication (java) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1330.patch, SOLR-1330.patch, SOLR-1330.patch, > SOLR-1330.patch, SOLR-1330.patch, SOLR-1330.patch, SOLR-1330.patch > > > The details of current replication should be shown only when a replication is > going on. It would also be useful if the history of past replications are > also captured -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr development with IntelliJIDEA - looking for advice
I am trying to learn IDEA, I have been using it for few weeks and I really it.Try asking some of core solr developer which are using IDEA why did they choose it. Regards, Lukas On Tue, Sep 8, 2009 at 2:35 AM, Pradeep Pujari wrote: > is IntelliJIDEA is a free java IDE? Why can not use Eclipse, which is > perhaps more popular and free? > > Thanks, > Pradeep. > > --- On Mon, 9/7/09, Lukáš Vlček wrote: > > > From: Lukáš Vlček > > Subject: Re: Solr development with IntelliJIDEA - looking for advice > > To: solr-dev@lucene.apache.org > > Date: Monday, September 7, 2009, 2:05 AM > > Cool, I figured out the the error for > > example 1:It was on the IntelliJ IDEA > > side. It is necessay to allow *.txt in resource patterns > > (File -> Settings > > [also Ctrl + Alt + S]) > > > > Rgds, > > Lukas > > > > On Sat, Sep 5, 2009 at 10:23 PM, Lukáš Vlček > > wrote: > > > > > Hi, > > > First of all, thanks for all your comments. I am > > trying to set-up just > > > "solr-core" for now. > > > > > > What I mean by this is that I ended up with one > > project having two modules > > > (speaking about IntelliJ IDEA project and modules): > > > > > > Module 1: > > > Solr-trunk (this is what I > > consider to be a "solr-core") > > > path: > > C:\projects\asf\solr-trunk\src > > > > > > source folders: > > > - common > > > - java > > > - solrj > > > - > > test\test-files\solr\conf...[!] > > > > > > test source folders: > > > - test > > > - > > test\test-files > > > > > > Module 2: > > > Webapp (It is necessary to > > setup Webapp module as the Solr-trunk needs > > > it as a dependency - but in fact it seems to be needed > > just by tests) > > > path: > > C:\projects\asf\solr-trunk\src\webapp > > > > > > source fodlers: > > > - src > > > > > > > > > Now... > > > Many individual tests work with this configuration but > > not all. > > > Example 1) > > > TestQuerySenderListener > > > > > > java.lang.RuntimeException: Can't find resource > > 'stopwords.txt' in > > > classpath or 'solr/conf/', > > cwd=C:\projects\asf\solr-trunk > > > at > > > > > > org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:197) > > > at > > > > > > org.apache.solr.core.SolrResourceLoader.getLines(SolrResourceLoader.java:242) > > > at > > > > > > org.apache.solr.core.SolrResourceLoader.getLines(SolrResourceLoader.java:216) > > > at > > > > > > org.apache.solr.analysis.StopFilterFactory.inform(StopFilterFactory.java:53) > > > at > > > > > > org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:426) > > > at > > org.apache.solr.schema.IndexSchema.(IndexSchema.java:102) > > > at > > org.apache.solr.util.TestHarness.(TestHarness.java:124) > > > at > > > > > > org.apache.solr.util.AbstractSolrTestCase.setUp(AbstractSolrTestCase.java:105) > > > at > > com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) > > > at > > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > at > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > > at > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > > at > > com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) > > > > > > I don't know why it does not locate stopwords.txt file > > while its fodler is > > > in source folders list (see [!] above). > > > > > > Example 2) > > > TestSpellCheckResponse > > > > > > java.lang.RuntimeException: > > java.lang.RuntimeException: Can't find resource > > > '../../../example/solr/conf/solrconfig.xml' in > > classpath or 'solr/conf/', > > > cwd=C:\projects\asf\solr-trunk > > > at > > org.apache.solr.util.TestHarness.createConfig(TestHarness.java:85) > > > at > > > > > > org.apache.solr.util.AbstractSolrTestCase.setUp(AbstractSolrTestCase.java:104) > > > at > > > > > > org.apache.solr.client.solrj.SolrExampleTestBase.setUp(SolrExampleTestBase.java:41) > > > at > > > > > > org.apache.solr.client.solrj.response.TestSpellCheckResponse.setUp(TestSpellCheckResponse.java:47) > > > at > > > > > com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > > at > > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > > at > > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > > at > > com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) > > > Caused by: java.lang.RuntimeException: Can't find > > resource > > > '../../../example/solr/conf/solrconfig.xml' in > > classpath or 'solr/conf/', > > > cwd=C:\projects\asf\solr-trunk > > > at > > > > > > org.apache.solr.core.SolrResourceLoader.openResource(SolrResourceLoader.java:197) > > > at > > > > > > org.apache.solr.core.SolrResourceLoader.openConfig(SolrResourceLoader.java:165) > > > at > > org.apache.solr
[jira] Resolved: (SOLR-1400) Document with empty or white-space only string causes exception with TrimFilter
[
https://issues.apache.org/jira/browse/SOLR-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Ingersoll resolved SOLR-1400.
---
Resolution: Fixed
Committed revision 812494.
> Document with empty or white-space only string causes exception with
> TrimFilter
> ---
>
> Key: SOLR-1400
> URL: https://issues.apache.org/jira/browse/SOLR-1400
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 1.4
>Reporter: Peter Wolanin
>Assignee: Grant Ingersoll
> Fix For: 1.4
>
> Attachments: SOLR-1400.patch, trim-example.xml
>
>
> Observed with Solr trunk. Posting any empty or whitespace-only string to a
> field using the {code}{code}
> Causes a java exception:
> {code}
> Sep 1, 2009 4:58:09 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.solr.analysis.TrimFilter.incrementToken(TrimFilter.java:63)
> at
> org.apache.solr.analysis.PatternReplaceFilter.incrementToken(PatternReplaceFilter.java:74)
> at
> org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:138)
> at
> org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:244)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:772)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:755)
> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2611)
> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2583)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:241)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61)
> at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:140)
> at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:69)
> 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:1299)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> {code}
> Trim of an empty or WS-only string should not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1071) spellcheck.extendedResults returns an invalid JSON response when count > 1
[
https://issues.apache.org/jira/browse/SOLR-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752472#action_12752472
]
Uri Boness commented on SOLR-1071:
--
bq. I guess it depends on how important order is in the top-level suggestions
list?
I guess the order is not that important, it's just that using a
SimpleOrderedMap will output a more intuitive JSON output to work with IMO.
bq. It would break back compat for the non-extended results too (for JSON and
friends).
True... I didn't think about that one. hmm... well... I guess you can keep it
as is then. I mean, it's not like you cannot work with the current format after
all :-)
> spellcheck.extendedResults returns an invalid JSON response when count > 1
> --
>
> Key: SOLR-1071
> URL: https://issues.apache.org/jira/browse/SOLR-1071
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 1.3
>Reporter: Uri Boness
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1071.patch, SpellCheckComponent_fix.patch,
> SpellCheckComponent_new_structure.patch,
> SpellCheckComponent_new_structure_incl_test.patch
>
>
> When: wt=json & spellcheck.extendedResults=true & spellcheck.count > 1, the
> suggestions are returned in the following format:
> "suggestions":[
> "amsterdm",{
>"numFound":5,
>"startOffset":0,
>"endOffset":8,
>"origFreq":0,
>"suggestion":{
> "frequency":8498,
> "word":"amsterdam"},
>"suggestion":{
> "frequency":1,
> "word":"amsterd"},
>"suggestion":{
> "frequency":8,
> "word":"amsterdams"},
>"suggestion":{
> "frequency":1,
> "word":"amstedam"},
>"suggestion":{
> "frequency":22,
> "word":"amsterdamse"}},
> "beak",{
>"numFound":5,
>"startOffset":9,
>"endOffset":13,
>"origFreq":0,
>"suggestion":{
> "frequency":379,
> "word":"beek"},
>"suggestion":{
> "frequency":26,
> "word":"beau"},
>"suggestion":{
> "frequency":26,
> "word":"baak"},
>"suggestion":{
> "frequency":15,
> "word":"teak"},
>"suggestion":{
> "frequency":11,
> "word":"beuk"}},
> "correctlySpelled",false,
> "collation","amsterdam beek"]}}
> This is an invalid json as each term is associated with a JSON object which
> holds multiple "suggestion" attributes. When working with a JSON library only
> the last "suggestion" attribute is picked up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1400) Document with empty or white-space only string causes exception with TrimFilter
[
https://issues.apache.org/jira/browse/SOLR-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752468#action_12752468
]
Peter Wolanin commented on SOLR-1400:
-
these lines seems to vary as to whether there is WS between "char" and the []
{code}
@@ -29,29 +30,48 @@
public class TestTrimFilter extends BaseTokenTestCase {
public void testTrim() throws Exception {
+char[] a = " a ".toCharArray();
+char [] b = "b ".toCharArray();
+char [] ccc = "cCc".toCharArray();
+char[] whitespace = " ".toCharArray();
+char[] empty = "".toCharArray();
{code}
> Document with empty or white-space only string causes exception with
> TrimFilter
> ---
>
> Key: SOLR-1400
> URL: https://issues.apache.org/jira/browse/SOLR-1400
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 1.4
>Reporter: Peter Wolanin
>Assignee: Grant Ingersoll
> Fix For: 1.4
>
> Attachments: SOLR-1400.patch, trim-example.xml
>
>
> Observed with Solr trunk. Posting any empty or whitespace-only string to a
> field using the {code}{code}
> Causes a java exception:
> {code}
> Sep 1, 2009 4:58:09 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.solr.analysis.TrimFilter.incrementToken(TrimFilter.java:63)
> at
> org.apache.solr.analysis.PatternReplaceFilter.incrementToken(PatternReplaceFilter.java:74)
> at
> org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:138)
> at
> org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:244)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:772)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:755)
> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2611)
> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2583)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:241)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61)
> at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:140)
> at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:69)
> 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:1299)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> {code}
> Trim of an empty or WS-only string should not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1400) Document with empty or white-space only string causes exception with TrimFilter
[
https://issues.apache.org/jira/browse/SOLR-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752463#action_12752463
]
Grant Ingersoll commented on SOLR-1400:
---
Peter, what is the code style inconsistency?
> Document with empty or white-space only string causes exception with
> TrimFilter
> ---
>
> Key: SOLR-1400
> URL: https://issues.apache.org/jira/browse/SOLR-1400
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 1.4
>Reporter: Peter Wolanin
>Assignee: Grant Ingersoll
> Fix For: 1.4
>
> Attachments: SOLR-1400.patch, trim-example.xml
>
>
> Observed with Solr trunk. Posting any empty or whitespace-only string to a
> field using the {code}{code}
> Causes a java exception:
> {code}
> Sep 1, 2009 4:58:09 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.solr.analysis.TrimFilter.incrementToken(TrimFilter.java:63)
> at
> org.apache.solr.analysis.PatternReplaceFilter.incrementToken(PatternReplaceFilter.java:74)
> at
> org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:138)
> at
> org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:244)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:772)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:755)
> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2611)
> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2583)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:241)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61)
> at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:140)
> at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:69)
> 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:1299)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> {code}
> Trim of an empty or WS-only string should not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: replace numbers with bullets in CHANGES
+1. Makes merging conflicts a whole lot easier. On Sep 7, 2009, at 9:05 PM, Yonik Seeley wrote: https://issues.apache.org/jira/browse/LUCENE-1898 Just one of those things we inherited from Lucene, but it does seem to make sense to just use a bullet (*) instead of numbering. I don't see any reason to change the current CHANGES for 1.4, but perhaps going forward after that? -Yonik http://www.lucidimagination.com
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752456#action_12752456 ] Noble Paul commented on SOLR-1277: -- bq.No... a zookeeper installation will be more static, but creating a new core should be very dynamic. One should even be able to run multiple solr clusters using the same zookeeper cluster. I guess I confused everyone. By zookeeper instance I meant an instance of ZooKeeperRequestHandler. > Implement a Solr specific naming service (using Zookeeper) > -- > > Key: SOLR-1277 > URL: https://issues.apache.org/jira/browse/SOLR-1277 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: log4j-1.2.15.jar, SOLR-1277.patch, zookeeper-3.2.0.jar > > Original Estimate: 672h > Remaining Estimate: 672h > > The goal is to give Solr server clusters self-healing attributes > where if a server fails, indexing and searching don't stop and > all of the partitions remain searchable. For configuration, the > ability to centrally deploy a new configuration without servers > going offline. > We can start with basic failover and start from there? > Features: > * Automatic failover (i.e. when a server fails, clients stop > trying to index to or search it) > * Centralized configuration management (i.e. new solrconfig.xml > or schema.xml propagates to a live Solr cluster) > * Optionally allow shards of a partition to be moved to another > server (i.e. if a server gets hot, move the hot segments out to > cooler servers). Ideally we'd have a way to detect hot segments > and move them seamlessly. With NRT this becomes somewhat more > difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1400) Document with empty or white-space only string causes exception with TrimFilter
[
https://issues.apache.org/jira/browse/SOLR-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752455#action_12752455
]
Sascha Szott commented on SOLR-1400:
Grant, why couldn't you readd the checks you introduced in revision #643465
{noformat}
Token t = input.next(in);
if (null == t || null == t.termBuffer() || t.termLength() == 0) {
return t;
}
{noformat}
and adjust them to the changes in the API, which results in
{noformat}
if (termAtt == null || termAtt.termBuffer() == null || termAtt.termLength() ==
0) {
return true;
}
{noformat}
To be honest, I'm not sure which return value suits best here.
> Document with empty or white-space only string causes exception with
> TrimFilter
> ---
>
> Key: SOLR-1400
> URL: https://issues.apache.org/jira/browse/SOLR-1400
> Project: Solr
> Issue Type: Bug
> Components: update
>Affects Versions: 1.4
>Reporter: Peter Wolanin
>Assignee: Grant Ingersoll
> Fix For: 1.4
>
> Attachments: SOLR-1400.patch, trim-example.xml
>
>
> Observed with Solr trunk. Posting any empty or whitespace-only string to a
> field using the {code}{code}
> Causes a java exception:
> {code}
> Sep 1, 2009 4:58:09 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.ArrayIndexOutOfBoundsException: -1
> at
> org.apache.solr.analysis.TrimFilter.incrementToken(TrimFilter.java:63)
> at
> org.apache.solr.analysis.PatternReplaceFilter.incrementToken(PatternReplaceFilter.java:74)
> at
> org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:138)
> at
> org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:244)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:772)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:755)
> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2611)
> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2583)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:241)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61)
> at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:140)
> at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:69)
> 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:1299)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> {code}
> Trim of an empty or WS-only string should not fail.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1071) spellcheck.extendedResults returns an invalid JSON response when count > 1
[
https://issues.apache.org/jira/browse/SOLR-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752449#action_12752449
]
Yonik Seeley commented on SOLR-1071:
bq. I mean the top most "suggestions" node.
Oh I see - I wasn't sure about that one... I guess it depends on how important
order is in the top-level suggestions list? It would break back compat for the
non-extended results too (for JSON and friends).
> spellcheck.extendedResults returns an invalid JSON response when count > 1
> --
>
> Key: SOLR-1071
> URL: https://issues.apache.org/jira/browse/SOLR-1071
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 1.3
>Reporter: Uri Boness
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1071.patch, SpellCheckComponent_fix.patch,
> SpellCheckComponent_new_structure.patch,
> SpellCheckComponent_new_structure_incl_test.patch
>
>
> When: wt=json & spellcheck.extendedResults=true & spellcheck.count > 1, the
> suggestions are returned in the following format:
> "suggestions":[
> "amsterdm",{
>"numFound":5,
>"startOffset":0,
>"endOffset":8,
>"origFreq":0,
>"suggestion":{
> "frequency":8498,
> "word":"amsterdam"},
>"suggestion":{
> "frequency":1,
> "word":"amsterd"},
>"suggestion":{
> "frequency":8,
> "word":"amsterdams"},
>"suggestion":{
> "frequency":1,
> "word":"amstedam"},
>"suggestion":{
> "frequency":22,
> "word":"amsterdamse"}},
> "beak",{
>"numFound":5,
>"startOffset":9,
>"endOffset":13,
>"origFreq":0,
>"suggestion":{
> "frequency":379,
> "word":"beek"},
>"suggestion":{
> "frequency":26,
> "word":"beau"},
>"suggestion":{
> "frequency":26,
> "word":"baak"},
>"suggestion":{
> "frequency":15,
> "word":"teak"},
>"suggestion":{
> "frequency":11,
> "word":"beuk"}},
> "correctlySpelled",false,
> "collation","amsterdam beek"]}}
> This is an invalid json as each term is associated with a JSON object which
> holds multiple "suggestion" attributes. When working with a JSON library only
> the last "suggestion" attribute is picked up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1071) spellcheck.extendedResults returns an invalid JSON response when count > 1
[
https://issues.apache.org/jira/browse/SOLR-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752448#action_12752448
]
Uri Boness commented on SOLR-1071:
--
bq. It already does... it's just the client code that checks for NamedList (the
parent of SimpleOrderedMap)
No... sorry, I mean the top most "suggestions" node. line 182 in the patched
class.
> spellcheck.extendedResults returns an invalid JSON response when count > 1
> --
>
> Key: SOLR-1071
> URL: https://issues.apache.org/jira/browse/SOLR-1071
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 1.3
>Reporter: Uri Boness
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1071.patch, SpellCheckComponent_fix.patch,
> SpellCheckComponent_new_structure.patch,
> SpellCheckComponent_new_structure_incl_test.patch
>
>
> When: wt=json & spellcheck.extendedResults=true & spellcheck.count > 1, the
> suggestions are returned in the following format:
> "suggestions":[
> "amsterdm",{
>"numFound":5,
>"startOffset":0,
>"endOffset":8,
>"origFreq":0,
>"suggestion":{
> "frequency":8498,
> "word":"amsterdam"},
>"suggestion":{
> "frequency":1,
> "word":"amsterd"},
>"suggestion":{
> "frequency":8,
> "word":"amsterdams"},
>"suggestion":{
> "frequency":1,
> "word":"amstedam"},
>"suggestion":{
> "frequency":22,
> "word":"amsterdamse"}},
> "beak",{
>"numFound":5,
>"startOffset":9,
>"endOffset":13,
>"origFreq":0,
>"suggestion":{
> "frequency":379,
> "word":"beek"},
>"suggestion":{
> "frequency":26,
> "word":"beau"},
>"suggestion":{
> "frequency":26,
> "word":"baak"},
>"suggestion":{
> "frequency":15,
> "word":"teak"},
>"suggestion":{
> "frequency":11,
> "word":"beuk"}},
> "correctlySpelled",false,
> "collation","amsterdam beek"]}}
> This is an invalid json as each term is associated with a JSON object which
> holds multiple "suggestion" attributes. When working with a JSON library only
> the last "suggestion" attribute is picked up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752446#action_12752446 ] Grant Ingersoll commented on SOLR-1277: --- The ZK client is actually very lightweight. I believe it needs to be per core, as you could have multiple layers and levels and each core could belong to different levels. Also, at least the way it currently works it relies on the full URL to know where it is. Most of the configuration is not for ZK itself, but instead for a core to properly register with ZK. > Implement a Solr specific naming service (using Zookeeper) > -- > > Key: SOLR-1277 > URL: https://issues.apache.org/jira/browse/SOLR-1277 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: log4j-1.2.15.jar, SOLR-1277.patch, zookeeper-3.2.0.jar > > Original Estimate: 672h > Remaining Estimate: 672h > > The goal is to give Solr server clusters self-healing attributes > where if a server fails, indexing and searching don't stop and > all of the partitions remain searchable. For configuration, the > ability to centrally deploy a new configuration without servers > going offline. > We can start with basic failover and start from there? > Features: > * Automatic failover (i.e. when a server fails, clients stop > trying to index to or search it) > * Centralized configuration management (i.e. new solrconfig.xml > or schema.xml propagates to a live Solr cluster) > * Optionally allow shards of a partition to be moved to another > server (i.e. if a server gets hot, move the hot segments out to > cooler servers). Ideally we'd have a way to detect hot segments > and move them seamlessly. With NRT this becomes somewhat more > difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752438#action_12752438 ] Yonik Seeley commented on SOLR-1277: Seems like we should have the ability to get pretty much all the configuration from zookeeper? > Implement a Solr specific naming service (using Zookeeper) > -- > > Key: SOLR-1277 > URL: https://issues.apache.org/jira/browse/SOLR-1277 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: log4j-1.2.15.jar, SOLR-1277.patch, zookeeper-3.2.0.jar > > Original Estimate: 672h > Remaining Estimate: 672h > > The goal is to give Solr server clusters self-healing attributes > where if a server fails, indexing and searching don't stop and > all of the partitions remain searchable. For configuration, the > ability to centrally deploy a new configuration without servers > going offline. > We can start with basic failover and start from there? > Features: > * Automatic failover (i.e. when a server fails, clients stop > trying to index to or search it) > * Centralized configuration management (i.e. new solrconfig.xml > or schema.xml propagates to a live Solr cluster) > * Optionally allow shards of a partition to be moved to another > server (i.e. if a server gets hot, move the hot segments out to > cooler servers). Ideally we'd have a way to detect hot segments > and move them seamlessly. With NRT this becomes somewhat more > difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752433#action_12752433 ] Noble Paul commented on SOLR-1277: -- That is the point. if we specify everything in the solrconfig.xml that automatically will make it belong to a core. how do we take care of that problem> > Implement a Solr specific naming service (using Zookeeper) > -- > > Key: SOLR-1277 > URL: https://issues.apache.org/jira/browse/SOLR-1277 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: log4j-1.2.15.jar, SOLR-1277.patch, zookeeper-3.2.0.jar > > Original Estimate: 672h > Remaining Estimate: 672h > > The goal is to give Solr server clusters self-healing attributes > where if a server fails, indexing and searching don't stop and > all of the partitions remain searchable. For configuration, the > ability to centrally deploy a new configuration without servers > going offline. > We can start with basic failover and start from there? > Features: > * Automatic failover (i.e. when a server fails, clients stop > trying to index to or search it) > * Centralized configuration management (i.e. new solrconfig.xml > or schema.xml propagates to a live Solr cluster) > * Optionally allow shards of a partition to be moved to another > server (i.e. if a server gets hot, move the hot segments out to > cooler servers). Ideally we'd have a way to detect hot segments > and move them seamlessly. With NRT this becomes somewhat more > difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1277) Implement a Solr specific naming service (using Zookeeper)
[ https://issues.apache.org/jira/browse/SOLR-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752432#action_12752432 ] Yonik Seeley commented on SOLR-1277: bq. Another important design aspect is that , do we want to have separate zookeeper instances for each core in a multicore environment? No... a zookeeper installation will be more static, but creating a new core should be very dynamic. One should even be able to run multiple solr clusters using the same zookeeper cluster. > Implement a Solr specific naming service (using Zookeeper) > -- > > Key: SOLR-1277 > URL: https://issues.apache.org/jira/browse/SOLR-1277 > Project: Solr > Issue Type: New Feature >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: log4j-1.2.15.jar, SOLR-1277.patch, zookeeper-3.2.0.jar > > Original Estimate: 672h > Remaining Estimate: 672h > > The goal is to give Solr server clusters self-healing attributes > where if a server fails, indexing and searching don't stop and > all of the partitions remain searchable. For configuration, the > ability to centrally deploy a new configuration without servers > going offline. > We can start with basic failover and start from there? > Features: > * Automatic failover (i.e. when a server fails, clients stop > trying to index to or search it) > * Centralized configuration management (i.e. new solrconfig.xml > or schema.xml propagates to a live Solr cluster) > * Optionally allow shards of a partition to be moved to another > server (i.e. if a server gets hot, move the hot segments out to > cooler servers). Ideally we'd have a way to detect hot segments > and move them seamlessly. With NRT this becomes somewhat more > difficult but not impossible? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1071) spellcheck.extendedResults returns an invalid JSON response when count > 1
[
https://issues.apache.org/jira/browse/SOLR-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752423#action_12752423
]
Yonik Seeley commented on SOLR-1071:
Thanks for the review Uri!
bq. One more thing - I think it will be more intuitive to use a
SimpleOrderedMap instead of a NamedList for the "suggestions" node.
It already does... it's just the client code that checks for NamedList (the
parent of SimpleOrderedMap)
> spellcheck.extendedResults returns an invalid JSON response when count > 1
> --
>
> Key: SOLR-1071
> URL: https://issues.apache.org/jira/browse/SOLR-1071
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 1.3
>Reporter: Uri Boness
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1071.patch, SpellCheckComponent_fix.patch,
> SpellCheckComponent_new_structure.patch,
> SpellCheckComponent_new_structure_incl_test.patch
>
>
> When: wt=json & spellcheck.extendedResults=true & spellcheck.count > 1, the
> suggestions are returned in the following format:
> "suggestions":[
> "amsterdm",{
>"numFound":5,
>"startOffset":0,
>"endOffset":8,
>"origFreq":0,
>"suggestion":{
> "frequency":8498,
> "word":"amsterdam"},
>"suggestion":{
> "frequency":1,
> "word":"amsterd"},
>"suggestion":{
> "frequency":8,
> "word":"amsterdams"},
>"suggestion":{
> "frequency":1,
> "word":"amstedam"},
>"suggestion":{
> "frequency":22,
> "word":"amsterdamse"}},
> "beak",{
>"numFound":5,
>"startOffset":9,
>"endOffset":13,
>"origFreq":0,
>"suggestion":{
> "frequency":379,
> "word":"beek"},
>"suggestion":{
> "frequency":26,
> "word":"beau"},
>"suggestion":{
> "frequency":26,
> "word":"baak"},
>"suggestion":{
> "frequency":15,
> "word":"teak"},
>"suggestion":{
> "frequency":11,
> "word":"beuk"}},
> "correctlySpelled",false,
> "collation","amsterdam beek"]}}
> This is an invalid json as each term is associated with a JSON object which
> holds multiple "suggestion" attributes. When working with a JSON library only
> the last "suggestion" attribute is picked up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1071) spellcheck.extendedResults returns an invalid JSON response when count > 1
[
https://issues.apache.org/jira/browse/SOLR-1071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752417#action_12752417
]
Uri Boness commented on SOLR-1071:
--
Looks good!
As for the naming, I really like your suggestion (in one of the comments above)
to replace "suggestion" with "alternatives". So the client code can look
something like:
{code}
response.getSuggestions().get("hell").getAlternatives().get(0);
{code}
One more thing - I think it will be more intuitive to use a SimpleOrderedMap
instead of a NamedList for the "suggestions" node. for the xml response it
won't make much difference I guess, but for the json one it will be more
intuitive and easier to work with. So to take your example above, you'd get
something like:
{code}
"spellcheck": {
"suggestions": {
"hell":{
"numFound":2,
"startOffset":0,
"endOffset":4,
"origFreq":0,
"alternatives":[
{
"word":"dell",
"freq":4
},
{
"word":"all",
"freq":4
}
]
},
"correctlySpelled":false}}}
{code}
> spellcheck.extendedResults returns an invalid JSON response when count > 1
> --
>
> Key: SOLR-1071
> URL: https://issues.apache.org/jira/browse/SOLR-1071
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
>Affects Versions: 1.3
>Reporter: Uri Boness
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1071.patch, SpellCheckComponent_fix.patch,
> SpellCheckComponent_new_structure.patch,
> SpellCheckComponent_new_structure_incl_test.patch
>
>
> When: wt=json & spellcheck.extendedResults=true & spellcheck.count > 1, the
> suggestions are returned in the following format:
> "suggestions":[
> "amsterdm",{
>"numFound":5,
>"startOffset":0,
>"endOffset":8,
>"origFreq":0,
>"suggestion":{
> "frequency":8498,
> "word":"amsterdam"},
>"suggestion":{
> "frequency":1,
> "word":"amsterd"},
>"suggestion":{
> "frequency":8,
> "word":"amsterdams"},
>"suggestion":{
> "frequency":1,
> "word":"amstedam"},
>"suggestion":{
> "frequency":22,
> "word":"amsterdamse"}},
> "beak",{
>"numFound":5,
>"startOffset":9,
>"endOffset":13,
>"origFreq":0,
>"suggestion":{
> "frequency":379,
> "word":"beek"},
>"suggestion":{
> "frequency":26,
> "word":"beau"},
>"suggestion":{
> "frequency":26,
> "word":"baak"},
>"suggestion":{
> "frequency":15,
> "word":"teak"},
>"suggestion":{
> "frequency":11,
> "word":"beuk"}},
> "correctlySpelled",false,
> "collation","amsterdam beek"]}}
> This is an invalid json as each term is associated with a JSON object which
> holds multiple "suggestion" attributes. When working with a JSON library only
> the last "suggestion" attribute is picked up.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hudson build is back to normal: Solr-trunk #918
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/918/changes
