From dev-return-34549-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Tue Jul 20 15:09:41 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 60483 invoked from network); 20 Jul 2010 15:09:41 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 Jul 2010 15:09:41 -0000 Received: (qmail 76705 invoked by uid 500); 20 Jul 2010 15:09:41 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 76589 invoked by uid 500); 20 Jul 2010 15:09:40 -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 76582 invoked by uid 99); 20 Jul 2010 15:09:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jul 2010 15:09:40 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates 209.85.161.50 as permitted sender) Received: from [209.85.161.50] (HELO mail-fx0-f50.google.com) (209.85.161.50) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jul 2010 15:09:32 +0000 Received: by fxm9 with SMTP id 9so3563412fxm.37 for ; Tue, 20 Jul 2010 08:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=BagKIUofyL/Ia1J9viFbvjqvmD/XgdznyxqQ7sKLaL8=; b=eEPdgxd590GukdMdfwjdklBZr3I7P5KqiFCdOCbgYmfFnXbMm44dJRxbYORgXbiaqu i10MNaKdP8NseEOu+o5Hu4VDQwWM2x0WXmjEkYTnpC4A+t08S5yXTHTZkOyzV3eheblG rz9//yvpA0IOHvLXiLgmGEtqCckdUhED5t2Ec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ROcyp3ykqwlw2+Po8xWugMRPFz1UMhFPovE4f18QBGfcpdnkTA7fMXeymHOHaZn2fN 5TgFqd2zpzr7700FD41No15q3kkm76ehWAIoX5f/6xONTulPrEL0pe9BABl/ET4/w0A2 zZbzJf+/cFHrZNqb/IODHQbizs15cJYihnGOc= Received: by 10.216.70.200 with SMTP id p50mr5391069wed.54.1279638551676; Tue, 20 Jul 2010 08:09:11 -0700 (PDT) Received: from emmanuel-lecharnys-MacBook-Pro.local ([78.192.106.184]) by mx.google.com with ESMTPS id p82sm2901299weq.3.2010.07.20.08.09.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 20 Jul 2010 08:09:10 -0700 (PDT) Message-ID: <4C45BC94.10908@gmail.com> Date: Tue, 20 Jul 2010 17:11:16 +0200 From: Emmanuel Lecharny Reply-To: elecharny@apache.org User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: Update about subtree problems References: <4C44E117.6040509@gmail.com> <4C456914.90405@apache.org> In-Reply-To: <4C456914.90405@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Ok, let's think more in details about the last idea (using entryUUID instead of DN to refer to subentries). We may also need an index to map ( so that we can quickly find the impacted entries if we modify a subentry. We may need two caches : - one for subentries : - one for APs : The first cache is used when we need to quickly get a subentry The second cache is used when we move an entry, to know if it move from one AP to another one. Add operation : 1) we are adding a normal entry if it's under some APs, we evaluate it against all the associated subentries, and when it evaluates to true, we store the subentries entryUUID in the entry. We also update the index. 2) we are adding a subentry for each entries under the associated AP, see if they are part of the SS, and if so, inject the subentryUUID into the entry. Update the index. Delete operation : 1) we delete a normal entry nothing special to do 2) we delete a subentry we have to modify all the referencing entries and remove the subentry UUID from them. We use the index to get this list of entries. Then we can delete the subentry and update the index. One slight problem though : we should not be able to process any other modification on a subentry while it's being deleted. Rename operation : 1) We rename a normal entry this entry may have children, and some of those children may be AP or subentries. However, as we are using entryUUID to reference a subentry, this operation has no impact on the entries content. 2) We rename a subentry assuming that the subentry will remain in the same AP, we will just have to update the caches. Nothing else is needed. Move operation 1) We move a normal entry this entry might have APs in some of its children. They won't be impacted. However, as we may move the subtree from one AP area to another one, we will have to check two things : - first we have to list all the subentries the moved entries are referring to (we use the AP and subentry cache for that). this can be done once for the moved entry, as all the children will share the same subentries. - second, we have to find the new subentries the children will depend upon once moved. Now, we can remove the subentry references from the first set not present in the second in each selected entry (using the index), add the new subentry references into the selected entries (and we have to evaluate all the entries one by one), updating the index at the same time, and last, delete all the references from the old subentries, updating the index. 2) We move a subentry Moving the subentry is a simpler operation : we update all the entries containg a reference to the moved subentry (using the index to find them), and add a new reference to the moved subentry into all the selected entries. It's a delete and add operation, in fact, applied to the subentry. 3) We move an AP Moving an AP is like moving a normal entry : if we have APs higher in the tree (ie closer to the rootDSE than the moved AP), and if we don't inherit from the same AP, we then have to udpate the children entries by removing the reference to the old subentries and add references to the new subentries. Last operation, not the simplest Modify operation 1) We modify a normal entry No impact if we don't try to modify the references to the subentries (something only an admin can do...) 2) We modify a normal entry to make it a subentry It's like a subentry creation. 3) We modify a subentry Depending on what we modify in the subentry, the consequences will be different : - if we modify the cn, it has no impact - if we modify the OC, for instance by removing the "subentry' element, then it's a deletion operation. Anything else has no impact - if we modify the subtreeSpecifiction, we can consider that it's like a deletion followed by an addition, as we have to reevaluate and update all the selected entries 4) We modify a subentry to make it a normal entry It's a deletion operation (see case (3), second modification 5) We modify an AP to make it a normal entry It should be forbidden if the AP has some attached subentries, otherwise it has no impact. One more thing : how do we deal with aliases ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com