Re: Confused by queries

2013-01-24 Thread Anders Melchiorsen
Support http://sematext.com/ On Jan 22, 2013 5:48 PM, Anders Melchiorsen m...@spoon.kalibalik.dk wrote: Thanks, though I am still confused. How about this one: manu:apple = 1 hit +name:video = 2 hits manu:apple +name:video = 2 hits Solr ignores the manu:apple part completely? Cheers, Anders

Confused by queries

2013-01-22 Thread Anders Melchiorsen
Hello! With the example server of Solr 4.0.0 (with *.xml indexed), I get these results: *:* = 32 hits name:ipod = 3 hits -name:ipod = 29 hits That is all fine, but for these next queries, I would expect to get 32 hits (i.e. everything), or at least the same number of hits for both queries:

Re: Confused by queries

2013-01-22 Thread Anders Melchiorsen
nothing, so the query is equivalent to: (name:ipod) = 3 hits You can simply insert a *:* to assure that it is not a pure negative query inside the parentheses: (name:ipod) OR (*:* -name:ipod) -- Jack Krupansky -Original Message- From: Anders Melchiorsen Sent: Tuesday, January

Which schema changes are incompatible?

2010-01-28 Thread Anders Melchiorsen
Hello. I read the FAQ entry about rebuilding the index, http://wiki.apache.org/solr/FAQ#How_can_I_rebuild_my_index_from_scratch_if_I_change_my_schema.3F but it is not clear about the times when this is needed. So I wonder, do I need to do it after adding a field, removing a field, changing

Overlapping zipcodes

2009-09-21 Thread Anders Melchiorsen
We are in a situation where we are trying to match up documents based on a number of zipcodes. In our case, zipcodes are just integers, so that hopefully simplifies things. So, we might have a document listing a number of zipcodes: 1200-1450,2000,5000-5999 and we want to do a search of

Re: Overlapping zipcodes

2009-09-21 Thread Anders Melchiorsen
queries? Cheers Avlesh On Mon, Sep 21, 2009 at 2:57 PM, Anders Melchiorsen m...@spoon.kalibalik.dk wrote: We are in a situation where we are trying to match up documents based on a number of zipcodes. In our case, zipcodes are just integers, so that hopefully simplifies things. So

Re: HTML decoder is splitting tokens

2009-08-27 Thread Anders Melchiorsen
Anders Melchiorsen wrote: Hi. When indexing the string Guuml;nther with HTMLStripWhitespaceTokenizerFactory (in analysis.jsp), I get two tokens, Gü and nther. Is this a bug, or am I doing something wrong? (Using a Solr nightly from 2009-05-29) Anders.

HTML decoder is splitting tokens

2009-08-26 Thread Anders Melchiorsen
Hi. When indexing the string Guuml;nther with HTMLStripWhitespaceTokenizerFactory (in analysis.jsp), I get two tokens, Gü and nther. Is this a bug, or am I doing something wrong? (Using a Solr nightly from 2009-05-29) Anders.

Re: Highlight arbitrary text

2009-07-23 Thread Anders Melchiorsen
On Tue, 21 Jul 2009 14:25:52 +0200, Anders Melchiorsen wrote: On Fri, 17 Jul 2009 16:04:24 +0200, Anders Melchiorsen wrote: However, in the normal highlighter, I am using usePhraseHighlighter and highlightMultiTerm and it seems that there is no way to turn

Re: Highlight arbitrary text

2009-07-21 Thread Anders Melchiorsen
On Fri, 17 Jul 2009 16:04:24 +0200, Anders Melchiorsen m...@cup.kalibalik.dk wrote: On Thu, 16 Jul 2009 10:56:38 -0400, Erik Hatcher e...@ehatchersolutions.com wrote: One trick worth noting is the FieldAnalysisRequestHandler can provide offsets from external text, which could be used

Re: Highlight arbitrary text

2009-07-17 Thread Anders Melchiorsen
On Thu, 16 Jul 2009 10:56:38 -0400, Erik Hatcher e...@ehatchersolutions.com wrote: One trick worth noting is the FieldAnalysisRequestHandler can provide offsets from external text, which could be used for client-side highlighting (see the showmatch parameter too). Thanks. I tried doing this,

Highlight arbitrary text

2009-07-15 Thread Anders Melchiorsen
Is it possible to have Solr highlight an arbitrary text that is posted at request time? Currently, we are storing an unindexed HTML field in Solr, just to have it highlighted. We would prefer to generate the HTML from the database at presentation time, in order to keep the Solr index smaller and