Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 11172 invoked from network); 17 Mar 2007 21:29:01 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 17 Mar 2007 21:29:01 -0000 Received: (qmail 83219 invoked by uid 500); 17 Mar 2007 21:29:09 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 83181 invoked by uid 500); 17 Mar 2007 21:29:09 -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 83163 invoked by uid 99); 17 Mar 2007 21:29:09 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Mar 2007 14:29:09 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of ersin.er@gmail.com designates 64.233.184.238 as permitted sender) Received: from [64.233.184.238] (HELO wr-out-0506.google.com) (64.233.184.238) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 17 Mar 2007 14:29:00 -0700 Received: by wr-out-0506.google.com with SMTP id 57so950140wri for ; Sat, 17 Mar 2007 14:28:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ePADxz+CU7RdwApptzhwo0MbiFxgHZOT+RmX0IrDrr78BJycO2c+oFCvJKmO6QE/of8rhlAq5BwYgbWV+eG+Q0zWYCRGSMKrjxdgZx055bjD7IxHVmf6IFEIx2jxPEMwshfXQbBH3C8ILvjqsxCKYp5i+/JC72g8dmu65QDdkCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QUsUYUNQKjNthKTNq1QsHzuvKoQn3uFqMDfosgXKgIkLvj9pjo0WbVPzXYEw1Nvdykq6dhZGzkOJTvRUKmkVxAunq8BD2y7279BEQbYfrV8mYCfJW1H57PTbyfQOtTTUrOclni5svDmpxcP67jE3hzBut1oBDdyp0wFKWYWWoE8= Received: by 10.65.154.2 with SMTP id g2mr4470647qbo.1174166919320; Sat, 17 Mar 2007 14:28:39 -0700 (PDT) Received: by 10.115.72.2 with HTTP; Sat, 17 Mar 2007 14:28:39 -0700 (PDT) Message-ID: Date: Sat, 17 Mar 2007 23:28:39 +0200 From: "Ersin Er" To: "Apache Directory Developers List" , erodriguez@apache.org Subject: Re: [core] Loading stored-procedures and setting triggers In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <568753d90703161203q5df0a56dpe9a7073db03cf76c@mail.gmail.com> <568753d90703161308x7b62c720lb66d71a352f8fda7@mail.gmail.com> <568753d90703171326u674de2d8y151d80f6704be321@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org On 3/17/07, Ersin Er wrote: > On 3/17/07, Enrique Rodriguez wrote: > > On 3/17/07, Ersin Er wrote: > > > On 3/16/07, Ersin Er wrote: > > > > ... > > > > Currently no. It's on TODO. My proposals were executing Triggers with > > > > creation time order and the other one was a Precedence specifier in > > > > the grammar. We'll figure it out soon. > > > > > > OK, now done. I have made some changes to the TriggerSpecification > > > grammar and TriggerService code. Now, we have guarantied ordered > > > execution of multiple SPs per Trigger execution. > > > > I thought about this some more. When a userPassword comes in, I > > derive keys, store the keys, and then discard the userPassword. The > > userPassword should never touch the database. My understanding with > > an AFTER trigger is that the userPassword would actually get stored. > > My intention with the ordering of the triggers was to then delete the > > userPassword with a 2nd trigger, but I realized it would be better to > > not store the userPassword in the first place. How can I avoid > > storing the userPassword and only store the keys? > > Well, as designed and once implemented we support BEFORE Triggers. But > I removed those portions of the code due to some inconsistencies. I > can reimplement BEFORE Triggers quickly (hopefully). Let me give it a > try in a few days. So, BEFORE Triggers will do the job for you, right? Hmm, what you need is infact INSTEAD of triggers which cause lots of inconsistencies to be resolved. Let me give them a try too. > > Enrique > > > > > -- > Ersin > -- Ersin