Hi,
I've realized I need to change a particular field from text_ws to text.
I realize I need to reindex as the tokens are being stored in a case
sensitive manner which we do not want.
However can I just reindex all my documents, or do I need to drop/wipe the
/data/index dir and start fresh?
I r
Hi - you don't need to erase the data directory, you can just reindex, but make
sure you overwrite all documents.
-Original message-
> From:Wayne W
> Sent: Friday 3rd October 2014 11:55
> To: solr-user@lucene.apache.org
> Subject: If I can a field from text_ws to text do I need to dr
What happens if I don't re-index every document? Its possible this might
happen.
--
View this message in context:
http://lucene.472066.n3.nabble.com/If-I-can-a-field-from-text-ws-to-text-do-I-need-to-drop-and-reindex-or-just-reindex-tp4162488p4162491.html
Sent from the Solr - User mailing list
Hi all
I recently rewrote our SOLR 4.8 dataimport to read from a set of
denormalised DB tables, in an attempt to increase full indexing speed.
When I tried it out however, indexing broke telling me that
"java.lang.Long cannot be cast to java.lang.Integer" (full stack
below, with the document elide
Then some documents will be indexed one way, and newer docs the other way. Not
the end of the world, but it could affect whether documents match as you expect
during searches. When changing field types, the safest and sanest thing to do
is reindex everything again.
Erik
On Oct 3, 20
OK thanks everyone for the help and clarification
--
View this message in context:
http://lucene.472066.n3.nabble.com/If-I-can-a-field-from-text-ws-to-text-do-I-need-to-drop-and-reindex-or-just-reindex-tp4162488p4162506.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hi,
I want to create synonyms for a token where I use a regular expression on
that token and create a synonym for it with the result.
I tried the following code:
public PatternRulesFilter(TokenStream input, Map
substitutions)
{
super(input);
this.substitutions = substitutions;
this.charTermAttr
On 10/3/2014 5:41 AM, Tom Evans wrote:
> I recently rewrote our SOLR 4.8 dataimport to read from a set of
> denormalised DB tables, in an attempt to increase full indexing speed.
> When I tried it out however, indexing broke telling me that
> "java.lang.Long cannot be cast to java.lang.Integer" (fu
On Fri, Oct 3, 2014 at 2:24 PM, Shawn Heisey wrote:
> Can you give us the entire stacktrace, with complete details from any
> "caused by" sections? Also, is this 4.8.0 or 4.8.1?
>
Thanks Shawn, this is SOLR 4.8.1 and here is the full traceback from the log:
95191 [Thread-21] INFO
org.apache.sol
On Fri, Oct 3, 2014 at 3:13 PM, Tom Evans wrote:
> I tried converting the selected data to SIGNED INTEGER, eg
> "CONVERT(country_id, SIGNED INTEGER) AS country_id", but this did not
> have the desired effect.
However, changing them to be cast to CHAR changed the error message -
"java.lang.Integer
Hi Bob, I tried using a product type attribute which separates the
products/parts and boost the product in TOP with OR condition for productype as
parts. This way you get all the products /parts related to your search and
always keeping the Products in the Top and Parts next to Products. This i
On Fri, Oct 3, 2014 at 3:24 PM, Tom Evans wrote:
> On Fri, Oct 3, 2014 at 3:13 PM, Tom Evans wrote:
>> I tried converting the selected data to SIGNED INTEGER, eg
>> "CONVERT(country_id, SIGNED INTEGER) AS country_id", but this did not
>> have the desired effect.
>
> However, changing them to be c
On 10/3/2014 8:24 AM, Tom Evans wrote:
> On Fri, Oct 3, 2014 at 3:13 PM, Tom Evans wrote:
>> I tried converting the selected data to SIGNED INTEGER, eg
>> "CONVERT(country_id, SIGNED INTEGER) AS country_id", but this did not
>> have the desired effect.
>
> However, changing them to be cast to CHA
On 10/3/2014 8:13 AM, Tom Evans wrote:
> Caused by: java.lang.ClassCastException: java.lang.Integer cannot be
> cast to java.lang.Long
> at java.lang.Long.compareTo(Long.java:50)
> at java.util.TreeMap.getEntry(TreeMap.java:346)
> at java.util.TreeMap.get(TreeMap.java:273)
> at
> org.apache.solr.h
Thanks Ravi. Do you tag the product as TOP as a binary flag? My marketing team
wants to use the number of orders but that screws up the relevance horribly. My
thought is to tag a product with a product attribute (as you suggest) and tag
it as TOP selling. Then I have pure relevance, but can give
How you fixed this? I am also getting same error with 4.10?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Errors-on-index-in-SolrCloud-ConcurrentUpdateSolrServer-Runner-run-tp4107661p4162544.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hi Bob, Yes you can have attribute TOP and make it as binary. Later in the =
Query you can boost the product with TOP
Something like (ProductType:"Product" AND TOPSelling:true)^10 OR (ProductTy=
pe:"Product" AND -TOPSelling:true) as a part of the query , If your search
return products then they
We are attempting to improve our Solr response time as our application uses
Solr for large and time consuming queries. We have found a very inconsistent
result in the time elapsed when pinging Solr. If we ping Solr from a desktop
Windows 7 machine, there is usually a 5 ms elapsed time. But if we pi
Please help me get over this obstacle:
Stack trace and (ColdFusion) snippet: https://gist.github.com/jamiejackson
(This is an attempt to get Solrj to perform a deleteByQuery
with ConcurrentUpdateSolrServer using basic authentication. I am a noob
with the entire Solrj and HTTPClient stack. )
Plea
Say I have a boolean field named 'hidden', and less than 1% of the
documents in the index have hidden=true.
Do both these filter queries use the same docset cache size? :
fq=hidden:false
fq=!hidden:true
Peter
On Fri, Oct 3, 2014 at 3:42 PM, Peter Keegan wrote:
> Say I have a boolean field named 'hidden', and less than 1% of the
> documents in the index have hidden=true.
> Do both these filter queries use the same docset cache size? :
> fq=hidden:false
> fq=!hidden:true
Nope... !hidden:true will be sma
On 10/3/2014 1:57 PM, Yonik Seeley wrote:
> On Fri, Oct 3, 2014 at 3:42 PM, Peter Keegan wrote:
>> Say I have a boolean field named 'hidden', and less than 1% of the
>> documents in the index have hidden=true.
>> Do both these filter queries use the same docset cache size? :
>> fq=hidden:false
>>
On Fri, Oct 3, 2014 at 4:35 PM, Shawn Heisey wrote:
> On 10/3/2014 1:57 PM, Yonik Seeley wrote:
>> On Fri, Oct 3, 2014 at 3:42 PM, Peter Keegan wrote:
>>> Say I have a boolean field named 'hidden', and less than 1% of the
>>> documents in the index have hidden=true.
>>> Do both these filter queri
Hi Scott,
Any chance this could be an IPv6 thing? What if you start both server and
client with this flag:
-Djava.net.preferIPv4Stack=true
Michael Della Bitta
Senior Software Engineer
o: +1 646 532 3062
appinions inc.
“The Science of Influence Marketing”
18 East 41st Street
New York, NY 100
That's a reasonable description for Solr/Lucene scoring, but use the latest
release:
http://lucene.apache.org/core/4_10_0/core/org/apache/lucene/search/similarities/TFIDFSimilarity.html
-- Jack Krupansky
-Original Message-
From: mdemarco123
Sent: Thursday, October 2, 2014 6:06 PM
To:
Yes, either term can be used to confuse people equally well!
-- Jack Krupansky
-Original Message-
From: Alejandro Calbazana
Sent: Thursday, October 2, 2014 3:28 PM
To: solr-user@lucene.apache.org ; Ahmet Arslan
Subject: Re: Solr + Federated Search Question
Thanks Ahmet. Yay! New ter
Thanks for the recommendation, but that is not making a difference here.
-Original Message-
From: Michael Della Bitta [mailto:michael.della.bi...@appinions.com]
Sent: Friday, October 03, 2014 2:00 PM
To: solr-user@lucene.apache.org
Subject: Re: Inconsistent response time
Hi Scott,
Any c
: Solr for large and time consuming queries. We have found a very inconsistent
: result in the time elapsed when pinging Solr. If we ping Solr from a desktop
: Windows 7 machine, there is usually a 5 ms elapsed time. But if we ping the
: same Solr instance from a Windows Server 2008 machine, it tak
> it will be cached as hidden:true and then inverted
Inverted at query time, so for best query performance use fq=hidden:false,
right?
On Fri, Oct 3, 2014 at 3:57 PM, Yonik Seeley wrote:
> On Fri, Oct 3, 2014 at 3:42 PM, Peter Keegan
> wrote:
> > Say I have a boolean field named 'hidden', and l
On Fri, Oct 3, 2014 at 6:38 PM, Peter Keegan wrote:
>> it will be cached as hidden:true and then inverted
> Inverted at query time, so for best query performance use fq=hidden:false,
> right?
Yep.
-Yonik
http://heliosearch.org - native code faceting, facet functions,
sub-facets, off-heap data
It could be due to the minimum timer resolution on Windows. Do a search for
"windows 15ms" and you'll find a lot of information about it. Though, I'm not
sure which versions of Windows and/or Java have that problem. You could test it
out by timing things other than Solr and see if they also take
Ok, that field now totally works, thanks again!
I've removed the wildcard to benefit from ranking and boosting and am now
trying to combine this field with another, but I have some difficulties
figuring out the right query.
I want to search on the occurence of the keyword in the title field
(titl
32 matches
Mail list logo
