Instead of seeing who can access what, I want to setup policies that return how many connections are allowed per second, or, how much bandwidth is allowed. How do I define my policies to return values instead of true/false?
Complete rules are just if-then statements that assign a VALUE to a VARIABLE. When the VALUE is omitted, it's implicitly true:
allow { input.method == "GET" }
Is equivalent to:
allow = true { input.method == "GET" }
There is nothing special about allow or true though; you could similarly define a rule that sets the connections per second limit:
connections_per_second = 7 { input.tier == "gold" }
If you have multiple definitions just be aware that only one can succeed (otherwise OPA will raise a conflict error). You need to resolve the conflict inside of your policy. There are different ways of handling this, e.g., default, else, negation, etc.
Related
I have a java method to create a constraintstream out of all TeamCalendar objects (planning entity with pinned=true) that do not follow a given Preference.
As a result I would like to have a constraint stream that denotes for each department how many of these discrepancies exist. This is the java code:
private BiConstraintStream<Department, Integer> violatedPreferredTeamDays(ConstraintFactory constraintFactory) {
return constraintFactory.from(TeamCalendar.class)
.ifNotExists(Preference.class,
Joiners.equal(TeamCalendar::getDate, Preference::getDate),
Joiners.equal(TeamCalendar::getDepartment, Preference::getDepartment))
.filter((tc) -> {
return true;
})
.groupBy(TeamCalendar::getDepartment, count())
.filter((dep, count) -> {
return true;
});
}
When running this in Debug mode, the first filter (tc -> {return true;}) is entered a total of 20 times, 5 times for each of the 4 departments.
However, after groupBy, the result set seems to be empty. The debugger does not break code execution in that filter, and the penalize function used on this BiConstraintStream does not penalize anything.
I tried some trivial alternatives:
.groupBy(tc -> tc.getDepartment(), count())
.groupBy(tc -> { return tc.getDepartment(); }, count() )
as well as alternatives for the count method:
.groupBy(TeamCalendar::getDepartment, sum(tc -> 1) )
.groupBy(TeamCalendar::getDepartment, sum(tc -> {return 1;})
But without any improvement.
Am I overlooking something here?
The underlying engine applies the first filter directly on the TeamCalendar and pre-empts the ifNotExists call. Therefore you can not use the filter to check whether or not the ifNotExists has triggered or not.
Constraint Streams are not imperative, and the execution of individual building blocks need not happen in sequence. Constraint Streams can not be inspected using the debugger, unless you understand how the underlying Drools engine evaluates the constraints, and adjust your expectations accordingly.
As to why the groupBy result is empty - probably because the Preference instance actually exists. If that is not the case, please file a JIRA, attach a minimal executable code reproducer, and we will look into it.
If I have a Role R defined as:
role R { method answer { 42 } }
What is the difference (if any) between these two lines:
my $a = 'question' does R;
my $b = 'question' but R;
They appear very similar:
say $a.answer; # OUTPUT: «42»
say $b.answer; # OUTPUT: «42»
say $a.WHAT; # OUTPUT: «(Str+{R})»
say $b.WHAT; # OUTPUT: «(Str+{R})»
Is this a case of there being More Than One Way To Do It™, and these both mean the same thing? Or is there a subtle difference that I'm missing?
note:
I understand that does is both an operator and a trait and thus can be used when for compile-time mixins (e.g., class C does R {}) whereas but is only for runtime mixins. I also understand that but can be used with an object (e.g., my $c = 'question' but False) whereas does can only be used with a Role. I'm not asking about either of those differences; my only question is about whether there's a difference when both are used at runtime with a Role. I have read the documentation section on mixing in Role, but didn't see an answer.
Put simply:
does modifies an object in place (and should be used with caution with value types, see note below)
but returns a new object.
When created off of a literal, it's probably not as evident, but when used with another object, it's pretty clear I think:
role R { method answer { 42 } }
my $question = 'question';
my $but = $question but R;
my $does = $question does R;
say $question.WHAT; # (Str+{R})
say $but.WHAT; # (Str+{R})
say $does.WHAT; # (Str+{R})
say $question.WHERE; # 129371492039210
say $but.WHERE; # 913912490323923
say $does.WHERE; # 129371492039210 <-- same as $question's
Notice I cheated a bit and swapped the order of does and but. If I had preserved the order you had, the does would modify $question in place, applying the role, meaning that but would clone $question (with its role) and apply the role (again!):
my $does = $question does R;
my $but = $question but R;
say $does.WHAT; # (Str+{R})
say $but.WHAT; # (Str+{R}+{R})
This is because does as an operator is conceptually akin to ++ or +=, that is, designed to be used in a standalone context, for instance
my $foo = …;
given $bar {
when 'a' { $foo does A }
when 'b' { $foo does B }
when 'c' { $foo does B }
}
Using but is conceptually closer to using $foo + 1 — mostly meaningless unless assigned to or passed to something else.
A warning for does and value types
If you use does on a value type (strings, numbers mainly), there is an extremely high likelihood that you will cause unintended side effects. This is because value types (which, e.g., strings are) are supposed to be immutable and substitutable for one other. Note the following:
role Fooish { }
my $foo = 'foo';
$foo does Fooish;
say 'foo'.WHAT; # (Str+{Fooish})
This is a substitution that's happening at compile time (so it won't affect, e.g, 'foobar'.substr(0,3), that happens at runtime), but can cause some truly weird effects if you toss them in a loop:
role Fooish { }
my #a;
#a.push('foo' does Fooish) for ^10;
say #a[0].WHAT; # (Str+{Fooish}+{Fooish}+{Fooish}+{Fooish}+{Fooish}
+{Fooish}+{Fooish}+{Fooish}+{Fooish}+{Fooish})
Applying multiple rolls takes longer and longer the more you do it, so if you change that to ^100000, be ready to wait a while. OTOH, doing but gives you nice constant time and doesn't pollute the literal. This behavior seems, AFAICT, to be perfectly valid, but definitely something that can catch you unexpectedly.
Except for the block where I declared a signature, all of the blocks have the same identity value, and claim to be declared on line 1 regardless of where they occur. Could anyone shed some light as to why this is the case?
say ｢Let's look at some blocks…｣;
if True {
&?BLOCK.say;
}
while True {
&?BLOCK.say;
last;
}
loop {
&?BLOCK.say;
last;
}
if True -> | {
｢I'm different!｣.say;
&?BLOCK.say;
}
when ?True {
&?BLOCK.say;
}
First of all: .say does NOT give you the identity value, because that calls the .gist method on the given expression. For the identity value, you need to call the .WHICH method. Fortunately, the Block.gist method does include the identity value in its stringification. But that is not guaranteed to be the case for all objects.
What you see there, is the static optimizer at work: because nothing is happening inside the block, it can be discarded. In the one case where it is different (where you specified an alternate signature), it is different. If you run this script with --optimize=0 or --optimize=1, then all blocks will have different identity values.
I guess you could call it an issue that mentioning &?BLOCK does not inhibit the static optimizer from flattening the scope. On the other hand, you could also call this a case of DIHWIDT (Doctor, It Hurts When I Do This). So don't do that then :-)
UPDATE: it is the different signature that made the difference. Daniel Mita++
Are idempotent and deterministic functions both just functions that return the same result given the same inputs?
Or is there a distinction that I'm missing?
(And if there is a distinction, could you please help me understand what it is)
In more simple terms:
Pure deterministic function: The output is based entirely, and only, on the input values and nothing else: there is no other (hidden) input or state that it relies on to generate its output. There are no side-effects or other output.
Impure deterministic function: As with a deterministic function that is a pure function: the output is based entirely, and only, on the input values and nothing else: there is no other (hidden) input or state that it relies on to generate its output - however there is other output (side-effects).
Idempotency: The practical definition is that you can safely call the same function multiple times without fear of negative side-effects. More formally: there are no changes of state between subsequent identical calls.
Idempotency does not imply determinacy (as a function can alter state on the first call while being idempotent on subsequent calls), but all pure deterministic functions are inherently idempotent (as there is no internal state to persist between calls). Impure deterministic functions are not necessarily idempotent.
Pure deterministic
Impure deterministic
Pure Nondeterministic
Impure Nondeterministic
Idempotent
Input
Only parameter arguments (incl. this)
Only parameter arguments (incl. this)
Parameter arguments and hidden state
Parameter arguments and hidden state
Any
Output
Only return value
Return value or side-effects
Only return value
Return value or side-effects
Any
Side-effects
None
Yes
None
Yes
After 1st call: Maybe.After 2nd call: None
SQL Example
UCASE
CREATE TABLE
GETDATE
DROP TABLE
C# Example
String.IndexOf
DateTime.Now
Directory.Create(String)Footnote1
Footnote1 - Directory.Create(String) is idempotent because if the directory already exists it doesn't raise an error, instead it returns a new DirectoryInfo instance pointing to the specified extant filesystem directory (instead of creating the filesystem directory first and then returning a new DirectoryInfo instance pointing to it) - this is just like how Win32's CreateFile can be used to open an existing file.
A temporary note on non-scalar parameters, this, and mutating input arguments:
(I'm currently unsure how instance methods in OOP languages (with their hidden this parameter) can be categorized as pure/impure or deterministic or not - especially when it comes to mutating the the target of this - so I've asked the experts in CS.SE to help me come to an answer - once I've got a satisfactory answer there I'll update this answer).
A note on Exceptions
Many (most?) programming languages today treat thrown exceptions as either a separate "kind" of return (i.e. "return to nearest catch") or as an explicit side-effect (often due to how that language's runtime works). However, as far as this answer is concerned, a given function's ability to throw an exception does not alter its pure/impure/deterministic/non-deterministic label - ditto idempotency (in fact: throwing is often how idempotency is implemented in the first place e.g. a function can avoid causing any side-effects simply by throwing right-before it makes those state changes - but alternatively it could simply return too.).
So, for our CS-theoretical purposes, if a given function can throw an exception then you can consider the exception as simply part of that function's output. What does matter is if the exception is thrown deterministically or not, and if (e.g. List<T>.get(int index) deterministically throws if index < 0).
Note that things are very different for functions that catch exceptions, however.
Determinacy of Pure Functions
For example, in SQL UCASE(val), or in C#/.NET String.IndexOf are both deterministic because the output depends only on the input. Note that in instance methods (such as IndexOf) the instance object (i.e. the hidden this parameter) counts as input, even though it's "hidden":
"foo".IndexOf("o") == 1 // first cal
"foo".IndexOf("o") == 1 // second call
// the third call will also be == 1
Whereas in SQL NOW() or in C#/.NET DateTime.UtcNow is not deterministic because the output changes even though the input remains the same (note that property getters in .NET are equivalent to a method that accepts no parameters besides the implicit this parameter):
DateTime.UtcNow == 2016-10-27 18:10:01 // first call
DateTime.UtcNow == 2016-10-27 18:10:02 // second call
Idempotency
A good example in .NET is the Dispose() method: See Should IDisposable.Dispose() implementations be idempotent?
a Dispose method should be callable multiple times without throwing an exception.
So if a parent component X makes an initial call to foo.Dispose() then it will invoke the disposal operation and X can now consider foo to be disposed. Execution/control then passes to another component Y which also then tries to dispose of foo, after Y calls foo.Dispose() it too can expect foo to be disposed (which it is), even though X already disposed it. This means Y does not need to check to see if foo is already disposed, saving the developer time - and also eliminating bugs where calling Dispose a second time might throw an exception, for example.
Another (general) example is in REST: the RFC for HTTP1.1 states that GET, HEAD, PUT, and DELETE are idempotent, but POST is not ( https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html )
Methods can also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.
So if you use DELETE then:
Client->Server: DELETE /foo/bar
// `foo/bar` is now deleted
Server->Client: 200 OK
Client->Server DELETE /foo/bar
// foo/bar` is already deleted, so there's nothing to do, but inform the client that foo/bar doesn't exist
Server->Client: 404 Not Found
// the client asks again:
Client->Server: DELETE /foo/bar
// foo/bar` is already deleted, so there's nothing to do, but inform the client that foo/bar doesn't exist
Server->Client: 404 Not Found
So you see in the above example that DELETE is idempotent in that the state of the server did not change between the last two DELETE requests, but it is not deterministic because the server returned 200 for the first request but 404 for the second request.
A deterministic function is just a function in the mathematical sense. Given the same input, you always get the same output. On the other hand, an idempotent function is a function which satisfies the identity
f(f(x)) = f(x)
As a simple example. If UCase() is a function that converts a string to an upper case string, then clearly UCase(Ucase(s)) = UCase(s).
Idempotent functions are a subset of all functions.
A deterministic function will return the same result for the same inputs, regardless of how many times you call it.
An idempotent function may NOT return the same result (it will return the result in the same form but the value could be different, see http example below). It only guarantees that it will have no side effects. In other words it will not change anything.
For example, the GET verb is meant to be idempotent in HTTP protocol. If you call "~/employees/1" it will return the info for employee with ID of 1 in a specific format. It should never change anything but simply return the employee information. If you call it 10, 100 or so times, the returned format will always be the same. However, by no means can it be deterministic. Maybe if you call it the second time, the employee info has changed or perhaps the employee no longer even exists. But never should it have side effects or return the result in a different format.
My Opinion
Idempotent is a weird word but knowing the origin can be very helpful, idem meaning same and potent meaning power. In other words it means having the same power which clearly doesn't mean no side effects so not sure where that comes from. A classic example of There are only two hard things in computer science, cache invalidation and naming things. Why couldn't they just use read-only? Oh wait, they wanted to sound extra smart, perhaps? Perhaps like cyclomatic complexity?
Have such code in project:
Cookie CookieCreate(CookiesTypes type)
{
Cookie user_cookie = null;
switch (type)
{
case CookiesTypes.SessionId:
user_cookie = new Cookie("session_id", Convert.ToBase64String(Guid.NewGuid().ToByteArray()));
break;
case CookiesTypes.ClientIp:
HttpListenerContext context = listener.GetContext();
user_cookie = new Cookie("client_ip", context.Request.RemoteEndPoint.ToString());
break;
}
return user_cookie;
}
I understand, that temp variable user_cookie is bad syntax... I've tried to use return in switch-block both in two cases, but I've got an compiler erros, when I tried so:
Pseudo-Code:
case ... :
//some action
return var;
Having a temporary that is set in a case of a switch statement to be returned at the end is not a bad syntax, it is also the only choice if you need to do something on user_cookie for all cases before returning it.
The only problem is see in your code is the lack of a default case which is indeed useful because:
either you can require a default case (so that you do something in that situation)
either the switch should never reach a default case (so you should manage that situation in a special way, for example by throwing an exception)
If you blindly remove temporary variable and return the value directly like you are trying to do, then it gives you a compiler error probably because not all your branches do return something (because you are lacking a default clause or lacking a return after the switch).
Despite the fact that there's nothing inherently wrong with temporary variables, if you really want to avoid it you just need to ensure that all code paths return something.
That means (for example) changing your current return to:
return null;
and having both cases contain:
return new Cookie (whatever);
instead of the assignment.