Re: ValueSourceParser problem
On Wed, Dec 16, 2009 at 12:39 PM, patrick o'leary wrote:
> Yeah.. can't release that part mate, all you need is
>
> package com.pjaol;
>
> import org.apache.lucene.queryParser.ParseException;
> import org.apache.solr.search.FunctionQParser;
> import org.apache.solr.search.ValueSourceParser;
> import org.apache.solr.search.function.ValueSource;
>
> public class CustomValueSourceParser extends ValueSourceParser{
>
>@Override
>public ValueSource parse(FunctionQParser fp) throws ParseException {
>
>System.out.println("*** Called");
>return null;
>}
>
> }
>
>
> And
> class="com.pjaol.CustomValueSourceParser"
> />
> in your solrconfig.xml
>
> The parse method only gets called at query time
>
>
Patrick, this works for me. The string is printed in the console. Your
runtime classpath must have Solr 1.3 jars somewhere because the
ValueSourceParser#init was abstract in 1.3
http://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.3/src/java/org/apache/solr/search/ValueSourceParser.java
--
Regards,
Shalin Shekhar Mangar.
Re: ValueSourceParser problem
Yeah.. can't release that part mate, all you need is
package com.pjaol;
import org.apache.lucene.queryParser.ParseException;
import org.apache.solr.search.FunctionQParser;
import org.apache.solr.search.ValueSourceParser;
import org.apache.solr.search.function.ValueSource;
public class CustomValueSourceParser extends ValueSourceParser{
@Override
public ValueSource parse(FunctionQParser fp) throws ParseException {
System.out.println("*** Called");
return null;
}
}
And
in your solrconfig.xml
The parse method only gets called at query time
2009/12/15 Noble Paul നോബിള് नोब्ळ्
> it does not have the code for SocialValueSource..
>
> On Wed, Dec 16, 2009 at 12:18 PM, patrick o'leary wrote:
> > Rather than subject the list to code, it's pasted here
> > http://www.pasteyourcode.com/13969
> >
> >
> > On Tue, Dec 15, 2009 at 10:42 PM, Shalin Shekhar Mangar <
> > shalinman...@gmail.com> wrote:
> >
> >> On Wed, Dec 16, 2009 at 11:58 AM, patrick o'leary
> wrote:
> >>
> >> > SEVERE: java.lang.AbstractMethodError
> >> >at
> org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:439)
> >> >at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1498)
> >> >at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1492)
> >> >at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1525)
> >> >at
> >> >
> org.apache.solr.core.SolrCore.initValueSourceParsers(SolrCore.java:1469)
> >> >at org.apache.solr.core.SolrCore.(SolrCore.java:549)
> >> >at
> >> >
> >> >
> >>
> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:137)
> >> >at
> >> >
> >>
> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83)
> >> >at
> >> org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99)
> >> >
> >> > And
> >> > svn info
> >> > Path: .
> >> > URL: http://svn.apache.org/repos/asf/lucene/solr/trunk
> >> > Repository Root: http://svn.apache.org/repos/asf
> >> > Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
> >> > Revision: 891117
> >> > Node Kind: directory
> >> > Schedule: normal
> >> > Last Changed Author: koji
> >> > Last Changed Rev: 890798
> >> > Last Changed Date: 2009-12-15 06:13:59 -0800 (Tue, 15 Dec 2009)
> >> >
> >> >
> >> I just wrote a custom ValueSourceParser which does not override the init
> >> method and it loads fine on current trunk. Can you share your code?
> >>
> >> --
> >> Regards,
> >> Shalin Shekhar Mangar.
> >>
> >
>
>
>
> --
> -
> Noble Paul | Systems Architect| AOL | http://aol.com
>
Re: ValueSourceParser problem
it does not have the code for SocialValueSource.. On Wed, Dec 16, 2009 at 12:18 PM, patrick o'leary wrote: > Rather than subject the list to code, it's pasted here > http://www.pasteyourcode.com/13969 > > > On Tue, Dec 15, 2009 at 10:42 PM, Shalin Shekhar Mangar < > shalinman...@gmail.com> wrote: > >> On Wed, Dec 16, 2009 at 11:58 AM, patrick o'leary wrote: >> >> > SEVERE: java.lang.AbstractMethodError >> > at org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:439) >> > at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1498) >> > at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1492) >> > at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1525) >> > at >> > org.apache.solr.core.SolrCore.initValueSourceParsers(SolrCore.java:1469) >> > at org.apache.solr.core.SolrCore.(SolrCore.java:549) >> > at >> > >> > >> org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:137) >> > at >> > >> org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83) >> > at >> org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99) >> > >> > And >> > svn info >> > Path: . >> > URL: http://svn.apache.org/repos/asf/lucene/solr/trunk >> > Repository Root: http://svn.apache.org/repos/asf >> > Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 >> > Revision: 891117 >> > Node Kind: directory >> > Schedule: normal >> > Last Changed Author: koji >> > Last Changed Rev: 890798 >> > Last Changed Date: 2009-12-15 06:13:59 -0800 (Tue, 15 Dec 2009) >> > >> > >> I just wrote a custom ValueSourceParser which does not override the init >> method and it loads fine on current trunk. Can you share your code? >> >> -- >> Regards, >> Shalin Shekhar Mangar. >> > -- - Noble Paul | Systems Architect| AOL | http://aol.com
[jira] Updated: (SOLR-1131) Allow a single field type to index multiple fields
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1131: - Attachment: SOLR-1131.patch Modified the Query creation to use the cached SchemaField names. > Allow a single field type to index multiple fields > -- > > Key: SOLR-1131 > URL: https://issues.apache.org/jira/browse/SOLR-1131 > Project: Solr > Issue Type: New Feature > Components: Schema and Analysis >Reporter: Ryan McKinley >Assignee: Grant Ingersoll > Fix For: 1.5 > > Attachments: SOLR-1131-IndexMultipleFields.patch, > SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch > > > In a few special cases, it makes sense for a single "field" (the concept) to > be indexed as a set of Fields (lucene Field). Consider SOLR-773. The > concept "point" may be best indexed in a variety of ways: > * geohash (sincle lucene field) > * lat field, lon field (two double fields) > * cartesian tiers (a series of fields with tokens to say if it exists within > that region) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ValueSourceParser problem
Rather than subject the list to code, it's pasted here http://www.pasteyourcode.com/13969 On Tue, Dec 15, 2009 at 10:42 PM, Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > On Wed, Dec 16, 2009 at 11:58 AM, patrick o'leary wrote: > > > SEVERE: java.lang.AbstractMethodError > >at org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:439) > >at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1498) > >at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1492) > >at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1525) > >at > > org.apache.solr.core.SolrCore.initValueSourceParsers(SolrCore.java:1469) > >at org.apache.solr.core.SolrCore.(SolrCore.java:549) > >at > > > > > org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:137) > >at > > > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83) > >at > org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99) > > > > And > > svn info > > Path: . > > URL: http://svn.apache.org/repos/asf/lucene/solr/trunk > > Repository Root: http://svn.apache.org/repos/asf > > Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 > > Revision: 891117 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: koji > > Last Changed Rev: 890798 > > Last Changed Date: 2009-12-15 06:13:59 -0800 (Tue, 15 Dec 2009) > > > > > I just wrote a custom ValueSourceParser which does not override the init > method and it loads fine on current trunk. Can you share your code? > > -- > Regards, > Shalin Shekhar Mangar. >
Re: ValueSourceParser problem
On Wed, Dec 16, 2009 at 11:58 AM, patrick o'leary wrote: > SEVERE: java.lang.AbstractMethodError >at org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:439) >at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1498) >at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1492) >at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1525) >at > org.apache.solr.core.SolrCore.initValueSourceParsers(SolrCore.java:1469) >at org.apache.solr.core.SolrCore.(SolrCore.java:549) >at > > org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:137) >at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83) >at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99) > > And > svn info > Path: . > URL: http://svn.apache.org/repos/asf/lucene/solr/trunk > Repository Root: http://svn.apache.org/repos/asf > Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 > Revision: 891117 > Node Kind: directory > Schedule: normal > Last Changed Author: koji > Last Changed Rev: 890798 > Last Changed Date: 2009-12-15 06:13:59 -0800 (Tue, 15 Dec 2009) > > I just wrote a custom ValueSourceParser which does not override the init method and it loads fine on current trunk. Can you share your code? -- Regards, Shalin Shekhar Mangar.
Re: ValueSourceParser problem
SEVERE: java.lang.AbstractMethodError at org.apache.solr.core.SolrCore.createInitInstance(SolrCore.java:439) at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1498) at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1492) at org.apache.solr.core.SolrCore.initPlugins(SolrCore.java:1525) at org.apache.solr.core.SolrCore.initValueSourceParsers(SolrCore.java:1469) at org.apache.solr.core.SolrCore.(SolrCore.java:549) at org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:137) at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:83) at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99) And svn info Path: . URL: http://svn.apache.org/repos/asf/lucene/solr/trunk Repository Root: http://svn.apache.org/repos/asf Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 891117 Node Kind: directory Schedule: normal Last Changed Author: koji Last Changed Rev: 890798 Last Changed Date: 2009-12-15 06:13:59 -0800 (Tue, 15 Dec 2009) On Tue, Dec 15, 2009 at 10:12 PM, Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > On Wed, Dec 16, 2009 at 11:32 AM, patrick o'leary wrote: > > > Check SolrCore.createInitInstance > > It cast's your CustomValueSourceParser as a NamedListInitializedPlugin > > which > > is an interface, > > thus the AbstractMethodError, as there isn't a concrete implementation of > > init. > > > > If it cast it as a ValueSourceParser in SolrCore then it would be fine. > > > > > That is not possible. Even though the object is cast to an interface > NamedListInitializedPlugin, it is still an instance of ValueSourceParser > and > therefore it does have an implementation of the init method. Am I missing > something? > > -- > Regards, > Shalin Shekhar Mangar. >
Re: ValueSourceParser problem
On Wed, Dec 16, 2009 at 11:32 AM, patrick o'leary wrote: > Check SolrCore.createInitInstance > It cast's your CustomValueSourceParser as a NamedListInitializedPlugin > which > is an interface, > thus the AbstractMethodError, as there isn't a concrete implementation of > init. > > If it cast it as a ValueSourceParser in SolrCore then it would be fine. > > That is not possible. Even though the object is cast to an interface NamedListInitializedPlugin, it is still an instance of ValueSourceParser and therefore it does have an implementation of the init method. Am I missing something? -- Regards, Shalin Shekhar Mangar.
Re: ValueSourceParser problem
Check SolrCore.createInitInstance It cast's your CustomValueSourceParser as a NamedListInitializedPlugin which is an interface, thus the AbstractMethodError, as there isn't a concrete implementation of init. If it cast it as a ValueSourceParser in SolrCore then it would be fine. On Tue, Dec 15, 2009 at 9:59 PM, Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > On Wed, Dec 16, 2009 at 11:01 AM, patrick o'leary wrote: > > > > > #2 There's an AbstractMethodError when you extend ValueSourceParser and > > don't override the init(NamedList args) method > > because SolrCore:~439 createInitInstance, cast's the plugin class as a > > NamedListInitializedPlugin, and call's > > ((NamedListInitializedPlugin) o).init(info.initArgs); > > > > If your extended ValueSourceParser class doesn't provide an override, > then > > there's nothing that implements the base interface from > > NamedListInitializedPlugin. > > > > > ValueSourceParser in trunk has an empty init method so you should never get > a AbstractMethodError. Can you check again? > > -- > Regards, > Shalin Shekhar Mangar. >
Re: ValueSourceParser problem
On Wed, Dec 16, 2009 at 11:01 AM, patrick o'leary wrote: > > #2 There's an AbstractMethodError when you extend ValueSourceParser and > don't override the init(NamedList args) method > because SolrCore:~439 createInitInstance, cast's the plugin class as a > NamedListInitializedPlugin, and call's > ((NamedListInitializedPlugin) o).init(info.initArgs); > > If your extended ValueSourceParser class doesn't provide an override, then > there's nothing that implements the base interface from > NamedListInitializedPlugin. > > ValueSourceParser in trunk has an empty init method so you should never get a AbstractMethodError. Can you check again? -- Regards, Shalin Shekhar Mangar.
Re: ValueSourceParser problem
Hey Patrick, On 12/15/09 9:31 PM, "patrick o'leary" wrote: > #1 Change documentation of > http://wiki.apache.org/solr/SolrPlugins#ValueSourceParser to say extends > ValueSourceParser rather than implements. I updated the Wiki based on your comment. Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
ValueSourceParser problem
Howdy Couple of things about the ValueSourceParser #1 Change documentation of http://wiki.apache.org/solr/SolrPlugins#ValueSourceParser to say extends ValueSourceParser rather than implements. #2 There's an AbstractMethodError when you extend ValueSourceParser and don't override the init(NamedList args) method because SolrCore:~439 createInitInstance, cast's the plugin class as a NamedListInitializedPlugin, and call's ((NamedListInitializedPlugin) o).init(info.initArgs); If your extended ValueSourceParser class doesn't provide an override, then there's nothing that implements the base interface from NamedListInitializedPlugin. Providing a head scratching conundrum that should be avoided. Seems more than a documentation fix Patrick
[jira] Commented: (SOLR-1316) Create autosuggest component
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791164#action_12791164 ] Andrzej Bialecki commented on SOLR-1316: - bq. What about DAWGs? Are we still considering them? I would be happy to include DAWGs if someone were to implement them ... ;) > Create autosuggest component > > > Key: SOLR-1316 > URL: https://issues.apache.org/jira/browse/SOLR-1316 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.5 > > Attachments: suggest.patch, suggest.patch, suggest.patch, TST.zip > > Original Estimate: 96h > Remaining Estimate: 96h > > Autosuggest is a common search function that can be integrated > into Solr as a SearchComponent. Our first implementation will > use the TernaryTree found in Lucene contrib. > * Enable creation of the dictionary from the index or via Solr's > RPC mechanism > * What types of parameters and settings are desirable? > * Hopefully in the future we can include user click through > rates to boost those terms/phrases higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1316) Create autosuggest component
[ https://issues.apache.org/jira/browse/SOLR-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrzej Bialecki updated SOLR-1316: Attachment: suggest.patch Updated patch: * removed the broken RadixTree, * changed Suggester and Lookup API so that they don't join the tokens - instead they will use whatever tokens are produced by the analyzer. For now results are merged into a single SpellingResult. > Create autosuggest component > > > Key: SOLR-1316 > URL: https://issues.apache.org/jira/browse/SOLR-1316 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.4 >Reporter: Jason Rutherglen >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.5 > > Attachments: suggest.patch, suggest.patch, suggest.patch, TST.zip > > Original Estimate: 96h > Remaining Estimate: 96h > > Autosuggest is a common search function that can be integrated > into Solr as a SearchComponent. Our first implementation will > use the TernaryTree found in Lucene contrib. > * Enable creation of the dictionary from the index or via Solr's > RPC mechanism > * What types of parameters and settings are desirable? > * Hopefully in the future we can include user click through > rates to boost those terms/phrases higher -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Namespaces in response (SOLR-1586)
Hi Hoss: On 12/15/09 6:39 PM, "Chris Hostetter" wrote: > > > : > a SolrQueryResponse, no one has ever accused any of those response writers > : > of not being flexible enough to generate a *different* type of response in > : > those formats. > : > : You may be right, but actually quite a few issues have referenced even non > : XMLWriters of similar issues. See: > > I honeslty don't understand what you're getting at here, this list of > issues is all over the map and almost none of them relate to the > extensibility of any request handlers... They may be all over the map, but in general they address your statement about "non-XML response writers" being flexible enough to generate a different type of response (although admittedly, none are as clear at the XMLWriter examples, I'll give you that). The examples I gave were just based on a quick search of JIRA. > : Maybe, maybe not. I'm not sure the effect is to make it crystal clear as > : much as it is to make it "clearer". XMLWriter is totally ambiguous -- what > : type of "XML" does it generate? I would argue "SOLR response XML", hence the > : SorlXmlResponseWriter. > > eh ... agree to disagree i guess. it seems just as valid to say that > "UpdateCommand" -- what type of data does it update? ... or that > "RequestHandler" is ambigious because it can only handle "Solr" requests, > so it should be title "SolrRequestHandler". True! I guess it's just aesthetics. I can go either way, but I dunno. (and yes, just to be a pest, What type of data does that UpdateCommand update?) > > we have enough ambiguity and confusion with some of our config file > options and names that non-java users see ... the ones that only plugin > writers see i'm less concerned with ... better to beef up the javadocs > that deal with a bunch of deprecation headaches just to add "Solr" to the > front of a class name. You give a little, you get a little back. Maybe a compromise is to called it NamedListResponseWriter, b/c that's really what it writes, no? Naming can be a pain -- I'll try and think of a good one when I'm preparing the patch for SOLR-1649. Thanks for the discussion. Helps to clarify things! Cheers, Chris ++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.mattm...@jpl.nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[
https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791146#action_12791146
]
Chris A. Mattmann commented on SOLR-17:
---
@Uri:
{quote}
Fair enough. I guess it can always serve as a reference to better understanding
what to expect from a Solr response (instead of trying to figure things out
from the code). Good thing about this generic format is that it's unlikely to
change that frequently, so the XSD's will probably not change that often as
well.
{quote}
+1, thanks for hearing me out!
@Hoss
{quote}
1. where should it live in source control? where should it live in the release
artifact?
2. what schema URI should we pick for identifying this? (i suspect apache.org
has a standard for this, so or at least precident from other projects, so we
should make sure we follow those examples before picking one arbitrarily
{quote}
In src, I think it should live here: src/xsd (let's call it solrresponse.xsd),
and let's make a DTD too (called solrresponse.dtd) that lives in src/dtd. In
release, let's make it live somewhere that gets published onto the SOLR website
(you guys are using forrest, right? I can put a patch together that copies it
to the right place). It would be great to have it at, say:
http://lucene.apache.org/solr/schema/solrresponse.xsd
http://lucene.apaceh.org/solr/dtd/solrresponse.dtd
In the long term, maybe we could version the URIs too, based on the current
SOLR version, but that's down the road.
{quote}
3. it won't do any good unless we make the XmlResponseWriter refrence the
schema URI so client tools can validate with it.
{quote}
Well it'll do some good just to have it out there. I'm a fan of incremental
patchiness, so as a start, can we make this issue just put the XSD/DTD into the
src, and then copy it to a Forrest accessible link, and then a do site rebuild?
Then, as patch #2, we tackle your #3 above. I agree, #3 is pretty trivial
(modifying a static final String in XMLWriter.java), but to me we can do it as
a separate, clean patch, not cluttered with adding the XSD/DTD and then
modifying Forrest (which this patch can do).
{quote}
4. we need hooks in our own test system for validating responses we get back to
catch potential bugs (either in the schema itself, or in xml that might get
inadvertantly changed)
{quote}
I think this is patch #3, or maybe #2a (and can go in along with #2 above), but
+1 for this too. I'm happy to contribute/lead the efforts here. I'll start
preparing patches right away.
Cheers,
Chris
> XSD for solr requests/responses
> ---
>
> Key: SOLR-17
> URL: https://issues.apache.org/jira/browse/SOLR-17
> Project: Solr
> Issue Type: Improvement
>Reporter: Mike Baranczak
>Priority: Minor
> Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd,
> UselessRequestHandler.java
>
>
> Attaching an XML schema definition for the responses and the update requests.
> I needed to do this for myself anyway, so I might as well contribute it to
> the project.
> At the moment, I have no plans to write an XSD for the config documents, but
> it wouldn't be a bad idea.
> TODO: change the schema URL. I'm guessing that Apache already has some sort
> of naming convention for these?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Namespaces in response (SOLR-1586)
: > a SolrQueryResponse, no one has ever accused any of those response writers : > of not being flexible enough to generate a *different* type of response in : > those formats. : : You may be right, but actually quite a few issues have referenced even non : XMLWriters of similar issues. See: I honeslty don't understand what you're getting at here, this list of issues is all over the map and almost none of them relate to the extensibility of any request handlers... : http://issues.apache.org/jira/browse/SOLR-1616 ... this was from someone who didn't notice json.nl=arrarr and felt like the default way of representing a NamedList in JSON was odd. they didn't disagree with the JSON structure, they just don't like the default. : http://issues.apache.org/jira/browse/SOLR-358 ...this was an improvement issue to track adding the ruby response writer ... which idnd't exist before this. : http://issues.apache.org/jira/browse/SOLR-1555 ...this is a bug in how the term compontent adds the terms to the response ... it's completley orthoginal to the response output structure. : http://issues.apache.org/jira/browse/SOLR-431 ...this is from one of my coworkers who had some really old, really hideously hackish plugins from before Solr was open sourced that was trying to find a way to work arround a big fixed in the xml escaping -- i could maybe see this as a "response writers need to be more flexible" type issue, except they knew from the start the start they were abusing a bug. : http://issues.apache.org/jira/browse/SOLR-912 ...this is an issue Kay opened to revamp NamedList to be more typesafe ... also has absolutely nothign to do with how flexible the output representation is. : Maybe, maybe not. I'm not sure the effect is to make it crystal clear as : much as it is to make it "clearer". XMLWriter is totally ambiguous -- what : type of "XML" does it generate? I would argue "SOLR response XML", hence the : SorlXmlResponseWriter. eh ... agree to disagree i guess. it seems just as valid to say that "UpdateCommand" -- what type of data does it update? ... or that "RequestHandler" is ambigious because it can only handle "Solr" requests, so it should be title "SolrRequestHandler". we have enough ambiguity and confusion with some of our config file options and names that non-java users see ... the ones that only plugin writers see i'm less concerned with ... better to beef up the javadocs that deal with a bunch of deprecation headaches just to add "Solr" to the front of a class name. -Hoss
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[ https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791137#action_12791137 ] Hoss Man commented on SOLR-17: -- bq. There are actually a lot of useful things that could be done with an XSD. I agree ... my comment (way back when) was more about what we should do with it in a Solr release: converting it from a *.xsd attachment to a *.patch attachment... 1. where should it live in source control? where should it live in the release artifact? 2. what schema URI should we pick for identifying this? (i suspect apache.org has a standard for this, so or at least precident from other projects, so we should make sure we follow those examples before picking one arbitrarily 3. it won't do any good unless we make the XmlResponseWriter refrence the schema URI so client tools can validate with it. 4. we need hooks in our own test system for validating responses we get back to catch potential bugs (either in the schema itself, or in xml that might get inadvertantly changed) ...etc... > XSD for solr requests/responses > --- > > Key: SOLR-17 > URL: https://issues.apache.org/jira/browse/SOLR-17 > Project: Solr > Issue Type: Improvement >Reporter: Mike Baranczak >Priority: Minor > Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd, > UselessRequestHandler.java > > > Attaching an XML schema definition for the responses and the update requests. > I needed to do this for myself anyway, so I might as well contribute it to > the project. > At the moment, I have no plans to write an XSD for the config documents, but > it wouldn't be a bad idea. > TODO: change the schema URL. I'm guessing that Apache already has some sort > of naming convention for these? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1656) XInclude's are resolved relative CWD, not instance dir
[ https://issues.apache.org/jira/browse/SOLR-1656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791130#action_12791130 ] Hoss Man commented on SOLR-1656: bq. I may be very wrongly informing but using ... I'm sure you are correct, but as i mentioned, Config only has an InputStream when it instantiates the DocumentBuilder. (hence: non trivial fix) > XInclude's are resolved relative CWD, not instance dir > -- > > Key: SOLR-1656 > URL: https://issues.apache.org/jira/browse/SOLR-1656 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Hoss Man > > As noted on the mailing list, when an XInclude in a config files refrences a > relative path, it's resolved relative the CWD of the servlet container, and > not the instanceDir of the core... > > http://old.nabble.com/using-Xinclude-with-multi-core-to26548400.html#a26548400 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[
https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791126#action_12791126
]
Uri Boness commented on SOLR-17:
{quote}
However, as a start, I think contributing and committing the SOLR XML response
writer output XSD (and a DTD, which I'll attach) is something that adds value,
doesn't take anything away, or touch other parts of the code, etc., and is
worthwhile to do.
{quote}
Fair enough. I guess it can always serve as a reference to better understanding
what to expect from a Solr response (instead of trying to figure things out
from the code). Good thing about this generic format is that it's unlikely to
change that frequently, so the XSD's will probably not change that often as
well.
> XSD for solr requests/responses
> ---
>
> Key: SOLR-17
> URL: https://issues.apache.org/jira/browse/SOLR-17
> Project: Solr
> Issue Type: Improvement
>Reporter: Mike Baranczak
>Priority: Minor
> Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd,
> UselessRequestHandler.java
>
>
> Attaching an XML schema definition for the responses and the update requests.
> I needed to do this for myself anyway, so I might as well contribute it to
> the project.
> At the moment, I have no plans to write an XSD for the config documents, but
> it wouldn't be a bad idea.
> TODO: change the schema URL. I'm guessing that Apache already has some sort
> of naming convention for these?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[
https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791042#action_12791042
]
Chris A. Mattmann commented on SOLR-17:
---
Hi Uri:
Thanks. Comments below:
{quote}
Having well defined XSD's for public services can be extremely helpful in many
aspects... together with proper version management they define the contract
between the users the the service. Some of the use cases that Chris listed
above are definitely valid and realistic. Moreover, XSD provides a natural and
proper documentation for the supported formats which any decent xml editor can
make use of and provide you with hints for writing the solrconfig.xml and the
schema.xml (for example).
{quote}
+1.
{quote}
That said... most of the xml formats in Solr are too generic to benefit from
XSD's. The only format where it makes sense is the schema.xml as it has an
expressive domain-driven structure. Unfortunately this is something you cannot
say for for the response formats and the solrconfig.xml where the
expressiveness lays within the values of the elements/attributes rather than in
the elements/attribute names themselves. XSD doesn't handle element/attribute
values very well.
{quote}
Kinda sorta. Regardless of how generic the XML used in SOLR is, I think it can
still benefit from being documented in an XSD. That way, as you mentioned
above, if it ever changes, with proper versioning, you have a baseline. In
addition, for those wanting to know what can and can't be done to be a valid
SOLR XML response (as I did w.r.t. geo stuff), the XSD/DTD can serve as a guide
regarding that interface. And beyond just names, there's cardinality that the
XSD could help validate (i.e., can you have sub-tags within a in the
SOLR XML response? -- the answer is no, and this is something that could be
codified in a DTD/XSD). Furthermore, we could also document what each of the
valid attribute and element definitions are too, which would be useful even
from a documentation perspective.
Maybe the idea is that we should have XSD/DTDs for not only the services, but
also for some of the configuration. This is a completely valid idea and I'm +1
for it. However, as a start, I think contributing and committing the SOLR XML
response writer output XSD (and a DTD, which I'll attach) is something that
adds value, doesn't take anything away, or touch other parts of the code, etc.,
and is worthwhile to do.
Cheers,
Chris
> XSD for solr requests/responses
> ---
>
> Key: SOLR-17
> URL: https://issues.apache.org/jira/browse/SOLR-17
> Project: Solr
> Issue Type: Improvement
>Reporter: Mike Baranczak
>Priority: Minor
> Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd,
> UselessRequestHandler.java
>
>
> Attaching an XML schema definition for the responses and the update requests.
> I needed to do this for myself anyway, so I might as well contribute it to
> the project.
> At the moment, I have no plans to write an XSD for the config documents, but
> it wouldn't be a bad idea.
> TODO: change the schema URL. I'm guessing that Apache already has some sort
> of naming convention for these?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[ https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791023#action_12791023 ] Uri Boness commented on SOLR-17: Having well defined XSD's for public services can be *extremely* helpful in many aspects... together with proper version management they define the contract between the users the the service. Some of the use cases that Chris listed above are definitely valid and realistic. Moreover, XSD provides a natural and proper documentation for the supported formats which any decent xml editor can make use of and provide you with hints for writing the solrconfig.xml and the schema.xml (for example). That said... most of the xml formats in Solr are too generic to benefit from XSD's. The only format where it makes sense is the schema.xml as it has an expressive domain-driven structure. Unfortunately this is something you cannot say for for the response formats and the solrconfig.xml where the expressiveness lays within the *values* of the elements/attributes rather than in the elements/attribute *names* themselves. XSD doesn't handle element/attribute values very well. > XSD for solr requests/responses > --- > > Key: SOLR-17 > URL: https://issues.apache.org/jira/browse/SOLR-17 > Project: Solr > Issue Type: Improvement >Reporter: Mike Baranczak >Priority: Minor > Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd, > UselessRequestHandler.java > > > Attaching an XML schema definition for the responses and the update requests. > I needed to do this for myself anyway, so I might as well contribute it to > the project. > At the moment, I have no plans to write an XSD for the config documents, but > it wouldn't be a bad idea. > TODO: change the schema URL. I'm guessing that Apache already has some sort > of naming convention for these? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[
https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790941#action_12790941
]
Chris A. Mattmann commented on SOLR-17:
---
{quote}
Chris, it seems that you are taking my comment personally. Please don't; it is
not my intention to ridicule anyone's efforts.
{quote}
I wouldn't say I took it personally -- as I said, I'm not sure I appreciated
the tone of the comment. A one-liner, that's curt, provides no background (lest
only an opinion), and that sounds like ridicule will elicit such a response in
many cases, see Netiquette Guidelines:
http://tools.ietf.org/html/rfc1855
{quote}
As you can see, this issue has been open for some time now and a major reason
is that we have never found a good use for an XSD. I'm merely trying to say
that it seems like we're trying to find use-cases for a solution instead of
starting with an actual need.
{quote}
Sure, judging by its issue number (17), I could tell it has been open for a
while. The ongoing conversation regarding SOLR-1586, see here:
http://www.lucidimagination.com/search/document/7094af4a3aa8bc03/namespaces_in_response_solr_1586
led me to this issue, as pointed out by Hoss. There _have_ been some relevant
discussions that have come up regarding XSD's, which was my point. So, I'm not
sure that we're _trying_ to find anything -- the discussion presented itself on
its own. Furthermore, even if the discussion hadn't occured, it doesn't seem
very contribution friendly to ignore something that clearly adds value to a
group of people. XML and XSD people exist and have their tools (as I noted
above, Doxygen, XMLSpy, etc.) for doing validation, and for generating sample
XML files, for designing XML, etc.. Just because there aren't a lot of votes on
the issue, or lots of mail traffic, it doesn't mean that the issue should not
get attention. I'm not sure what's so controversial about adding an XSD to the
SOLR trunk. Hence my point in calling attention to this issue. There's been a
patch available for quite some time. What's missing from the patch to get this
contribution into the trunk?
{quote}
My point is that Solr can use it we want to but Solr certainly does not need to
use it. I don't think we gain much by an XSD.
{quote}
I agree that SOLR, from a code/API/functionality perspective, does not _need_
to use it. However, it would not hurt anything to add the XSD as part of the
trunk for those that would like to download it and use it to understand how to
write additional SOLR XML consuming clients. Or for those that would like to
validate SOLR XML responses they receive. This isn't outside of the ordinary at
all, and I think only adds value, and doesn't take any away. If the concern is
maintaining it, I'd be happy to do so. I'm sure there are others that would
contribute as well.
> XSD for solr requests/responses
> ---
>
> Key: SOLR-17
> URL: https://issues.apache.org/jira/browse/SOLR-17
> Project: Solr
> Issue Type: Improvement
>Reporter: Mike Baranczak
>Priority: Minor
> Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd,
> UselessRequestHandler.java
>
>
> Attaching an XML schema definition for the responses and the update requests.
> I needed to do this for myself anyway, so I might as well contribute it to
> the project.
> At the moment, I have no plans to write an XSD for the config documents, but
> it wouldn't be a bad idea.
> TODO: change the schema URL. I'm guessing that Apache already has some sort
> of naming convention for these?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1658) Negative query weirdness
[ https://issues.apache.org/jira/browse/SOLR-1658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790930#action_12790930 ] Yonik Seeley commented on SOLR-1658: I agree. Extended dismax already implements this. It comes down to needing a flag... sometimes you want pure negative queries (when parsing query parts for example) and sometimes you don't. We should just add a boolean flag to SolrQueryParser. *But* we don't want to do this for the top level for filter queries - as an optimization, solr currently caches -foo:x the same as foo:x and if we always handled negative queries at the QP level, it would disable that. > Negative query weirdness > > > Key: SOLR-1658 > URL: https://issues.apache.org/jira/browse/SOLR-1658 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 >Reporter: David Bowen > > In the standard Solr example, the queries > # adapter AND NOT power > # adapter AND (NOT power) > are different. The second will never return any results. I find this > surprising. I think the second query should be the same as the first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1660) capitalizationfilter crashes if you use the maxWordCountOption
capitalizationfilter crashes if you use the maxWordCountOption -- Key: SOLR-1660 URL: https://issues.apache.org/jira/browse/SOLR-1660 Project: Solr Issue Type: Bug Components: Schema and Analysis Affects Versions: 1.4 Reporter: Robert Muir Attachments: SOLR-1660.patch because arrayCopys into null. if you want a testcase i can yank it out of in-progress patch from SOLR-1657, but i think its obvious. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1660) capitalizationfilter crashes if you use the maxWordCountOption
[ https://issues.apache.org/jira/browse/SOLR-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-1660: -- Attachment: SOLR-1660.patch > capitalizationfilter crashes if you use the maxWordCountOption > -- > > Key: SOLR-1660 > URL: https://issues.apache.org/jira/browse/SOLR-1660 > Project: Solr > Issue Type: Bug > Components: Schema and Analysis >Affects Versions: 1.4 >Reporter: Robert Muir > Attachments: SOLR-1660.patch > > > because arrayCopys into null. > if you want a testcase i can yank it out of in-progress patch from SOLR-1657, > but i think its obvious. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[ https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790910#action_12790910 ] Shalin Shekhar Mangar commented on SOLR-17: --- Chris, it seems that you are taking my comment personally. Please don't; it is not my intention to ridicule anyone's efforts. As you can see, this issue has been open for some time now and a major reason is that we have never found a good use for an XSD. I'm merely trying to say that it seems like we're trying to _find_ use-cases for a solution instead of starting with an actual need. My point is that Solr can use it we _want_ to but Solr certainly does not _need_ to use it. I don't think we gain much by an XSD. > XSD for solr requests/responses > --- > > Key: SOLR-17 > URL: https://issues.apache.org/jira/browse/SOLR-17 > Project: Solr > Issue Type: Improvement >Reporter: Mike Baranczak >Priority: Minor > Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd, > UselessRequestHandler.java > > > Attaching an XML schema definition for the responses and the update requests. > I needed to do this for myself anyway, so I might as well contribute it to > the project. > At the moment, I have no plans to write an XSD for the config documents, but > it wouldn't be a bad idea. > TODO: change the schema URL. I'm guessing that Apache already has some sort > of naming convention for these? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1659) Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 +
[ https://issues.apache.org/jira/browse/SOLR-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1659: -- Attachment: SOLR-1659.patch A quick, rough stab at everything *but* analyzer stuff (SOLR-1657), test class stuff, and a compression workaround (which Lucene has pulled). > Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 + > --- > > Key: SOLR-1659 > URL: https://issues.apache.org/jira/browse/SOLR-1659 > Project: Solr > Issue Type: Task >Reporter: Mark Miller > Attachments: SOLR-1659.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-1659) Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 +
Get off deprecated Lucene API's to clear the way for a move to Lucene 3.0 + --- Key: SOLR-1659 URL: https://issues.apache.org/jira/browse/SOLR-1659 Project: Solr Issue Type: Task Reporter: Mark Miller -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1657) convert the rest of solr to use the new tokenstream API
[ https://issues.apache.org/jira/browse/SOLR-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790865#action_12790865 ] Robert Muir commented on SOLR-1657: --- bq. + test classes that use old stuff for testing in fact I am working on the tests first. In my opinion what we should do is take the functionality of lucene's BaseTokenStreamTestCase and add it to BaseTokenTestCase. Perhaps this old stuff can be implemented on top of assertTokenStreamContents, assertAnalyzesTo, etc, or we can change the tests. Either way, my reasoning is that this logic is very careful about ensuring that tokenstreams behave properly, it inserts garbage data to make sure that attributes are cleared correctly, etc, etc. > convert the rest of solr to use the new tokenstream API > --- > > Key: SOLR-1657 > URL: https://issues.apache.org/jira/browse/SOLR-1657 > Project: Solr > Issue Type: Task >Reporter: Robert Muir > > org.apache.solr.analysis: > BufferedTokenStream > -> CommonGramsFilter > -> CommonGramsQueryFilter > -> RemoveDuplicatesTokenFilter > CapitalizationFilterFactory > HyphenatedWordsFilter > LengthFilter (deprecated, remove) > PatternTokenizerFactory (remove deprecated methods) > SynonymFilter > SynonymFilterFactory > WordDelimiterFilter > org.apache.solr.handler: > AnalysisRequestHandler > AnalysisRequestHandlerBase > org.apache.solr.handler.component: > QueryElevationComponent > SpellCheckComponent > org.apache.solr.highlight: > DefaultSolrHighlighter > org.apache.solr.search: > FieldQParserPlugin > org.apache.solr.spelling: > SpellingQueryConverter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1657) convert the rest of solr to use the new tokenstream API
[ https://issues.apache.org/jira/browse/SOLR-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790860#action_12790860 ] Mark Miller commented on SOLR-1657: --- + test classes that use old stuff for testing ;) > convert the rest of solr to use the new tokenstream API > --- > > Key: SOLR-1657 > URL: https://issues.apache.org/jira/browse/SOLR-1657 > Project: Solr > Issue Type: Task >Reporter: Robert Muir > > org.apache.solr.analysis: > BufferedTokenStream > -> CommonGramsFilter > -> CommonGramsQueryFilter > -> RemoveDuplicatesTokenFilter > CapitalizationFilterFactory > HyphenatedWordsFilter > LengthFilter (deprecated, remove) > PatternTokenizerFactory (remove deprecated methods) > SynonymFilter > SynonymFilterFactory > WordDelimiterFilter > org.apache.solr.handler: > AnalysisRequestHandler > AnalysisRequestHandlerBase > org.apache.solr.handler.component: > QueryElevationComponent > SpellCheckComponent > org.apache.solr.highlight: > DefaultSolrHighlighter > org.apache.solr.search: > FieldQParserPlugin > org.apache.solr.spelling: > SpellingQueryConverter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1658) Negative query weirdness
Negative query weirdness Key: SOLR-1658 URL: https://issues.apache.org/jira/browse/SOLR-1658 Project: Solr Issue Type: Bug Components: search Affects Versions: 1.4 Reporter: David Bowen In the standard Solr example, the queries # adapter AND NOT power # adapter AND (NOT power) are different. The second will never return any results. I find this surprising. I think the second query should be the same as the first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1657) convert the rest of solr to use the new tokenstream API
convert the rest of solr to use the new tokenstream API --- Key: SOLR-1657 URL: https://issues.apache.org/jira/browse/SOLR-1657 Project: Solr Issue Type: Task Reporter: Robert Muir org.apache.solr.analysis: BufferedTokenStream -> CommonGramsFilter -> CommonGramsQueryFilter -> RemoveDuplicatesTokenFilter CapitalizationFilterFactory HyphenatedWordsFilter LengthFilter (deprecated, remove) PatternTokenizerFactory (remove deprecated methods) SynonymFilter SynonymFilterFactory WordDelimiterFilter org.apache.solr.handler: AnalysisRequestHandler AnalysisRequestHandlerBase org.apache.solr.handler.component: QueryElevationComponent SpellCheckComponent org.apache.solr.highlight: DefaultSolrHighlighter org.apache.solr.search: FieldQParserPlugin org.apache.solr.spelling: SpellingQueryConverter -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1630) StringIndexOutOfBoundsException in SpellCheckComponent
[
https://issues.apache.org/jira/browse/SOLR-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790816#action_12790816
]
Guillaume Lebourgeois commented on SOLR-1630:
-
Hi, it seems I've encountered the same bug. All queries using the - char, or
the _ char make solr throw an exception when using the SpellCheckComponent. It
is possible to temporary fix it by setting accuracy parameter to 1.0 (which
makes the spellcheck pretty useless, but avoid exceptions).
> StringIndexOutOfBoundsException in SpellCheckComponent
> --
>
> Key: SOLR-1630
> URL: https://issues.apache.org/jira/browse/SOLR-1630
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis, spellchecker
>Affects Versions: 1.4
> Environment: Solr 1.4
> Lucene 2.9.1
> Win XP
> java version "1.6.0_14"
>Reporter: Robin Wojciki
>Assignee: Shalin Shekhar Mangar
> Attachments: bug.xml, schema.xml, solrconfig.xml
>
>
> For some documents/search strings, the SpellCheckComponent throws
> StringIndexOutOfBoundsException
> See: http://www.lucidimagination.com/search/document/3be6555227e031fc/
> h2. Replication
> * Save attached schema.xml and solrconfig.xml in
> apache-solr-1.4.0/example/solr/conf
> * Start Solr
> * Index attached bug.xml
> * Query [http://localhost:8983/solr/select/?q=awehjse-wjkekw]
> It throws a StringIndexOutOfBoundsException
> {noformat} String index out of range: -7
> java.lang.StringIndexOutOfBoundsException: String index out of range: -7
> at java.lang.AbstractStringBuilder.replace(Unknown Source)
> at java.lang.StringBuilder.replace(Unknown Source)
> at
> org.apache.solr.handler.component.SpellCheckComponent.toNamedList(SpellCheckComponent.java:248)
> at
> org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:143)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> {noformat}
--
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=12790814#action_12790814 ] Yonik Seeley commented on SOLR-1277: I think I'll try to start implementing some bootstrap code - it will make it simple for new users to get a cluster up and running, in addition to making further development easier. I'm thinking of enabling via -Dboostrap_collection that will do everything necessary including copying local files to 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, SOLR-1277.patch, > SOLR-1277.patch, SOLR-1277.patch, zookeeper-3.2.1.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-17) XSD for solr requests/responses
[ https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790787#action_12790787 ] Chris A. Mattmann commented on SOLR-17: --- In what way? And furthermore, I don't appreciate the tone of your comment. Is this the way you, as a committer, encourage people to contribute to SOLR? I hope not. > XSD for solr requests/responses > --- > > Key: SOLR-17 > URL: https://issues.apache.org/jira/browse/SOLR-17 > Project: Solr > Issue Type: Improvement >Reporter: Mike Baranczak >Priority: Minor > Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd, > UselessRequestHandler.java > > > Attaching an XML schema definition for the responses and the update requests. > I needed to do this for myself anyway, so I might as well contribute it to > the project. > At the moment, I have no plans to write an XSD for the config documents, but > it wouldn't be a bad idea. > TODO: change the schema URL. I'm guessing that Apache already has some sort > of naming convention for these? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: NPE in MoreLikeThis referenced doc not found and debugQuery=True
On Thu, Dec 10, 2009 at 6:34 PM, david.stu...@progressivealliance.co.uk < david.stu...@progressivealliance.co.uk> wrote: > Hi All, > > When I do a specific MLT search on a document with debugQuery=True I am > getting > a NullPoniterException both on screen and in my catalina logs. The query is > as > follows > > > http://localhost:8080/solr2/select/?mlt.minwl=3&mlt.fl=body&mlt.mintf=1&mlt.maxwl=15&mlt.maxqt=20&version=1.2&rows=5&mlt.mindf=1&fl=nid,title,path,url,digest,teaser&start=0&q=nid:16036&qt=mlt&debugQuery=true > > Is this desired behavior? > > java.lang.RuntimeException: java.lang.NullPointerException > at org.apache.solr.search.QueryParsing.toString(QueryParsing.java:470) > at > > org.apache.solr.util.SolrPluginUtils.doStandardDebug(SolrPluginUtils.java:399) > at > > org.apache.solr.handler.MoreLikeThisHandler.handleRequestBody(MoreLikeThisHandle > r.java:189) > at > > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java > :131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1204) > at > > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303) > at > > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232) > at > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilt > erChain.java:235) > at > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain. > java:206) > at > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:2 > 33) > at > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:1 > 91) > at > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) > at > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) > at > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109 > ) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) > at > > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Pr > otocol.java:583) > at > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) > at java.lang.Thread.run(Thread.java:637) > Caused by: java.lang.NullPointerException > at org.apache.solr.search.QueryParsing.toString(QueryParsing.java:439) > at org.apache.solr.search.QueryParsing.toString(QueryParsing.java:467) > ... 18 more > > > Apologies if this has been discussed or deemed desired, but thought I would > mention this and offer a patch as a entry into helping with the project. > > Thanks for reporting this Dave. It'd be great if you can open a Jira issue and attach a unit test reproducing this issue. A fix would be even better :) http://wiki.apache.org/solr/HowToContribute -- Regards, Shalin Shekhar Mangar.
Jetty/Solr unresponsive
Hi,
I'm trying to package SOLR 1.4 for debian. When running test tests, many of
them fail with "Jetty/Solr unresponsive" after something about 121 seconds
(timeout?).
a) Why? Is it possible, that I'm expected to run the tests as root?
b) I've to disable all tests, that access the internet when building the
debian package. As I understand, JUnit doesn't have a way to annotate tests
with a tag ("accesses-internet") and then have the test runner disable tests
with certain tags?
c) When I've run the tests with ant test, where do I have a summary of failed
tests? Do I've to scan through the output of ant test?
Thanks for your help,
Thomas Koch, http://www.koch.ro
[jira] Commented: (SOLR-1532) allow StreamingUpdateSolrServer to use a provided HttpClient
[ https://issues.apache.org/jira/browse/SOLR-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790766#action_12790766 ] gabriele renzi commented on SOLR-1532: -- thanks toy you, I was starting to lose hope :) > allow StreamingUpdateSolrServer to use a provided HttpClient > > > Key: SOLR-1532 > URL: https://issues.apache.org/jira/browse/SOLR-1532 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 1.4 >Reporter: gabriele renzi >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1532.patch, SOLR-1532.patch > > > As of r830319 StreamingUpdateSolrServer does not allow calling code to > provide an HttpClient, and this implies client code cannot reuse an existing > connection manager, the patch adds a new constructor and refactors the old > one to use this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1653) add PatternReplaceCharFilter
[
https://issues.apache.org/jira/browse/SOLR-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi resolved SOLR-1653.
--
Resolution: Fixed
Committed revision 890798. Thanks Shalin and Noble for taking time to review
the patch.
> add PatternReplaceCharFilter
>
>
> Key: SOLR-1653
> URL: https://issues.apache.org/jira/browse/SOLR-1653
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Affects Versions: 1.4
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1653.patch, SOLR-1653.patch
>
>
> Add a new CharFilter that uses a regular expression for the target of replace
> string in char stream.
> Usage:
> {code:title=schema.xml}
> positionIncrementGap="100" >
>
> groupedPattern="([nN][oO]\.)\s*(\d+)"
> replaceGroups="1,2" blockDelimiters=":;"/>
> mapping="mapping-ISOLatin1Accent.txt"/>
>
>
>
> {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-1131) Allow a single field type to index multiple fields
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790745#action_12790745 ] Grant Ingersoll commented on SOLR-1131: --- OK, I see what you mean. I don't think we should add it onto the interface, though. I think it can just be handled by changing the signature of the createField method that takes in the delegatedFieldType. > Allow a single field type to index multiple fields > -- > > Key: SOLR-1131 > URL: https://issues.apache.org/jira/browse/SOLR-1131 > Project: Solr > Issue Type: New Feature > Components: Schema and Analysis >Reporter: Ryan McKinley >Assignee: Grant Ingersoll > Fix For: 1.5 > > Attachments: SOLR-1131-IndexMultipleFields.patch, > SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, > SOLR-1131.patch, SOLR-1131.patch > > > In a few special cases, it makes sense for a single "field" (the concept) to > be indexed as a set of Fields (lucene Field). Consider SOLR-773. The > concept "point" may be best indexed in a variety of ways: > * geohash (sincle lucene field) > * lat field, lon field (two double fields) > * cartesian tiers (a series of fields with tokens to say if it exists within > that region) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1131:
Attachment: SOLR-1131.patch
I guess Noble was referring to something like what is done in this patch.
# DelegatingFieldType has a new method:
{code}
public SchemaField[] getSubFields(SchemaField mainField);
{code}
# PointType and PlusMinusField implement this new method. It is not the
prettiest way but this is one way to do it.
# With this approach, we can get the names from the subFields wherever the name
is used (not implemented in this patch).
The PlusMinusField is actually a field type and not a field so we should
probably rename it to PlusMinusFieldType.
> Allow a single field type to index multiple fields
> --
>
> Key: SOLR-1131
> URL: https://issues.apache.org/jira/browse/SOLR-1131
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Ryan McKinley
>Assignee: Grant Ingersoll
> Fix For: 1.5
>
> Attachments: SOLR-1131-IndexMultipleFields.patch,
> SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt,
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch,
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch,
> SOLR-1131.patch, SOLR-1131.patch
>
>
> In a few special cases, it makes sense for a single "field" (the concept) to
> be indexed as a set of Fields (lucene Field). Consider SOLR-773. The
> concept "point" may be best indexed in a variety of ways:
> * geohash (sincle lucene field)
> * lat field, lon field (two double fields)
> * cartesian tiers (a series of fields with tokens to say if it exists within
> that region)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790728#action_12790728 ] Grant Ingersoll commented on SOLR-1131: --- bq. Even if SchemaField is final we can precreate and cache the SchemaField objects because the properties of the synthetic field is known in advance. For instance, if you have a dimension of 2 ,the PointType instance will always have 2 well known synthetic names and types that can be created well in advance and they can be reused True, but you need to also be able to change the name and it needs to be able to rely on the existing createField signature, which uses these values on the SchemaField. Earlier patches had a separate, internal createField() method that took in all the options (thus not requiring the SF at all) but they don't work for the delegation. I'm open to ideas, though, so throw up some code. > Allow a single field type to index multiple fields > -- > > Key: SOLR-1131 > URL: https://issues.apache.org/jira/browse/SOLR-1131 > Project: Solr > Issue Type: New Feature > Components: Schema and Analysis >Reporter: Ryan McKinley >Assignee: Grant Ingersoll > Fix For: 1.5 > > Attachments: SOLR-1131-IndexMultipleFields.patch, > SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, > SOLR-1131.patch > > > In a few special cases, it makes sense for a single "field" (the concept) to > be indexed as a set of Fields (lucene Field). Consider SOLR-773. The > concept "point" may be best indexed in a variety of ways: > * geohash (sincle lucene field) > * lat field, lon field (two double fields) > * cartesian tiers (a series of fields with tokens to say if it exists within > that region) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790720#action_12790720 ] Noble Paul commented on SOLR-1131: -- bq.Because there is no way to change the name on a SchemaField w/o changing SchemaField to be non-final. I don't think SchemaField should be non-final. Even if SchemaField is final we can precreate and cache the SchemaField objects because the properties of the synthetic field is known in advance. For instance, if you have a dimension of 2 ,the PointType instance will always have 2 well known synthetic names and types that can be created well in advance and they can be reused > Allow a single field type to index multiple fields > -- > > Key: SOLR-1131 > URL: https://issues.apache.org/jira/browse/SOLR-1131 > Project: Solr > Issue Type: New Feature > Components: Schema and Analysis >Reporter: Ryan McKinley >Assignee: Grant Ingersoll > Fix For: 1.5 > > Attachments: SOLR-1131-IndexMultipleFields.patch, > SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, > SOLR-1131.patch > > > In a few special cases, it makes sense for a single "field" (the concept) to > be indexed as a set of Fields (lucene Field). Consider SOLR-773. The > concept "point" may be best indexed in a variety of ways: > * geohash (sincle lucene field) > * lat field, lon field (two double fields) > * cartesian tiers (a series of fields with tokens to say if it exists within > that region) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1655) Remove default datasource MockDataSource from DIH requestHandler config in dataimport-solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1655. -- Resolution: Fixed committed r890775 Thanks Akshay > Remove default datasource MockDataSource from DIH requestHandler config in > dataimport-solrconfig.xml > > > Key: SOLR-1655 > URL: https://issues.apache.org/jira/browse/SOLR-1655 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Akshay K. Ukey >Assignee: Noble Paul >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1655.patch, SOLR-1655.patch > > > Presence of MockDataSource as default datasource for DataImportHandler > requestHandler in dataimport-solrconfig.xml (which is used by DIH tests) > requires name attribute for dataSource tag to be present in dataConfig. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields
[ https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790715#action_12790715 ] Grant Ingersoll commented on SOLR-1131: --- bq. It is not clear as to why can't the 'sf' instance be cached and reused? Because there is no way to change the name on a SchemaField w/o changing SchemaField to be non-final. I don't think SchemaField should be non-final. bq. Why do we have a map for flags why not use a bitset? Yeah, we could add a new method that takes a bitset, b/c I believe that is what is used under the hood anyway. > Allow a single field type to index multiple fields > -- > > Key: SOLR-1131 > URL: https://issues.apache.org/jira/browse/SOLR-1131 > Project: Solr > Issue Type: New Feature > Components: Schema and Analysis >Reporter: Ryan McKinley >Assignee: Grant Ingersoll > Fix For: 1.5 > > Attachments: SOLR-1131-IndexMultipleFields.patch, > SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, > SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, > SOLR-1131.patch > > > In a few special cases, it makes sense for a single "field" (the concept) to > be indexed as a set of Fields (lucene Field). Consider SOLR-773. The > concept "point" may be best indexed in a variety of ways: > * geohash (sincle lucene field) > * lat field, lon field (two double fields) > * cartesian tiers (a series of fields with tokens to say if it exists within > that region) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-919) Cache and reuse the SolrConfig
[ https://issues.apache.org/jira/browse/SOLR-919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-919: Attachment: SOLR-919.patch untested patch > Cache and reuse the SolrConfig > -- > > Key: SOLR-919 > URL: https://issues.apache.org/jira/browse/SOLR-919 > Project: Solr > Issue Type: Improvement > Components: multicore >Reporter: Noble Paul >Assignee: Noble Paul > Fix For: 1.5 > > Attachments: SOLR-919.patch > > > If there are 1000's of cores the no:of times we need to load and parse the > solrconfig.xml is going to be very expensive. It is desirable to just create > one instance of SolrConfig object and re-use it across cores -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1655) Remove default datasource MockDataSource from DIH requestHandler config in dataimport-solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akshay K. Ukey updated SOLR-1655: - Attachment: SOLR-1655.patch Patch in sync with trunk > Remove default datasource MockDataSource from DIH requestHandler config in > dataimport-solrconfig.xml > > > Key: SOLR-1655 > URL: https://issues.apache.org/jira/browse/SOLR-1655 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Akshay K. Ukey >Assignee: Noble Paul >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1655.patch, SOLR-1655.patch > > > Presence of MockDataSource as default datasource for DataImportHandler > requestHandler in dataimport-solrconfig.xml (which is used by DIH tests) > requires name attribute for dataSource tag to be present in dataConfig. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1532) allow StreamingUpdateSolrServer to use a provided HttpClient
[ https://issues.apache.org/jira/browse/SOLR-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-1532. - Resolution: Fixed Assignee: Shalin Shekhar Mangar Committed revision 890769. Thanks Gabriele! > allow StreamingUpdateSolrServer to use a provided HttpClient > > > Key: SOLR-1532 > URL: https://issues.apache.org/jira/browse/SOLR-1532 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 1.4 >Reporter: gabriele renzi >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1532.patch, SOLR-1532.patch > > > As of r830319 StreamingUpdateSolrServer does not allow calling code to > provide an HttpClient, and this implies client code cannot reuse an existing > connection manager, the patch adds a new constructor and refactors the old > one to use this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1532) allow StreamingUpdateSolrServer to use a provided HttpClient
[ https://issues.apache.org/jira/browse/SOLR-1532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1532: Attachment: SOLR-1532.patch Synced to trunk. I'll commit this shortly. > allow StreamingUpdateSolrServer to use a provided HttpClient > > > Key: SOLR-1532 > URL: https://issues.apache.org/jira/browse/SOLR-1532 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 1.4 >Reporter: gabriele renzi >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1532.patch, SOLR-1532.patch > > > As of r830319 StreamingUpdateSolrServer does not allow calling code to > provide an HttpClient, and this implies client code cannot reuse an existing > connection manager, the patch adds a new constructor and refactors the old > one to use this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-630) Spellchecker should not be case-sensitive and should be stopwords-aware
[ https://issues.apache.org/jira/browse/SOLR-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-630. Resolution: Invalid I don't think this is a problem. As Alex noted, it is all a matter of configuring your analyzers and spell checker correctly. > Spellchecker should not be case-sensitive and should be stopwords-aware > --- > > Key: SOLR-630 > URL: https://issues.apache.org/jira/browse/SOLR-630 > Project: Solr > Issue Type: Bug > Components: spellchecker >Reporter: Otis Gospodnetic >Priority: Minor > Fix For: 1.5 > > > Here are 2 more bugs: > 1) > Search for: > united states of America > Suggests: > united states oft America > It looks like the SC doesn't check stopwords, and "of" is a stopword. Thus, > it does not exist in the index, > but "oft" does, so SC suggests "oft" and thinks "of" is misspelled. I think > the SC component should check the list of > stopwords, too, no? > 2) > Search for: > united states of America > Suggests: > united states oftAmericaa > The of->oft is described above. But note how SC suggested America->Americaa, > but it didn't do that for "america". > This looks like case-sensitivity problem. Shouldn't the SC be > case-insensitive? > I can't produce a patch now (no src handy), so I'm hoping Grant or somebody > else can do it based on this report. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1654) Add TikaEntityProcessor example to the DIHExample
[ https://issues.apache.org/jira/browse/SOLR-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1654. -- Resolution: Fixed Assignee: Noble Paul committed r890761 Thanks Akshay > Add TikaEntityProcessor example to the DIHExample > - > > Key: SOLR-1654 > URL: https://issues.apache.org/jira/browse/SOLR-1654 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Akshay K. Ukey >Assignee: Noble Paul >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1654.patch, SOLR-1654.patch > > > As part of "ant example" a sample tika setup should be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1654) Add TikaEntityProcessor example to the DIHExample
[ https://issues.apache.org/jira/browse/SOLR-1654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akshay K. Ukey updated SOLR-1654: - Attachment: SOLR-1654.patch Patch with slight change in the tika example solrconfig.xml and tika-data-config.xml > Add TikaEntityProcessor example to the DIHExample > - > > Key: SOLR-1654 > URL: https://issues.apache.org/jira/browse/SOLR-1654 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Akshay K. Ukey >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1654.patch, SOLR-1654.patch > > > As part of "ant example" a sample tika setup should be generated. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1212) TestNG Test Case
[ https://issues.apache.org/jira/browse/SOLR-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790648#action_12790648 ] Shalin Shekhar Mangar commented on SOLR-1212: - I'm not sure what to do with this. We don't need to ship this with our releases. Perhaps it is best to mark this as "Won't Fix" and link this issue to http://wiki.apache.org/solr/TestingSolr so that people who use TestNG can use this code if necessary. > TestNG Test Case > - > > Key: SOLR-1212 > URL: https://issues.apache.org/jira/browse/SOLR-1212 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.4 > Environment: Java 6 >Reporter: Kay Kay > Fix For: 1.5 > > Attachments: SOLR-1212.patch, testng-5.9-jdk15.jar > > Original Estimate: 1h > Remaining Estimate: 1h > > TestNG equivalent of AbstractSolrTestCase , without using JUnit altogether . > New Class created: AbstractSolrNGTest > LICENSE.txt , NOTICE.txt modified as appropriate. ( TestNG under Apache > License 2.0 ) > TestNG 5.9-jdk15 added to lib. > Justification: In some workplaces - people are moving towards TestNG and > take out JUnit altogether from the classpath. Hence useful in those cases. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1645) Add human content-type
[ https://issues.apache.org/jira/browse/SOLR-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1645: Fix Version/s: (was: 1.4) 1.5 1.4 has been released. Marking for 1.5 instead. > Add human content-type > -- > > Key: SOLR-1645 > URL: https://issues.apache.org/jira/browse/SOLR-1645 > Project: Solr > Issue Type: Improvement > Components: contrib - Solr Cell (Tika extraction) >Affects Versions: 1.4 >Reporter: Khalid Yagoubi > Fix For: 1.5 > > > Idea is to allow Solr-Cell to "calculate" the human content-type from the > extracted content-type and map it to a field in the schema. > So the user can search on "media: image" or "media:video" > Idea : > 1) Hardcode a hashmap in somewhere in extraction classes and get human > content-type from extracted content-type. I Think to SolrContentHandler.java > 2) Write an xml file where we can put a mapping like in tika-config.xml for > parsers > 3) Use tika-config.xml to get all supported mime-types -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1006) ConcurrentLRUCache API improvements
[ https://issues.apache.org/jira/browse/SOLR-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1006: Description: This is to make ConcurrentLRUCache more consistent with LinkedHashMap behavior # remove must not call evictionListener.evictedEntry() # -EvictionListener must be able prevent eviction of an element by returning a false.- # Add a new method Map getOldestItems(long n) was: This is to make ConcurrentLRUCache more consistent with LinkedHashMap behavior # remove must not call evictionListener.evictedEntry() # EvictionListener must be able prevent eviction of an element by returning a false. # Add a new method Map getOldestItems(long n) I don't have a a use-case for this anymore. Let us close this issue. > ConcurrentLRUCache API improvements > --- > > Key: SOLR-1006 > URL: https://issues.apache.org/jira/browse/SOLR-1006 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1006.patch, SOLR-1006.patch > > > This is to make ConcurrentLRUCache more consistent with LinkedHashMap behavior > # remove must not call evictionListener.evictedEntry() > # -EvictionListener must be able prevent eviction of an element by returning > a false.- > # Add a new method Map getOldestItems(long n) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-1006) ConcurrentLRUCache API improvements
[ https://issues.apache.org/jira/browse/SOLR-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar closed SOLR-1006. --- Resolution: Fixed Fix Version/s: (was: 1.5) 1.4 > ConcurrentLRUCache API improvements > --- > > Key: SOLR-1006 > URL: https://issues.apache.org/jira/browse/SOLR-1006 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1006.patch, SOLR-1006.patch > > > This is to make ConcurrentLRUCache more consistent with LinkedHashMap behavior > # remove must not call evictionListener.evictedEntry() > # -EvictionListener must be able prevent eviction of an element by returning > a false.- > # Add a new method Map getOldestItems(long n) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1006) ConcurrentLRUCache API improvements
[ https://issues.apache.org/jira/browse/SOLR-1006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790644#action_12790644 ] Shalin Shekhar Mangar edited comment on SOLR-1006 at 12/15/09 10:18 AM: I don't have a use-case for this anymore. Let us close this issue. was (Author: shalinmangar): I don't have a a use-case for this anymore. Let us close this issue. > ConcurrentLRUCache API improvements > --- > > Key: SOLR-1006 > URL: https://issues.apache.org/jira/browse/SOLR-1006 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1006.patch, SOLR-1006.patch > > > This is to make ConcurrentLRUCache more consistent with LinkedHashMap behavior > # remove must not call evictionListener.evictedEntry() > # -EvictionListener must be able prevent eviction of an element by returning > a false.- > # Add a new method Map getOldestItems(long n) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790635#action_12790635
]
Noble Paul edited comment on SOLR-1131 at 12/15/09 10:06 AM:
-
in FieldType#createFields(SchemaField field, FieldType delegatedType, String
storageVal, boost, String ... externalVals)
{code:java}
String name = field.getName();
Map props = new HashMap();
//Just set these, delegate everything else to the field type
props.put("indexed", "true");
props.put("stored", "false");
//props.put("omitNorms", "true");
//props.put("tokenized", "false");
if (field.indexed()) {
for (int j = 0; j < externalVals.length; j++) {
//SchemaField is final, as is name, so we need to recreate each time
//put the counter before the separator, b/c dynamic fields can't be
asterisks on both the front and the end of the String
SchemaField sf = SchemaField.create(name + "_" + j +
POLY_FIELD_SEPARATOR + delegatedType.typeName, delegatedType, props);
//QUESTION: should we allow for vectors, etc? Not sure that it makes
sense
results[j] = delegatedType.createField(sf, externalVals[j], boost);
}
}
{code}
It is not clear as to why can't the 'sf' instance be cached and reused?
we can also avoid creating the synthetic field name at query time in
PointField#.getFieldQuery
Why do we have a map for flags why not use a bitset?
was (Author: noble.paul):
in FieldType#createFields(SchemaField field, FieldType delegatedType,
String storageVal, boost, String ... externalVals)
{code:java}
String name = field.getName();
Map props = new HashMap();
//Just set these, delegate everything else to the field type
props.put("indexed", "true");
props.put("stored", "false");
//props.put("omitNorms", "true");
//props.put("tokenized", "false");
if (field.indexed()) {
for (int j = 0; j < externalVals.length; j++) {
//SchemaField is final, as is name, so we need to recreate each time
//put the counter before the separator, b/c dynamic fields can't be
asterisks on both the front and the end of the String
SchemaField sf = SchemaField.create(name + "_" + j +
POLY_FIELD_SEPARATOR + delegatedType.typeName, delegatedType, props);
//QUESTION: should we allow for vectors, etc? Not sure that it makes
sense
results[j] = delegatedType.createField(sf, externalVals[j], boost);
}
}
{code}
It is not clear as to why can't the 'sf' instance be cached and reused?
Why do we have a map for flags why not use a bitset?
> Allow a single field type to index multiple fields
> --
>
> Key: SOLR-1131
> URL: https://issues.apache.org/jira/browse/SOLR-1131
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Ryan McKinley
>Assignee: Grant Ingersoll
> Fix For: 1.5
>
> Attachments: SOLR-1131-IndexMultipleFields.patch,
> SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt,
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch,
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch,
> SOLR-1131.patch
>
>
> In a few special cases, it makes sense for a single "field" (the concept) to
> be indexed as a set of Fields (lucene Field). Consider SOLR-773. The
> concept "point" may be best indexed in a variety of ways:
> * geohash (sincle lucene field)
> * lat field, lon field (two double fields)
> * cartesian tiers (a series of fields with tokens to say if it exists within
> that region)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1131) Allow a single field type to index multiple fields
[
https://issues.apache.org/jira/browse/SOLR-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790635#action_12790635
]
Noble Paul commented on SOLR-1131:
--
in FieldType#createFields(SchemaField field, FieldType delegatedType, String
storageVal, boost, String ... externalVals)
{code:java}
String name = field.getName();
Map props = new HashMap();
//Just set these, delegate everything else to the field type
props.put("indexed", "true");
props.put("stored", "false");
//props.put("omitNorms", "true");
//props.put("tokenized", "false");
if (field.indexed()) {
for (int j = 0; j < externalVals.length; j++) {
//SchemaField is final, as is name, so we need to recreate each time
//put the counter before the separator, b/c dynamic fields can't be
asterisks on both the front and the end of the String
SchemaField sf = SchemaField.create(name + "_" + j +
POLY_FIELD_SEPARATOR + delegatedType.typeName, delegatedType, props);
//QUESTION: should we allow for vectors, etc? Not sure that it makes
sense
results[j] = delegatedType.createField(sf, externalVals[j], boost);
}
}
{code}
It is not clear as to why can't the 'sf' instance be cached and reused?
Why do we have a map for flags why not use a bitset?
> Allow a single field type to index multiple fields
> --
>
> Key: SOLR-1131
> URL: https://issues.apache.org/jira/browse/SOLR-1131
> Project: Solr
> Issue Type: New Feature
> Components: Schema and Analysis
>Reporter: Ryan McKinley
>Assignee: Grant Ingersoll
> Fix For: 1.5
>
> Attachments: SOLR-1131-IndexMultipleFields.patch,
> SOLR-1131.Mattmann.121009.patch.txt, SOLR-1131.Mattmann.121109.patch.txt,
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch,
> SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch, SOLR-1131.patch,
> SOLR-1131.patch
>
>
> In a few special cases, it makes sense for a single "field" (the concept) to
> be indexed as a set of Fields (lucene Field). Consider SOLR-773. The
> concept "point" may be best indexed in a variety of ways:
> * geohash (sincle lucene field)
> * lat field, lon field (two double fields)
> * cartesian tiers (a series of fields with tokens to say if it exists within
> that region)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-17) XSD for solr requests/responses
[ https://issues.apache.org/jira/browse/SOLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790621#action_12790621 ] Shalin Shekhar Mangar commented on SOLR-17: --- This is like a solution looking for a problem. > XSD for solr requests/responses > --- > > Key: SOLR-17 > URL: https://issues.apache.org/jira/browse/SOLR-17 > Project: Solr > Issue Type: Improvement >Reporter: Mike Baranczak >Priority: Minor > Attachments: solr-complex.xml, solr-rev2.xsd, solr.xsd, > UselessRequestHandler.java > > > Attaching an XML schema definition for the responses and the update requests. > I needed to do this for myself anyway, so I might as well contribute it to > the project. > At the moment, I have no plans to write an XSD for the config documents, but > it wouldn't be a bad idea. > TODO: change the schema URL. I'm guessing that Apache already has some sort > of naming convention for these? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-773: Comment: was deleted (was: Bonjour, Je suis absent jusqu'au 4 janvier prochain, mais répondrai au plus vite à votre message dès mon retour. Cordiales salutations, Benoît Terradillos ) > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, > lucene.tar.gz, screenshot-1.jpg, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-spatial_solr.patch, SOLR-773.patch, SOLR-773.patch, > solrGeoQuery.tar, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-773) Incorporate Local Lucene/Solr
[ https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-773: Comment: was deleted (was: Sorry for the last Post. I feel like a newbie (which I am) and regret being on holidays ;-)! Can anybody delete it (I didn't find a way...)?) > Incorporate Local Lucene/Solr > - > > Key: SOLR-773 > URL: https://issues.apache.org/jira/browse/SOLR-773 > Project: Solr > Issue Type: New Feature >Reporter: Grant Ingersoll >Assignee: Grant Ingersoll >Priority: Minor > Fix For: 1.5 > > Attachments: exampleSpatial.zip, lucene-spatial-2.9-dev.jar, > lucene.tar.gz, screenshot-1.jpg, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, > SOLR-773-spatial_solr.patch, SOLR-773.patch, SOLR-773.patch, > solrGeoQuery.tar, spatial-solr.tar.gz > > > Local Lucene has been donated to the Lucene project. It has some Solr > components, but we should evaluate how best to incorporate it into Solr. > See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
