On 3/17/07, Ersin Er <[EMAIL PROTECTED]> wrote:
On 3/17/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
> On 3/17/07, Ersin Er <[EMAIL PROTECTED]> wrote:
> > On 3/16/07, Ersin Er <[EMAIL PROTECTED]> 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.
Enrique
