Don't use the same Filter for multiple messages (proto)

[lebogg]

clouditor/api/orchestrator/orchestrator.proto

Lines 468 to 477 in cf4cfd9

	message Filter {
	// Optional. List only assessment results of a specific cloud service.
	optional string cloud_service_id = 1 [ (validate.rules).string.uuid = true ];
	// Optional. List only compliant assessment results.
	optional bool compliant = 2;
	// Optional. List only assessment results of a specific metric id.
	repeated string metric_ids = 3
	[ (validate.rules).repeated .items.string.min_len = 1 ];
	optional string metric_id = 4 [ (validate.rules).string.min_len = 1 ];
	}

Here, the Filter is used for both ListAssessmentResultsRequest and ListAssessmentToolsRequest. I guess the fields are not appropriate for both cases? In addition, the comments refer only to assessment results.

[oxisto]

Ah, it seems all the filter of the service were merged into a single one. Looks like we need distinct filter objects and then the question is: Is that worth it? Or would it be better just to have a common handling of the filter fields in the service implementation?

[oxisto]

We could also embed the filter type directly into the message like this:

message ListResourcesRequest {
  message Filter {
    optional string type = 1;
    optional string cloud_service_id = 2;
  }

  optional Filter filter = 1;

  int32 page_size = 10;
  string page_token = 11;
  string order_by = 12;
  bool asc = 13;
}

although this creates a type called ListResourcesRequest_Filter in Go.

Probably renaming the type to ListResourcesFilter would be cleaner?

message ListResourcesRequest {
  optional ListResourcesFilter filter = 1;

  int32 page_size = 10;
  string page_token = 11;
  string order_by = 12;
  bool asc = 13;
}

message ListResourcesFilter {
  optional string type = 1;
  optional string cloud_service_id = 2;
}

or ListResourcesRequestFilter?

cc @lebogg @luis-gasparschroeder

[anatheka]

I like more the upper one with the filter embedded in the message.

[lebogg]

Ah, it seems all the filter of the service were merged into a single one. Looks like we need distinct filter objects and then the question is: Is that worth it? Or would it be better just to have a common handling of the filter fields in the service implementation?

Tricky question. I kinda dislike one filter for multiple requests. But, on the other side, if we have one such big filter and comment appropriately to which Requests they belong and also do the handling of these filters in the implementation (like you mentioned), it could work.

Otherwise, I would prefer the embedded option in the case of single filters.

[oxisto]

We need to check, if the "new" approach (unique filter message in request) is used everywhere.