Possible bug with AnalyzingInfixLookupFactory, FileDictionaryFactory and Context Filtering

Hi all, I asked a question on StackOverflow about a problem I was having with the suggester module, but since then I have looked into the source code of Solr, and I thinkit is a

Possible bug report—ICU Tokenizer: letter-space-number-letter tokenized inconsistently

Hi all.. Following the advice at https://issues.apache.org/jira I'm explaining my situation here before creating an issue. The short version is that the ICU tokenizer can split tokens differently after a space depending on what comes *before* the space. For example, *x 14th* is tokenized as x | 1

Re: Possible bug on LTR when using solr 8.6.3 - index out of bounds DisiPriorityQueue.add(DisiPriorityQueue.java:102)

racting-features > [2] > https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.3/solr/contrib/ltr/src/java/org/apache/solr/ltr/feature/SolrFeature.java#L243 > [3] > https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.6.3/solr/contrib/ltr/src/java/org/apache/

Possible bug on LTR when using solr 8.6.3 - index out of bounds DisiPriorityQueue.add(DisiPriorityQueue.java:102)

Hello, We are trying to update Solr from 8.3.1 to 8.6.3. On Solr 8.3.1 we are using LTR in production using a MultipleAdditiveTrees model. On Solr 8.6.3 we receive an error when we try to compute some SolrFeatures. We didn't find any pattern of the queries that fail. Example: We have the following

Re: Possible bug in cluster status - > solr 8.3

AFAIK these collection properties are not tracked that faithfully and can get out of sync, mostly because they are used only during collection CREATE and BACKUP / RESTORE and not during other collection operations or during searching / indexing. SPLITSHARD doesn’t trust them, instead it checks t

Re: Possible bug in cluster status - > solr 8.3

It seems like an issue to me. Can you open a JIRA with these details? On Fri, Nov 15, 2019 at 10:51 AM Jacek Kikiewicz wrote: > > I found interesting situation, I've created a collection with only one > replica. > Then I scaled solr-cloud cluster, and run 'addreplica' call to add 2 more. > So

Possible bug in cluster status - > solr 8.3

I found interesting situation, I've created a collection with only one replica. Then I scaled solr-cloud cluster, and run 'addreplica' call to add 2 more. So I have a collection with 3 tlog replicas, cluster status page shows them but shows also this: "core_node2":{ "

Re: install solr service possible bug

Thanks for checking and confirming Shawn. I have created JIRA https://issues.apache.org/jira/browse/SOLR-10932 On Tue, Jun 20, 2017 at 10:06 AM, Shawn Heisey wrote: > On 6/14/2017 7:47 AM, Susheel Kumar wrote: > > Can anyone confirm if this "service --version" command works ? For me > > to ins

Re: install solr service possible bug

On 6/14/2017 7:47 AM, Susheel Kumar wrote: > Can anyone confirm if this "service --version" command works ? For me > to install in SUSE distribution, "service --version" commands always > fail and abort the solr installation with printing the error "Script > requires the 'service' command" To make

Re: Possible bug in Solrj-6.6.0

osed > when the application exits. > > > > > > > > > > > > > > > > > > > > > > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Fri, Jun 16, 2017 at 2:17 AM, Aman Deep Singh < > amandeep.coo...@gmail.com&

Re: Possible bug in Solrj-6.6.0

red by multiple requests and should be closed when the application exits. Joel Bernstein http://joelsolr.blogspot.com/ On Fri, Jun 16, 2017 at 2:17 AM, Aman Deep Singh wrote: > Hi, > I think their is a possible bug in Solrj version 6.6.0 ,as streaming is not > workin

Re: Possible bug in Solrj-6.6.0

tiple requests and should be closed when the application exits. Joel Bernstein http://joelsolr.blogspot.com/ On Fri, Jun 16, 2017 at 2:17 AM, Aman Deep Singh wrote: > Hi, > I think their is a possible bug in Solrj version 6.6.0 ,as streaming is not > working > as

