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 D4FF84D14 for ; Fri, 17 Jun 2011 20:50:02 +0000 (UTC) Received: (qmail 76279 invoked by uid 500); 17 Jun 2011 20:50:02 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 76234 invoked by uid 500); 17 Jun 2011 20:50:02 -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 76227 invoked by uid 99); 17 Jun 2011 20:50:02 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jun 2011 20:50:02 +0000 Received: from localhost (HELO mail-yx0-f178.google.com) (127.0.0.1) (smtp-auth username elecharny, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jun 2011 20:50:02 +0000 Received: by yxm8 with SMTP id 8so1911748yxm.37 for ; Fri, 17 Jun 2011 13:50:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.169.16 with SMTP id w16mr3114929ago.89.1308343801492; Fri, 17 Jun 2011 13:50:01 -0700 (PDT) Reply-To: elecharny@apache.org Received: by 10.90.63.17 with HTTP; Fri, 17 Jun 2011 13:50:01 -0700 (PDT) In-Reply-To: <97D89D19-76BE-4F3A-9B40-7A502676A401@gmail.com> References: <4DF9CB33.8000008@gmail.com> <97D89D19-76BE-4F3A-9B40-7A502676A401@gmail.com> Date: Fri, 17 Jun 2011 22:50:01 +0200 Message-ID: Subject: Re: Morning thoughts about alias handling... From: Emmanuel Lecharny To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=0016e645aaca88354c04a5ee87d5 --0016e645aaca88354c04a5ee87d5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 17, 2011 at 8:39 PM, Alex Karasulu wrote: > Hiya, > > Going totally off memory here from years back. The search engine was > designed to expand the scope that aliases introduce with their references= . > Meaning the scope expands to new areas if the reference points outside of > the base of the search: of course this is more complex when considering > deref modes and where the alias is. > > But essentially I was under the impression that dereferencing was not > handled in higher levels outside of the xdbm search in the partition. Hen= ce > not in the filters injected into the returned cursor system. Are u > witnessing the contrary conditions? > No, you are right. The current system is leveraging (or at least is suppose= d to) the alias indexes. But it does not work correctly. I think it would be easier to handle aliases by sending new search requests in the upper cursor, AFAICT atm. I'm still analysing the current implementation, so I'm not 100% sure. --=20 Regards, Cordialement, Emmanuel L=E9charny www.iktek.com --0016e645aaca88354c04a5ee87d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 17, 2011 at 8:39 PM, Alex Ka= rasulu <akarasu= lu@gmail.com> wrote:
Hiya,

Going totally off memory here from years back. The search engine was design= ed to expand the scope that aliases introduce with their references. Meanin= g the scope expands to new areas if the reference points outside of the bas= e of the search: of course this is more complex when considering deref mode= s and where the alias is.

But essentially I was under the impression that dereferencing was not handl= ed in higher levels outside of the xdbm search in the partition. Hence not = in the filters injected into the returned cursor system. Are u witnessing t= he contrary conditions?

No, you are right. The current system is l= everaging (or at least is supposed to) the alias indexes.

But it does not work correctly.

I think it= would be easier to handle aliases by sending new search requests in the up= per cursor, AFAICT atm.

I'm still analysing the current implementation, so = I'm not 100% sure.

--
Regards,
Cordial= ement,
Emmanuel L=E9charny
www.iktek= .com
--0016e645aaca88354c04a5ee87d5--