[Mono-devel-list] Clear in ConstraintCollection and KeyRestrictions in DbDataPermissionAttribute

S Umadevi sumadevi at novell.com
Thu Mar 11 03:06:15 EST 2004


Hi
  I need help /thoughts on implementing the above.

1. KeyRestriction in DbDataPermissionAttribute : The MSDN Documentation
says.
>>>
Value
One or more connection string parameters that are allowed or
disallowed.
Remarks
Connection string parameters are identified in the form <parameter
name>=. Multiple parameters can be specified, delimited using a
semi-colon (;). The connection string parameters listed may be
identified as either the only additional parameters allowed or
additional parameters that are not allowed using the
KeyRestrictionBehavior property.

If no key restrictions are specified, and the KeyRestrictionBehavior
property is set to AllowOnly, then no additional connection string
parameters are allowed.

If no key restrictions are specified, and the KeyRestrictionBehavior
property is set to PreventUsage, then additional connection string
parameters are allowed. If more than one rule is set for the same
connection string, the more restrictive rule is selected during the
permission check.
>>>>
When are these restrictions applied to the connection string for
additional parameters ?. Since the connectionstring is a string how do
we enforce  any additional parameters to it?  Or is that we dont want to
allow additional agruements?


Incase there are any examples of this usage please let me know..

2. Clear method  in ConstraintCollection :
The code has the following comment
//LAMESPEC: MSFT implementation allows this
> //even when a ForeignKeyConstraint exist for a UniqueConstraint
> //thus violating the CanRemove logic
But the MSDN documentation asks the user to check using  CanRemove. Now
if we go by the assumption that the user will first check and then
remove using clear method it seems to be fine..  But if we want to
change this to check and remove only if there is no foreignkeyconstraint
then, how do we indicate to the user that the clear didnt succeed ? The
method does not throw any exception or return any value..

Hence I feel we can stay with the existing implemenation.. Any other
thoughts ?


regards
uma








More information about the Mono-devel-list mailing list