directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <ersin...@gmail.com>
Subject Re: [core] Loading stored-procedures and setting triggers
Date Sat, 17 Mar 2007 21:40:37 GMT
On 3/17/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> On 3/17/07, Ersin Er <ersin.er@gmail.com> wrote:
> > On 3/17/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
> > > On 3/17/07, Ersin Er <ersin.er@gmail.com> wrote:
> > > > On 3/16/07, Ersin Er <ersin.er@gmail.com> 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?
>
> I *think* so, if I understand how a BEFORE trigger would work.  I hope
> I got my use-case across, since really I'm looking to your "core"
> expertise in how best to try to do this.  I might want an interceptor,
> for all I know.

We can start with writing an Interceptor first and I can later convert
it into SP+Trigger form. You can easily intercept a request with
Interceptors and can do whatever you want instead of the real
operation. It's possible not to hit the database by not calling the
next method in the interceptor. If you need further assistance with
writing an interceptor I can help you.

> Enrique
>


-- 
Ersin

Mime
View raw message