Possible bug in Solrj-6.6.0

Hi, I think their is a possible bug in Solrj version 6.6.0 ,as streaming is not working as i have a piece of code public Set getAllIds(String requestId, String field) { LOG.info("Now Trying to fetch all the ids from SOLR for request Id {}", requestId); Map props = n

install solr service possible bug

Hi, Can anyone confirm if this "service --version" command works ? For me to install in SUSE distribution, "service --version" commands always fail and abort the solr installation with printing the error "Script requires the 'service' command" To make it work, i had to change "service --versio

Re: Possible bug

Thanks for reporting. This was fixed by , which will be included in forthcoming Solr 6.5.1. -- Steve www.lucidworks.com > On Apr 6, 2017, at 12:54 PM, OTH wrote: > > I'm not sure if any one else had this problem, but this is a problem I had: >

Possible bug

I'm not sure if any one else had this problem, but this is a problem I had: I'm using Solr 6.4.1, on Windows, and when would run 'bin\solr delete -c ', it wouldn't work properly. It turned out it was because there was a space character which shouldn't have been there at the end of line 1380 in th

Re[2]: [possible bug]: [child] - ChildDocTransformerFactory returns top level documents nested under middle level documents when queried for the middle level ones

Thanks, Anshum! This definitely brings the result I wanted. It is just the description from ChildDocTransformerFactory docs (" This transformer returns all descendants of each parent document in a flat list nested inside the parent document .") is a bit misleading...  One should never stop

Re: [Possible Bug] 5.5.0 Startup script ignoring host parameter?

On 30/03/16 16:45, Shawn Heisey wrote: > The host parameter does not control binding to network interfaces. It > controls what hostname is published to zookeeper when running in cloud mode. Oh I see. That wasn't clear from the documentation. Might be worth adding such a parameter to the startup s

Re: [possible bug]: [child] - ChildDocTransformerFactory returns top level documents nested under middle level documents when queried for the middle level ones

I'm not the best person to comment on this so perhaps someone could chime in as well, but can you try using a wildcard for your childFilter? Something like: childFilter=type_s:doc.enriched.text.* You could also possibly enrich the document with depth information and use that for filtering out. On

[possible bug]: [child] - ChildDocTransformerFactory returns top level documents nested under middle level documents when queried for the middle level ones

I think I am observing an unexpected behavior of ChildDocTransformerFactory. The query is like this: /select?q={!parent which= "type_s:doc.enriched.text "}t ype_s:doc.enriched.text.entities +text_t:pjm +type_t:Company +relevance_tf:[0.7%20TO%20*]&fl=*,[child parentFilter=type_s:doc.enriche

Re: [Possible Bug] 5.5.0 Startup script ignoring host parameter?

On 3/30/2016 5:45 AM, Bram Van Dam wrote: > It looks like the "-h" parameter isn't being processed correctly. I want > Solr to listen on 127.0.0.1, but instead it binds to all interfaces. Am > I doing something wrong? Or am I misinterpreting what the -h parameter > is for? The host parameter does

[Possible Bug] 5.5.0 Startup script ignoring host parameter?

Hi folks, It looks like the "-h" parameter isn't being processed correctly. I want Solr to listen on 127.0.0.1, but instead it binds to all interfaces. Am I doing something wrong? Or am I misinterpreting what the -h parameter is for? Linux: # bin/solr start -h 127.0.0.1 -p 8180 # netstat -tlnp |

Re: Possible Bug - MDC handling in org.apache.solr.common.util.ExecutorUtil.MDCAwareThreadPoolExecutor.execut e(Runnable)

: Not sure I'm onboard with the first proposed solution, but yes, I'd open a : JIRA issue to discuss. we should standardize the context keys to use use fully qualified (org.apache.solr.*) java class name prefixes -- just like we do with the logger names themselves. : : - Mark : : On Mon, Jan

Re: Possible Bug - MDC handling in org.apache.solr.common.util.ExecutorUtil.MDCAwareThreadPoolExecutor.execute(Runnable)

Not sure I'm onboard with the first proposed solution, but yes, I'd open a JIRA issue to discuss. - Mark On Mon, Jan 11, 2016 at 4:01 AM Konstantin Hollerith wrote: > Hi, > > I'm using SLF4J MDC to log additional Information in my WebApp. Some of my > MDC-Parameters even include Line-Breaks. >

Possible Bug - MDC handling in org.apache.solr.common.util.ExecutorUtil.MDCAwareThreadPoolExecutor.execute(Runnable)

Hi, I'm using SLF4J MDC to log additional Information in my WebApp. Some of my MDC-Parameters even include Line-Breaks. It seems, that Solr takes _all_ MDC parameters and puts them into the Thread-Name, see org.apache.solr.common.util.ExecutorUtil.MDCAwareThreadPoolExecutor.execute(Runnable). Whe

Re: Possible bug with searchers and core swapping

On 10/23/2015 5:27 PM, Shawn Heisey wrote: > Today I noticed this on my dev server running Solr 5.2.1: > > https://www.dropbox.com/s/bt81sv35acb7q2n/searcher-from-old-corename.png?dl=0 > On the index with the problem, I am using one third-party plugin with a > schema component and an update proc

Possible bug with searchers and core swapping

Today I noticed this on my dev server running Solr 5.2.1: https://www.dropbox.com/s/bt81sv35acb7q2n/searcher-from-old-corename.png?dl=0 The name of this core is spark0live, but before the last index rebuild, it was named spark0build. My full rebuild process indexes data into build cores, then wh

Re: Real-Time get and Dynamic Fields: possible bug.

Yep, but those dynamic fields had a field type "string", so the unique indexed therm will be the entire field value and the faceted terms counted will match with exactly with each field value. Thats why I was confused. Typically I use faceting with string non tokenized field values for simple stats

Re: Real-Time get and Dynamic Fields: possible bug.

On Thu, May 14, 2015 at 12:49 PM, Luis Cappa Banda wrote: > If you don' t mark as stored a field indexed and 'facetable', I was > expecting to not be able to return their values, so faceting has no sense. Faceting does not use or retrieve stored field values. The labels faceting returns are from

Re: Real-Time get and Dynamic Fields: possible bug.

That is something I didin' t know, but I thought it was mandatory. I' ll try to explain step by step my (I think) logical way to understand it: - If a field is indexed, you can search by it. - When faceting, you have to index the field (because it can be tokenized and then you would like

Re: Real-Time get and Dynamic Fields: possible bug.

On Thu, May 14, 2015 at 10:47 AM, Luis Cappa Banda wrote: > Hi Yonik, > > Yes, they are the target from copyFields in the schema.xml. This *_target > fields are suposed to be used in some specific searchable (thus, tokenized) > fields that in the future are candidates to be faceted to return some

Re: Real-Time get and Dynamic Fields: possible bug.

Hi Yonik, Yes, they are the target from copyFields in the schema.xml. This *_target fields are suposed to be used in some specific searchable (thus, tokenized) fields that in the future are candidates to be faceted to return some stats. For example, imagine that you have a field storing a director

Re: Real-Time get and Dynamic Fields: possible bug.

Ehem, *_target ---> *_facet. 2015-05-14 16:47 GMT+02:00 Luis Cappa Banda : > Hi Yonik, > > Yes, they are the target from copyFields in the schema.xml. This *_target > fields are suposed to be used in some specific searchable (thus, tokenized) > fields that in the future are candidates to be facet

Re: Real-Time get and Dynamic Fields: possible bug.

Are the _facet fields the target of a copyField in the schema? Realtime get either gets the values from the transaction log (and if you didn't send it the values, they won't be there) or gets them from the index to try and reconstruct what was sent in. It's generally not recommended to have copyFi

Real-Time get and Dynamic Fields: possible bug.

Hi there, I have the following dynamicFields definition in my schema.xml: I' ve seen that when fetching documents with /select?q=id:whateverId, the results returned include both i18n* and *_facet fields filled. However, when using real-time request handler (/get?ids:whateverIds) the resul

Re: Weird Problem (possible bug?) with german stemming and wildcard search

Thank you very much, this information is worht it's weight in gold. So far, we've used the asterisk method because it seemed logical and straight-forward. We will slowly migrate to a version using EdgeNGramFilterFactory. Thanks a bunch. Am 07.10.2014 14:42 schrieb Alexandre Rafalovitch: On

Re: Weird Problem (possible bug?) with german stemming and wildcard search

Hi - you should not use wild cards for autocompletion, Lucene has far better tools for making very good autocompletion, also, since a wild card is a multi term query, they are not passed through your configured query time analyzer. Some other comments: - you use a porter stemmer but you should u

Re: Weird Problem (possible bug?) with german stemming and wildcard search

On 7 October 2014 08:25, Thomas Michael Engelke wrote: > So the culprit is the asterisk at the end. As far as we can read from the > docs, an asterisk is just 0 or more characters, which means that the literal > word in front of the asterisk should match the query. Not quite: http://wiki.apache.o

Weird Problem (possible bug?) with german stemming and wildcard search

I have a problem with a stemmed german field. The field definition: stored="true" required="false" multiValued="false"/> ... positionIncrementGap="100" autoGeneratePhraseQueries="true"> words="stopwords.txt"/> generateWordParts="1" generateNumberParts="1" catenateWords="1" catenateN

Re: Possible bug in Solr JoinQParserPlugin?!

Done https://issues.apache.org/jira/browse/SOLR-2824 On 12-10-2011 0:47, Chris Hostetter wrote: : I have the following query : /core1/select?q=*:*&fq={!join from=id to=childIds fromIndex=core2}specials:1&fl=id,name ... : org.apache.solr.search.JoinQParserPlugin$1.parse(JoinQParserPlugi

Re: Possible bug in Solr JoinQParserPlugin?!

: I have the following query : /core1/select?q=*:*&fq={!join from=id to=childIds fromIndex=core2}specials:1&fl=id,name ... : org.apache.solr.search.JoinQParserPlugin$1.parse(JoinQParserPlugin.java:60) : the parse is called for the filterquery on the main core (core1). Not the : core of th

Re: Possible bug in Solr JoinQParserPlugin?!

Hi Can someone help me confirm this. Or should I create a ticket? Thijs On 7-10-2011 10:10, Thijs wrote: Hi I think I might have found a bug in the JoinQParser. But I want to verify this first before creating a issue. I have two cores with 2 different schema's now I want to join between

Possible bug in Solr JoinQParserPlugin?!

Hi I think I might have found a bug in the JoinQParser. But I want to verify this first before creating a issue. I have two cores with 2 different schema's now I want to join between the 2 cores. where I filter on a field from one core that doesn't exist in the other core. core1: {childIds,

Possible bug in MoreLikeThisHandler debugging?

Hi. After upgrading to solr 3.3.0 from 1.4.0, I noticed that I couldn't get the MoreLikeThisHandler to return debugging data. I tried the debug parameters debugQuery and debug, but all I got was: true I took a look at the code for the MoreLikeThisHandler, and noted in the debbuging part that th

Possible bug in MoreLikeThisHandler debugging?

Hi. After upgrading to solr 3.3.0 from 1.4.0, I noticed that I couldn't get the MoreLikeThisHandler to return debugging data. I tried the debug parameters debugQuery and debug, but all I got was: true I took a look at the code for the MoreLikeThisHandler, and noted in the debbuging part that th

Possible bug in MoreLikeThisHandler debugging?

Hi. After upgrading to solr 3.3.0 from 1.4.0, I noticed that I couldn't get the MoreLikeThisHandler to return debugging data. I tried the debug parameters debugQuery and debug, but all I got was: true I took a look at the code for the MoreLikeThisHandler, and noted in the debbuging part that th

Re: Possible bug in FastVectorHighlighter

Worked fine. Thanks a lot! Massimo On 09/08/2011 11:58, Jayendra Patil wrote: Try using - Regards, Jayendra On Tue, Aug 9, 2011 at 4:46 AM, Massimo Schiavon wrote: In my Solr (3.3) configuration I specified these two params: when I do a simple search I obtain correctly h

Re: Possible bug in FastVectorHighlighter

Try using - Regards, Jayendra On Tue, Aug 9, 2011 at 4:46 AM, Massimo Schiavon wrote: > In my Solr (3.3) configuration I specified these two params: > > > > > when I do a simple search I obtain correctly highlighted results where > matches areenclosed with correct tag. > If I do

Possible bug in FastVectorHighlighter

In my Solr (3.3) configuration I specified these two params: when I do a simple search I obtain correctly highlighted results where matches areenclosed with correct tag. If I do the same request with hl.useFastVectorHighlighter=true in the http query string (or specifying the same parameter

Re: Possible bug in Solr 3.3 grouping

Thanks Martijn - I should be able to patch the Solr 3.3 release based on r1145748. - Nikhil From: Martijn v Groningen To: solr-user@lucene.apache.org; Nikhil Chhaochharia Sent: Wednesday, 13 July 2011 2:04 AM Subject: Re: Possible bug in Solr 3.3 grouping Hi

Re: Possible bug in Solr 3.3 grouping

Hi Nikhil, Thanks for raising this issue. I checked this particular issue in a test case and I ran into the same error, so this is indeed a bug. I've fixed this issue for 3x in revision 1145748. So checking out the latest 3x branch and building Solr yourself should give you this bug fix. Or you ca

Possible bug in Solr 3.3 grouping

Hi, I am using Solr 3.3 and have run into a problem with grouping.  If 'group.main' is 'true' and 'start' is greater than 'rows', then I do not get any results.  A sample response is: 0602 If 'group.main' is false, then I get results. Did anyone else come across this problem?  Using the gr

Re: Possible bug in query sorting

On Fri, Oct 29, 2010 at 1:47 PM, Pablo Recio wrote: > That's my schema XML: >   >     >       >       >       >       >     >     >       >       ignoreCase="true" expand="true"/> >       >       >       >     >   >   > >   [...] >   required="true" multiValued="false" omitNorms="f

Re: Possible bug in query sorting

That's my schema XML: link text ... 2010/10/28 Gora Mohanty > On Thu, Oct 28, 2010 at 5:18 PM, Michael McCandless > wrote: > >

Re: Possible bug in query sorting

On Thu, Oct 28, 2010 at 5:18 PM, Michael McCandless wrote: > Is it somehow possible that you are trying to sort by a multi-valued field? [...] Either that, or or your field gets processed into multiple tokens via the analyzer/tokenizer path in your schema. The reported error is a consequence of t

Re: Possible bug in query sorting

Is it somehow possible that you are trying to sort by a multi-valued field? Mike On Thu, Oct 28, 2010 at 6:59 AM, Pablo Recio wrote: > Hi all. I'm having a problem with solr sorting search results. > > When I try to make a query and sort it by title: > > http://localhost:8983/solr/select/?q=*%3A

Possible bug in query sorting

Hi all. I'm having a problem with solr sorting search results. When I try to make a query and sort it by title: http://localhost:8983/solr/select/?q=*%3A*&version=2.2&start=0&rows=10&indent=on&sort=title%20desc I get that error [1]. If I try to sort by other indexed field it works, indeed if I c

possible bug in zookeeper / solrCloud ?

Hi I am using solrCloud which uses an ensemble of 3 zookeeper instances. I am performing survivability tests: Taking one of the zookeeper instances down I would expect the client to use a different zookeeper server instance. But as you can see in the below logs attached Depending on which insta

Re: possible bug in sorting by Function?

: issue resolve. problem was that solr.war was silently not being overwritten : by new version. : : will try to spend more time debugging before posting. Glad you were able to figure it out. For future refrence: problems like these are pretty much impossible for people to help you with unless

Re: possible bug in sorting by Function?

issue resolve. problem was that solr.war was silently not being overwritten by new version. will try to spend more time debugging before posting. -- View this message in context: http://lucene.472066.n3.nabble.com/possible-bug-in-sorting-by-Function-tp1118235p1121349.html Sent from the Solr

Re: possible bug in sorting by Function?

),sum(Latitude,1))%20asc http://10.0.11.54:8994/solr/select?q=*:*&sort=sum(sum(Latitude,1.0),sum(Latitude,1.0))%20asc http://10.0.11.54:8994/solr/select?q=*:*&sort=sum(rad(Latitude),rad(Latitude))%20asc -- View this message in context: http://lucene.472066.n3.nabble.com/possible-bug-in-sorti

Re: possible bug in sorting by Function?

small typo in last email: second sum should have been hsin, but I notice that the problem also occurs when I leave it as sum -- View this message in context: http://lucene.472066.n3.nabble.com/possible-bug-in-sorting-by-Function-tp1118235p1118260.html Sent from the Solr - User mailing list

possible bug in sorting by Function?

I did apply the SOLR-1297-2.patch supplied by Koji Sekiguchi but it didn't seem to help. I am using solr 903398 2010-01-26 20:21:09Z. Any suggestions appreciated. -- View this message in context: http://lucene.472066.n3.nabble.com/possible-bug-in-sorting-by-Function-tp1118235p1118235.html

Re: Wildcard on first char, Possible Bug 1.4?

On Tue, Oct 27, 2009 at 4:14 PM, Grant Ingersoll wrote: > I'm pretty sure wildcard queries don't go through analysis, hence they are > probably not stemmed. Right - same thing would happen w/o the reverse filter. Also, wildcarding mixes poorly with stemming - trying to analyze won't fix the probl

Re: Wildcard on first char, Possible Bug 1.4?

On Oct 27, 2009, at 9:44 AM, wrote: Hey, i found out when i use the new feature solr.ReversedWildcardFilterFactory that the following happens: I query for thomas. nickname:thomas nickname:thomas nickname:thoma nickname:thoma We see the parsed String ist thoma. I query for *thomas

Re: Wildcard on first char, Possible Bug 1.4?

: i found out when i use the new feature solr.ReversedWildcardFilterFactory that the following happens: Hmmm in spite of ReversedWildcardFilterFactory being somethng designed to be used as part of the analysis chain for a fields *so* you can do leading wildcard queries on them, it doesn't c

Wildcard on first char, Possible Bug 1.4?

Hey, i found out when i use the new feature solr.ReversedWildcardFilterFactory that the following happens: I query for thomas. nickname:thomas nickname:thomas nickname:thoma nickname:thoma We see the parsed String ist thoma. I query for *thomas nickname:*thomas nickname:*thomas nickname:#1;s

Re: Possible bug with commands to manage cores

al with the >>>>>> cores >>>>>> administration can't show the result using php or phps reponseWriter. >>>>>> Despite passing the command wt=php the result will show always in >>>>>> xml. >>>>>> Js

Re: Possible bug with commands to manage cores

;>>>> and ruby responseWriters work well. I am with a nightly from middle June. >>>>> Didn't use to happen with an older nighly. >>>>> >>>>> http://localhost8080

Re: Possible bug with commands to manage cores

;>> >>>> http://localhost8080/solr/admin/cores?wt=php&action=STATUS&core=core_01 >>>> >>>> This will show the response in xml format. >>>> -- >>>> View this message in context: >>>> http://www.n

Re: Possible bug with commands to manage cores

gt; Didn't use to happen with an older nighly. >>> >>> http://localhost8080/solr/admin/cores?wt=php&action=STATUS&core=core_01 >>> >>> This will show the response in xml format. >>> -- >>

Re: Possible bug with commands to manage cores

how always in xml. >> Json >> and ruby responseWriters work well. I am with a nightly from middle June. >> Didn't use to happen with an older nighly. >> >> http://localhost8080/solr/admin/cores?wt=php&action=STATUS&core=core_01 >> >> This will

Re: Possible bug with commands to manage cores

ill show the response in xml format. > -- > View this message in context: > http://www.nabble.com/Possible-bug-with-commands-to-manage-cores-tp24106584p24106584.html > Sent from the Solr - User mailing list archive at Nabble.com. > > -- - Noble Paul | Principal Engineer| AOL | http://aol.com

Possible bug with commands to manage cores

June. Didn't use to happen with an older nighly. http://localhost8080/solr/admin/cores?wt=php&action=STATUS&core=core_01 This will show the response in xml format. -- View this message in context: http://www.nabble.com/Possible-bug-with-commands-to-manage-cores-tp24106584p24106584.html

Re: Possible bug with sdouble?

On Wed, Mar 4, 2009 at 2:56 PM, Jonathan Ariel wrote: > Hi everyone! > So it seems like I ran into a bug with sdouble. > I have a document with two fields. > field1 is double > > stored="true" omitNorms="true"/> > indexed="true" stored="true" omitNorms="true"/> > > when I index I send for both o

Re: Possible bug with sdouble?

009 2:56:03 PM > Subject: Possible bug with sdouble? > > Hi everyone! > So it seems like I ran into a bug with sdouble. > I have a document with two fields. > field1 is double > > > stored="true" omitNorms="true"/> > > indexed="true"

Possible bug with sdouble?

Hi everyone! So it seems like I ran into a bug with sdouble. I have a document with two fields. field1 is double when I index I send for both of them the same value (7300) and when I'm querying I'm getting the following 7300 7.3E7 What do you think? Why am I getting different notati

Possible bug in spellchecker result

L.S. There seems to be a bug in the PHPS outputHandler when retrieving a query that also produces spellcheck results. The following query fails to return an unserializable string: spellcheck=true&facet=true&indent=on&facet.mincount=1&spellcheck.extendedResults=true& spellcheck.q=groninen&spellc

Re: CoreDescriptor explanation and possible bug

TED]> To: solr-user@lucene.apache.org Sent: Thursday, 28 August, 2008 6:30:16 PM Subject: Re: CoreDescriptor explanation and possible bug Hi Nikhil, Can you please describe your use-case? Are you aware of EmbeddedSolrServer? http://wiki.apache.org/solr/Solrj On Thu, Aug 28, 2008 at 6:12 PM,

Re: CoreDescriptor explanation and possible bug

Thanks again, this should solve the current problem I am having. Nikhil - Original Message From: Henrib <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Sent: Thursday, 28 August, 2008 7:42:11 PM Subject: Re: CoreDescriptor explanation and possible bug Nikhil Chhaochharia

Re: CoreDescriptor explanation and possible bug

er.register("", core, false); return container; } }; return init.initialize().getCore(""); } -- View this message in context: http://www.nabble.com/CoreDescriptor-explanation-and-possible-bug-tp19197004p19201459.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: CoreDescriptor explanation and possible bug

