From dev-return-40666-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Sun Mar 25 11:54:27 2012 Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C45559274 for ; Sun, 25 Mar 2012 11:54:27 +0000 (UTC) Received: (qmail 72256 invoked by uid 500); 25 Mar 2012 11:54:27 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 72182 invoked by uid 500); 25 Mar 2012 11:54:26 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 72171 invoked by uid 99); 25 Mar 2012 11:54:26 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Mar 2012 11:54:26 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-wg0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 25 Mar 2012 11:54:19 +0000 Received: by wgbdr13 with SMTP id dr13so3120999wgb.1 for ; Sun, 25 Mar 2012 04:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=9BHc9ZWcH7yOY5bf+eRMYWv7Hk8WsFUcEdwuN96AvBU=; b=ppKwYXSblxvUzN28UiCDXrMmzUqvkHMbXxW9P1aSxr2sbgxRdSDpPEIb+tZJiCg77I bwZ/CoDaGywzCFxPjc6O1CDIjRKMpuGGKaJcUyx/GpFGySilhbzMF6WOwHne4sw25iUC lObj08cOLTAgtWMI8ljACNFB29Ovp3O5m1aK/4JaQzUEZUmzNDRVKOCyfNfxh5GLdQ8Y 3YOT2AJ2dIjAG9XYprSdFioqdDjZCdvPEQwpf4P1pQ473Rx1qsS+OoRS5GhZCyEBoPqw 7zxEt+tNY4r7rDchIugQDWsWBUHViwHWtlM6hPLyUx9iq/GRiirXEjh+Czap2sHDJyMH ltcg== MIME-Version: 1.0 Received: by 10.180.107.132 with SMTP id hc4mr10573722wib.21.1332676439522; Sun, 25 Mar 2012 04:53:59 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.180.4.1 with HTTP; Sun, 25 Mar 2012 04:53:59 -0700 (PDT) In-Reply-To: <20120322163801.GA30613@symas.com> References: <4F6B47E1.1020105@gmail.com> <20120322161118.GA30069@symas.com> <4F6B5342.3080605@gmail.com> <20120322163801.GA30613@symas.com> Date: Sun, 25 Mar 2012 14:53:59 +0300 X-Google-Sender-Auth: bv1eMO83A6SI08WcBxAtBSLy-Oo Message-ID: Subject: Re: [index] Presence index usage From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=e89a8f235089c73f1504bc0fe91c --e89a8f235089c73f1504bc0fe91c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Mar 22, 2012 at 6:38 PM, wrote: > On Thu, Mar 22, 2012 at 05:28:50PM +0100, Emmanuel L=E9charny wrote: > > Le 3/22/12 5:11 PM, hyc@symas.com a =E9crit : > > >On Thu, Mar 22, 2012 at 04:40:17PM +0100, Emmanuel L=E9charny wrote > > > >>Now, if we consider the fact that having all the AT stored in the > > >>index will allow us to know what will be the impacted entries if an > > >>AT is removed from the schema, then it can be a good thing to have a > > >>complete index with all the AT. > > >It's an interesting idea, if the admin was going to index it anyway. > > >Otherwise, IMO you're optimizing for a very infrequent case, which > > >is self-defeating. > > Here, it's not about optimization, really. > > > > The idea is much more about bieng able to see if an AT removal from > > the schema is likely to impact the data, without doing a full scan. > > Yes... but "avoiding a full scan" is just a (coarse) optimization of > the schema change. > > > Not sure it's a sane politic though : removing an AT from a > > production server sounds a bad idea... > > Agreed. And again, even if it's for a valid reason, it will occur once > in a blue moon. Who cares how long it takes? > > If you're really concerned about this scenario, sounds like a refcount > on the schema elements would be more straightforward. > +1 this would be easier to comprehend and maintain in the long run verses this mechanism which couples the index to ref-count like functionality. --=20 Best Regards, -- Alex --e89a8f235089c73f1504bc0fe91c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Mar 22, 2012 at 6:38 PM, <hyc@symas.com> wrote:
On Thu, Mar 22, 2012 at 05:28:50PM +0100, Emmanuel L=E9ch= arny wrote:
> Le 3/22/12 5:11 PM, hyc@symas.com= a =E9crit :
> >On Thu, Mar 22, 2012 at 04:40:17PM +0100, Emmanuel L=E9charny wrot= e

> >>Now, if we consider the fact that havi= ng all the AT stored in the
> >>index will allow us to know what will be the impacted entries = if an
> >>AT is removed from the schema, then it can be a good thing to = have a
> >>complete index with all the AT.
> >It's an interesting idea, if the admin was going to index it a= nyway.
> >Otherwise, IMO you're optimizing for a very infrequent case, w= hich
> >is self-defeating.
> Here, it's not about optimization, really.
>
> The idea is much more about bieng able to see if an AT removal from > the schema is likely to impact the data, without doing a full scan.
Yes... but "avoiding a full scan" is just a (coarse) optimi= zation of
the schema change.

> Not sure it's a sane politic though : removing an AT from a
> production server sounds a bad idea...

Agreed. And again, even if it's for a valid reason, it will occur= once
in a blue moon. Who cares how long it takes?

If you're really concerned about this scenario, sounds like a refcount<= br> on the schema elements would be more straightforward.

+1 this would be easier to comprehend and maintain in the long r= un verses this mechanism which couples the index to ref-count like function= ality.

--
Best Regards,
-- Alex

--e89a8f235089c73f1504bc0fe91c--