TrueCloudLab/frostfs-api
26
0
Fork 17
Code Issues 11 Pull requests 1 Releases Activity Actions

[#26] netmap: Add NOT and UNIQUE keywords #27

Merged
fyrchik merged 1 commit from aarifullin/frostfs-api:feature/26-add_keywords into master 2023-05-31 10:02:48 +00:00
Conversation 1 Commits 1 Files changed 1 +6
1 changed files with 6 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
netmap/types.proto
View file

@ -33,6 +33,9 @@ enum Operation {
// Logical AND
AND = 8;
// Logical negation
NOT = 9;
fyrchik marked this conversation as resolved Outdated
fyrchik commented 2023-05-25 10:46:29 +00:00
Outdated
Review
Copy link

In the task we have mentioned that we would like a new field UnaryOperation added to the filter.
This way we can have NOT (A EQ B) as one filter.

In the task we have mentioned that we would like a new field `UnaryOperation` added to the filter. This way we can have `NOT (A EQ B)` as one filter.
aarifullin commented 2023-05-26 14:04:40 +00:00
Outdated
Review
Copy link

There are few problems to discuss

  1. If we add new proto structrure UnaryOperation then there are two options:
    1.1. Embed it to Filter like this:
message Filter {
 string name = 1 [json_name = "name"];

 // Key to filter
 string key = 2 [json_name = "key"];

 // Filtering operation
 Operation op = 3 [json_name = "op"];

 // Value to match
 string value = 4 [json_name = "value"];

 // List of inner filters. Top level operation will be applied to the whole
 // list.
 repeated Filter filters = 5 [json_name = "filters"];
 
 UnaryOperation unary_op = 6 [json_name = "unary_op"];
}

Cons: very easy to support the backward compability
Pros: name, key, op, value fields (that are used either for filterExpr AND/OR filterExpr or for expr (like A EQ B)) are adapted for non-existent BinaryOperation structre. And also unary_op can be assigned along with op

1.2. Introduce more structrure

message Filter {
    BinaryOperation bin_op = 1 [json_name = "binary_op"];
    
    repeated Filter filters = 2 [json_name = "filters"];

    UnaryOperation unary_op = 3 [json_name = "unary_op"]; // and so on
}

Cons: the structures are used how they should be. Everything is explicit
Pros: Requires total refactoring that may break the backward compability :(

  1. We can keep proto like that and change nothing. @fyrchik suggested interesting idea to "not know" NOT in proto and use one trick in the parser: negate operation where NOT is in the prefix:

NOT (A EQ B) AND (C GT D) = (A NE B) OR (C LE D) but this exclusive case only for NOT

There are few problems to discuss 1. If we add new proto structrure `UnaryOperation` then there are two options: 1.1. Embed it to `Filter` like this: ``` message Filter { string name = 1 [json_name = "name"]; // Key to filter string key = 2 [json_name = "key"]; // Filtering operation Operation op = 3 [json_name = "op"]; // Value to match string value = 4 [json_name = "value"]; // List of inner filters. Top level operation will be applied to the whole // list. repeated Filter filters = 5 [json_name = "filters"]; UnaryOperation unary_op = 6 [json_name = "unary_op"]; } ``` Cons: very easy to support the backward compability Pros: `name`, `key`, `op`, `value` fields (that are used either for `filterExpr AND/OR filterExpr` or for `expr` (like `A EQ B`)) are adapted for non-existent `BinaryOperation` structre. And also `unary_op` can be assigned along with `op` 1.2. Introduce more structrure ``` message Filter { BinaryOperation bin_op = 1 [json_name = "binary_op"]; repeated Filter filters = 2 [json_name = "filters"]; UnaryOperation unary_op = 3 [json_name = "unary_op"]; // and so on } ``` Cons: the structures are used how they should be. Everything is explicit Pros: Requires total refactoring that may break the backward compability :( 2. We can keep `proto` like that and change nothing. @fyrchik suggested interesting idea to "not know" `NOT` in proto and use one trick in the parser: negate operation where NOT is in the prefix: `NOT (A EQ B) AND (C GT D) = (A NE B) OR (C LE D)` but this exclusive case only for NOT
}
// Selector modifier shows how the node set will be formed. By default selector
@ -119,6 +122,9 @@ message PlacementPolicy {
// List of named filters to reference in selectors
repeated Filter filters = 4 [json_name = "filters"];
// Unique flag defines non-overlapping application for replicas
fyrchik marked this conversation as resolved Outdated
fyrchik commented 2023-05-31 08:34:24 +00:00
Outdated
Review
Copy link

It is not necessarily consecutive. Can we make use the word non-overlapping somewhere in this doc?

It is not necessarily consecutive. Can we make use the word `non-overlapping` somewhere in this doc?
bool unique = 5 [json_name = "unique"];
}
// NeoFS node description