explanation and possible bug Seems you want something like: public SolrCore nikhilInit(final IndexSchema indexSchema) { final String solrConfigFilename = "solrconfig.xml"; // or else CoreContainer.Initializer init = new CoreContainer.Initializer() { @Override publi

Re: CoreDescriptor explanation and possible bug

e); container.register("", core, false); return container; } }; return init.initialize().getCore(""); } -- View this message in context: http://www.nabble.com/CoreDescriptor-explanation-and-possible-bug-tp19197004p19200585.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: CoreDescriptor explanation and possible bug

problem in another way, I have a solrconfig.xml but no > schema.xml. I create a IndexSchema object at runtime. I want to now get a > SolrCore object. > > Thanks, > Nikhil > > > > > > - Original Message > From: Henrib <[EMAIL PROTECTED]> > To: solr-

Re: CoreDescriptor explanation and possible bug

Thursday, 28 August, 2008 5:23:48 PM Subject: Re: CoreDescriptor explanation and possible bug Hi, It is likely to be related to how you initialize Solr & create your SolrCore; there has been a few changes to ensure there is always a CoreContainer created which (as its name stands), holds a refer

Re: CoreDescriptor explanation and possible bug

CoreDescriptor is all about and how it > is supposed to be used? > > Thanks, > Nikhil > > > -- View this message in context: http://www.nabble.com/CoreDescriptor-explanation-and-possible-bug-tp19197004p19198965.html Sent from the Solr - User mailing list archive at Nabble.com.

