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 1EF2B10ECD for ; Fri, 16 Aug 2013 16:16:12 +0000 (UTC) Received: (qmail 50307 invoked by uid 500); 16 Aug 2013 16:16:11 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 50173 invoked by uid 500); 16 Aug 2013 16:16:11 -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 50160 invoked by uid 99); 16 Aug 2013 16:16:10 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Aug 2013 16:16:10 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com designates 74.125.82.172 as permitted sender) Received: from [74.125.82.172] (HELO mail-we0-f172.google.com) (74.125.82.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 16 Aug 2013 16:16:05 +0000 Received: by mail-we0-f172.google.com with SMTP id t61so1814849wes.17 for ; Fri, 16 Aug 2013 09:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=FmM9cRnF7Ow1xV6+U6suHv2uNJ/d2F63dtqzQOeSCmE=; b=Aex4r/S9txBjeglHng00nOH4LN52nTEc7bsJ1ne4lYHlF80BrmfNU00vAb8Mc67Zi9 61xknvRkSJ2uEMm0iNQqrtuWKpVWjVkWmdctxsFSGoCj2ipyHD5Bs6UxRI7lq5+8gw6O bRcOAV06dhwZxHA8mq8XnS6wAqvcIi3hXM3ZO06y4itSxjyGAT+KXNK6jeLLFsEupCF7 Tm7qMfjjikIZWXxtGhcz9lY2edXDtPCaLywG50FfA0T7jUcqdsyrHLC9LLXaqaloUykJ DtCxlnuA2LfRndiWc3NRO/0jR72OtXTlJANnIkFm/Q7J/o8n9wpHYpUqZRrcq7vJQ0M6 9wJw== X-Received: by 10.180.84.65 with SMTP id w1mr5844713wiy.4.1376669743742; Fri, 16 Aug 2013 09:15:43 -0700 (PDT) Received: from luc14-1-78-235-65-101.fbx.proxad.net (luc14-1-78-235-65-101.fbx.proxad.net. [78.235.65.101]) by mx.google.com with ESMTPSA id eb3sm9296912wic.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 Aug 2013 09:15:42 -0700 (PDT) Message-ID: <520E502E.4060308@gmail.com> Date: Fri, 16 Aug 2013 18:15:42 +0200 From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Apache Directory Developers List Subject: About entry cloning on the server... X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Hi guys, this morning, while I was trying not to wake up, I had an idea that could change a lot. Whenw e do a search, we get back an entry from the backend. As we may change this entry befoe sendng it to the user, we do a deep copy of it. The rationnal is that the user may require only a few attributes, or the authorization layer might hide some of the attributes (or even some of the values), or some interceptor might remove or add some attributes and/or values (like the collectiveAttributes interceptor). Ok, by cloning the whole entry, we guarantee that we can cache it for any further requests, so this is mandatory if we want to deliver some decent performances without hitting the disk for each entry we have to return. Now, if we consider that most of the time, the attributes will not be changed (ie, it's quite rare that we hide or add a value of an attribute), so it would make sense not to clone the attributes. I was thinking that if we just do a shallow clone of the entry, we should save a hell lot of processing and time... Would it fly ? It depends. There are cases where we want to do a deep copy of the attributes too : - when we have to hide an attribute - when we have to replace the attribute's name by the one provided by the user (if the user request for an entry with OBJECTCLASS, then the attribute's name should be OBJECTCLASS, nothing else) But even then, we can easily clone the associated attributes on the fly, and replace the existing one in the cloned entry... I think that worths an experiment... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com