Return-Path: X-Original-To: apmail-directory-users-archive@www.apache.org Delivered-To: apmail-directory-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BED179919 for ; Tue, 4 Oct 2011 00:12:16 +0000 (UTC) Received: (qmail 41251 invoked by uid 500); 4 Oct 2011 00:12:16 -0000 Delivered-To: apmail-directory-users-archive@directory.apache.org Received: (qmail 41229 invoked by uid 500); 4 Oct 2011 00:12:16 -0000 Mailing-List: contact users-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@directory.apache.org Delivered-To: mailing list users@directory.apache.org Received: (qmail 41221 invoked by uid 99); 4 Oct 2011 00:12:16 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Oct 2011 00:12:16 +0000 X-ASF-Spam-Status: No, hits=0.9 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (athena.apache.org: transitioning domain of craig@mfoundry.com does not designate 74.125.149.76 as permitted sender) Received: from [74.125.149.76] (HELO na3sys009aog106.obsmtp.com) (74.125.149.76) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 04 Oct 2011 00:12:10 +0000 Received: from mail-ww0-f50.google.com ([74.125.82.50]) (using TLSv1) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP; Mon, 03 Oct 2011 17:11:49 PDT Received: by mail-ww0-f50.google.com with SMTP id 3so4872483wwe.7 for ; Mon, 03 Oct 2011 17:11:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.88.212 with SMTP id a62mr619568wef.43.1317687108831; Mon, 03 Oct 2011 17:11:48 -0700 (PDT) Received: by 10.216.162.132 with HTTP; Mon, 3 Oct 2011 17:11:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 3 Oct 2011 19:11:48 -0500 Message-ID: Subject: Re: Indexing schema attributes From: Craig Setera To: "users@directory.apache.org" Content-Type: multipart/alternative; boundary=0016e6d645590c093304ae6df034 --0016e6d645590c093304ae6df034 Content-Type: text/plain; charset=ISO-8859-1 I actually assumed that to be the case. In our case, we did an LDIF export, set up the indices and re-imported the LDIF. Before the addition of the indices, our search would return a single result and after we would get zero results. I initially attributed that to the indices not being correctly registered, but from what you are saying that is not the case. On Monday, October 3, 2011, Kiran Ayyagari wrote: > ah, forgot to mention that before, newly created indices in versions > prior to 1.5.7 will not contain the indexed data for the already > existing data > (i.e if there are 100 entries already present before adding a new > index then the new index will not contain any relevant data from the > existing 100 entries > , it will be populated with the data that was added subsequently (e.x > adding a 101 entry ) ) > > The work around is to export the data, remove the data from server and > finally re-import after creating the relevant indices. > (this is not needed for the version > 1.5.7) > > -- Craig Setera Director, Product Engineering mFoundry p 415.324.5801 craig@mfoundry.com --0016e6d645590c093304ae6df034--