CoreDescriptor explanation and possible bug

Hi, I have been using nightly builds of Solr 1.3 with SolrJ for some time now. I upgraded the Solr jars from the 14-Aug nightly and my program would not compile. I found that SolrCore constructor needed a new parameter CoreDescriptor. I passed null and it worked fine. I then upgraded to the

Re: Possible bug in copyField

On 8/28/06, jason rutherglen <[EMAIL PROTECTED]> wrote: Could someone point me to where in the Solr code the Analyzer is applied to a query parser field? The lucene query parser normally does analysis. It also does things like making phrase queries from field that return multiple tokens. -Yo

Re: Possible bug in copyField

Could someone point me to where in the Solr code the Analyzer is applied to a query parser field? - Original Message From: Erik Hatcher <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Sent: Monday, August 28, 2006 11:13:25 AM Subject: Re: Possible bug in copyField On

Re: Possible bug in copyField

play with searching with or without stemming on the query side. Erik - Original Message From: Yonik Seeley <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org Cc: jason rutherglen <[EMAIL PROTECTED]> Sent: Monday, August 28, 2006 7:33:48 AM Subject: Re: Possi

Re: Possible bug in copyField

Subject: Re: Possible bug in copyField On 8/28/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : By looking at what is stored. Has this worked for others? > > the "stored" value of a field is allways going to be the pre-analyzed text > -- that's why the stored valu

