Subject | RE: [IB-Architect] Compile Time Triggers |
---|---|
Author | Leyne, Sean |
Post date | 2001-05-07T14:15:44Z |
Jim,
Like Dalton Calford, I interpret this as being SELECT triggers.
I have a couple of questions;
Since the SQL would have already been parsed in order to determine which
tables are being accessed, how do you propose to allow for the trigger
to change the parsed statement?
How would you see the trigger parsing through the SQL statement to
determine how to add the "where" clause?
In the case of multi-table joins, would the trigger be called for each
table? In the case where two tables have runtime client restrictions,
wouldn't adding the criteria for both tables result in a needlessly slow
statement execution.
What about situations where a client "where" clause has already been
added to the statement, wouldn't adding a second occurrence, needlessly
slow the statement execution.
Sean
-----Original Message-----
From: Jim Starkey [mailto:jas@...]
Sent: Friday, May 04, 2001 1:31 PM
To: IB-Architect@yahoogroups.com
Subject: [IB-Architect] Compile Time Triggers
I've got a persistent client who's been bugging me for a solution
for a specific security problem. He's got a web application with
a bunch of clients none of which are allowed to see each other's
data. The standard way of handling this, of course, is to add a
conjunct to the "where" clause where appropriate. He's not happy
that he has to trust his programmers to do the right thing under
all circumstance, and wants a system solution.
After coming with with all sorts of unsatisfactory solutions, I
eventually came up with the idea of a per-table compile time
trigger. The trigger would be fired during compilation of any
database statement referencing the table. The trigger would
have access to the environment (login account, active roles,
connection attributes) and could abort the compilation ("bad
dog!"), add a conjunct ("and client = 'xyzzy'), or let the
compilation go.
So far, sounds cool. The next question is "what else is this
good for" (which is polite way to say what corners are the users
like to paint themselves into). For example, the compile time
trigger could be used to track the frequency that various queries
are compiled and/or prepared.
Any thoughts?
[Yeah, I know it is unblessed by the decoder ring set.]
Jim Starkey
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
Like Dalton Calford, I interpret this as being SELECT triggers.
I have a couple of questions;
Since the SQL would have already been parsed in order to determine which
tables are being accessed, how do you propose to allow for the trigger
to change the parsed statement?
How would you see the trigger parsing through the SQL statement to
determine how to add the "where" clause?
In the case of multi-table joins, would the trigger be called for each
table? In the case where two tables have runtime client restrictions,
wouldn't adding the criteria for both tables result in a needlessly slow
statement execution.
What about situations where a client "where" clause has already been
added to the statement, wouldn't adding a second occurrence, needlessly
slow the statement execution.
Sean
-----Original Message-----
From: Jim Starkey [mailto:jas@...]
Sent: Friday, May 04, 2001 1:31 PM
To: IB-Architect@yahoogroups.com
Subject: [IB-Architect] Compile Time Triggers
I've got a persistent client who's been bugging me for a solution
for a specific security problem. He's got a web application with
a bunch of clients none of which are allowed to see each other's
data. The standard way of handling this, of course, is to add a
conjunct to the "where" clause where appropriate. He's not happy
that he has to trust his programmers to do the right thing under
all circumstance, and wants a system solution.
After coming with with all sorts of unsatisfactory solutions, I
eventually came up with the idea of a per-table compile time
trigger. The trigger would be fired during compilation of any
database statement referencing the table. The trigger would
have access to the environment (login account, active roles,
connection attributes) and could abort the compilation ("bad
dog!"), add a conjunct ("and client = 'xyzzy'), or let the
compilation go.
So far, sounds cool. The next question is "what else is this
good for" (which is polite way to say what corners are the users
like to paint themselves into). For example, the compile time
trigger could be used to track the frequency that various queries
are compiled and/or prepared.
Any thoughts?
[Yeah, I know it is unblessed by the decoder ring set.]
Jim Starkey
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/