Return-Path: 
 <solr-user-return-69133-apmail-lucene-solr-user-archive=lucene.apache.org@lucene.apache.org>
X-Original-To: apmail-lucene-solr-user-archive@minotaur.apache.org
Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 71C45C060
	for <apmail-lucene-solr-user-archive@minotaur.apache.org>;
 Thu,  5 Jul 2012 15:40:18 +0000 (UTC)
Received: (qmail 84230 invoked by uid 500); 5 Jul 2012 15:40:15 -0000
Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org
Received: (qmail 84177 invoked by uid 500); 5 Jul 2012 15:40:15 -0000
Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:solr-user-help@lucene.apache.org>
List-Unsubscribe: <mailto:solr-user-unsubscribe@lucene.apache.org>
List-Post: <mailto:solr-user@lucene.apache.org>
List-Id: <solr-user.lucene.apache.org>
Reply-To: solr-user@lucene.apache.org
Delivered-To: mailing list solr-user@lucene.apache.org
Received: (qmail 84166 invoked by uid 99); 5 Jul 2012 15:40:15 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jul 2012 15:40:15 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=FSL_RCVD_USER,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of erickerickson@gmail.com
 designates 209.85.214.176 as permitted sender)
Received: from [209.85.214.176] (HELO mail-ob0-f176.google.com)
 (209.85.214.176)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Jul 2012 15:40:08 +0000
Received: by obbtb18 with SMTP id tb18so6340658obb.35
        for <solr-user@lucene.apache.org>;
 Thu, 05 Jul 2012 08:39:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=n3AguzJng6IISbgHz79cSpv/cBtNkTyrJyqHcTVY5VY=;
        b=DWCf9T91IotQS3mNdnIGHWbpAqM1x7fZG63yxMEhYyEdvuPkPyXDENDS1Re8K+W3cN
         nc6xfMv4CPqAWvVFc3ravzMU7d44fc61D3QaJC9ADSI6vxdYZJtizYwKQDL4kSvHlsIN
         WtPj6VVFZuBA5Mqg4AQjESn67BPRZDNCQK7V9B59cNUtysgNUs4AqmP3M/gZQQ6gwEeR
         Uyj2JPB4VHzBSAflk9YqgirQtKmld4G8eL3rDZ6aiIfn3gJBufZSZF1dR3vLFDPgEDjQ
         VpVVN9enkA0wEhceq7/KSN0owQKBZcShwBM+kcIbQjESNysZePa7KdzmIyFiUFBIgHZg
         31Og==
MIME-Version: 1.0
Received: by 10.182.17.42 with SMTP id l10mr21784644obd.52.1341502788076; Thu,
 05 Jul 2012 08:39:48 -0700 (PDT)
Received: by 10.182.167.37 with HTTP; Thu, 5 Jul 2012 08:39:48 -0700 (PDT)
In-Reply-To: 
 <CANbU6K+eswaXN0L300pPzc1aHfe=2W6utAx+6beg6FVnjofQUA@mail.gmail.com>
References: 
 <CANAV3Wn3JxRrfSEGoYKV95vreQ28z8=HoQhmec+eSwiLmej0aA@mail.gmail.com>
	<CANbU6KK9mZKW8+Ro7XWbEU=3xNCJXG2kkzxZf69F8NtueBp6vQ@mail.gmail.com>
	<CANAV3Wn_8zncb-4pjheHhpM5dvaVLpng1JrNedovqx8Jof_xxg@mail.gmail.com>
	<CANAV3Wn=ArpXG2vYMO=FpLj+HHcWeVmch5iQu7tCsEGk+9m7Dw@mail.gmail.com>
	<CANbU6KLv39xAW-c8OPTgqLVEo=VFH4SYUD2Ax=+QP4+gU-uMsA@mail.gmail.com>
	<CANAV3W=u3GE_jFQqekbMwn+dxQ9U7mpVjCyLibAEYsvbV0i=+A@mail.gmail.com>
	<CANbU6K+eswaXN0L300pPzc1aHfe=2W6utAx+6beg6FVnjofQUA@mail.gmail.com>
Date: Thu, 5 Jul 2012 11:39:48 -0400
Message-ID: 
 <CAN4YXvfjCf0JJHuhcm6wzBzFxo14z7XgKGU5ODFXuMJnZVw+Wg@mail.gmail.com>
Subject: Re: Frequency of Unique Id displayed more than 1
From: Erick Erickson <erickerickson@gmail.com>
To: solr-user@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
X-Virus-Checked: Checked by ClamAV on apache.org

solr updates are really a delete followed by a re-index. The old terms
are left in the index, but the associated document is marked as deleted.
Schema browser, for instance, will happily report frequencies > 1 for
<uniqueKey>s when a document has been updated.

You can ignore this if you query on the schemaId in question and get
only back one document, it's expected behavior. Also, if this is indeed
what you're seeing, doing  an optimize (forceMerge in the new parlance)
should take all the frequencies back to 1.

Best
Erick

On Thu, Jul 5, 2012 at 9:09 AM, Savvas Andreas Moysidis
<savvas.andreas.moysidis@gmail.com> wrote:
> hmm, based on the schema I don't see how you would be able to commit
> the same "schemaid" twice?
> maybe you want to investigate how you post a document to solr (do you
> do a commit after the post etc) or the merge strategy that is being
> applied.
>
> Just to exclude any possibilities, is is possible that at some point
> the "schemaid" field wasn't defined as "string" and then changed to
> "string" without re-indexing?
>
> On 5 July 2012 12:09, Sohail Aboobaker <saboobaker@gmail.com> wrote:
>> <fields>
>>  <field name="schemaid" type="string" indexed="true" stored="true"
>> required="true"/>
>>  <field name="itemmasterid" type="string" indexed="true" stored="true"
>> required="true"/>
>>  <field name="itemtitle" type="string" indexed="true" stored="true"
>> required="true"/>
>>  <field name="manufacturerId" type="string" indexed="true" stored="true"
>> required="true"/>
>> <field name="language" type="string" indexed="true" stored="true"
>> required="true"/>
>> <field name="make" type="string" indexed="true" stored="true"
>> required="true"/>
>> <field name="model" type="string" indexed="true" stored="true"
>> required="true"/>
>> <field name="msrp" type="double" indexed="true" stored="true"
>> required="true"/>
>> <field name="level1Categories" type="string" indexed="true" stored="true"
>> required="true" multiValued="true"/><field name="level2Categories"
>> type="string" indexed="true" stored="true" required="false"
>> multiValued="true"/><field name="level3Categories" type="string"
>> indexed="true" stored="true" required="false" multiValued="true"/><field
>> name="level4Categories" type="string" indexed="true" stored="true"
>> required="false" multiValued="true"/>
>> </fields>
>> <uniqueKey>schemaid</uniqueKey>
>>
>> Above is the main schema. Let me know if you need more information.