Re: Possible bug in copyField

On 8/28/06, Chris Hostetter <[EMAIL PROTECTED]> wrote: : By looking at what is stored. Has this worked for others? the "stored" value of a field is allways going to be the pre-analyzed text -- that's why the stored values in your "text" fields still have upper case characters and stop words.

Re: Possible bug in copyField

: By looking at what is stored. Has this worked for others? the "stored" value of a field is allways going to be the pre-analyzed text -- that's why the stored values in your "text" fields still have upper case characters and stop words. what matters is whether or not the "indexed" terms of you

Re: Possible bug in copyField

By looking at what is stored. Has this worked for others? - Original Message From: Yonik Seeley <[EMAIL PROTECTED]> To: solr-user@lucene.apache.org; jason rutherglen <[EMAIL PROTECTED]> Sent: Friday, August 25, 2006 6:35:43 PM Subject: Re: Possible bug in copyField On 8/

Re: Possible bug in copyField

On 8/25/06, jason rutherglen <[EMAIL PROTECTED]> wrote: When doing a copyField into a text field that is supposed to be stemmed I'm not seeing the stemming occur. How did you determine that stemming didn't occur? -Yonik

Possible bug in copyField

When doing a copyField into a text field that is supposed to be stemmed I'm not seeing the stemming occur. These are the relevant lines of XML from the schema.xml: