Shaleen
Def.Rights:
Roles can be enabled or disabled -- an unit must not be dependent
on the enabled/disabled roles. There is nothing bad to have such
design. This design is well thought, IMHO. At least at it's [was]
consistent [on the moment of its invention].
Inv.right
Due to the context switching inv.right program units are a little
bit (simplified) more expensive to be managed than def.rights.
Such units require some more development efforts and accuracy
(internal/external names).
>>> 2) To take care of this problem invokers rights facility
>>> was introduced. Then why this restriction on roles.
The advantage is reusable and manageable code but not just
the problem with roles. Def.rights units have their advantages
too -- the biggest one, IMHO -- no 'context switching'. Stored
Java stuff is also based on inv.right facility.
Kind regards,
--
Vladimir Begun
The statements and opinions expressed here are my own and
do not necessarily represent those of Oracle Corporation.
Shaleen wrote:
Hmm. Makes sense. Thanks Tim.
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Thursday, December 26, 2002 2:34 PM
I don't agree that anyone "shirked". Roles are, by design, changeable
within a session. The SET ROLE command is not DDL, altering the metadata
of
the database. Instead, it is only altering already-granted permissions to
used subsequently by the session. So, why should "permanent" objects
(such
as views, procedure, packages, triggers, etc) be created using permissions
which are inherently transitory (i.e. available via roles)? Just because
very few people use SET ROLE during a session doesn't alter its basic
properties...
When that note says that "complexity would be raised to the Nth degree",
they are not necessarily indicating that Oracle could not have implemented
it. This stuff is simplicity itself compared to the
transaction-consistency
model. Rather, the complexity would have been on the database
administration side (not in the database engine), and a major pain in
everyone's behind. Think it through. Oracle made a good design decision
to
prevent unnecessary complexity in database administration.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Vladimir Begun
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
