Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Hub Generated] Review request for Microsoft.PolicyInsights to add version 2018-07-01-preview #5408

Merged
merged 2 commits into from
Apr 11, 2019
Merged

[Hub Generated] Review request for Microsoft.PolicyInsights to add version 2018-07-01-preview #5408

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
65d1694
Fix incorrect types
j5lim Mar 15, 2019
5dec070
Transform the type of expressionValue and targetValue to object type …
j5lim Apr 1, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 6 additions & 6 deletions ...-07-01-preview/examples/PolicyStates_QueryResourceScopeExpandPolicyEvaluationDetails.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -93,12 +93,12 @@
"policyEvaluationDetails": {
"evaluatedExpressions": [
{
"result": "False",
"expression": "name",
"path": "name",
"expressionValue": "myDomainName",
"targetValue": "someName",
"operator": "Equals"
"result": "True",
"expression": "tags",
"path": "tags",
"expressionValue": {},
"targetValue": "global-opco",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This property is declared as an object in policyStates.json, so the example doesn't match.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A string is also valid for the property value since it is an object.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See https://swagger.io/docs/specification/data-models/data-types/#object - "An object is a collection of property/value pairs".

We're using Swagger 2.0, which adheres to OpenAPI 2.0 (which takes types from JSON schema draft 4). A JSON string is not valid for a "object" type field as per the JSON schema.

Copy link
Contributor Author

@j5lim j5lim Mar 20, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. "any" type explained in the doc is what we need. Can I use "any" type?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@praries880 can you please provide guidance on how to model a value which can be any type (string, object, array)?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@j5lim Ill get back to you on that shortly

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@j5lim
A good way to model this will be to break up the various properties into separate types and then define targetValue and expressionValue as composite types that encapsulate those properties...

Having a single type overloaded to support more than one type will be impossible to support in languages like Go

Autorest does not support the Any type.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@praries880 Does it mean we need to change the RP to return targetValue and expressionValue accordingly or can it be done by swagger changes only? Do you have some example?

How about using a directive to transform to object type similar to what OperationalInsights spec does here? Can I do that approach?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@praries880 Pushed a new commit where a directive is used to transform the type of the properties to object for the languages that support a generic object type. This way at least those languages can handle the response without an error. Can you please review it?

"operator": "NotContainsKey"
}
],
"ifNotExistsDetails": {
Expand Down
4 changes: 2 additions & 2 deletions ...ts/resource-manager/Microsoft.PolicyInsights/preview/2018-07-01-preview/policyStates.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1165,11 +1165,11 @@
},
"expressionValue": {
"description": "Value of the expression.",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have you already generated any client SDKs for the existing version? This looks like a breaking change. Will your service continue to accept strings?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SDKs for other languages are published but not SDK for .NET. This is part of the response not the request.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, so this change in behavior from your RP may break users of these existing SDKs, as response deserialization may fail. Normally a breaking change would require an API version rev. I'll discuss with the team. Is this feature in public preview or GA?

Copy link
Contributor Author

@j5lim j5lim Mar 21, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no change in the RP behavior. The RP has been always returning "any" type for these properties, which is expected. The issue is in the client code generation since the current swagger spec has incorrect type for these properties and the user of the latest SDK may see a failure when the property has a non-string value. So the PR should be treated as a fix not a breaking change.

The RP is in GA. The feature is only available in the preview API version.

"type": "string"
"type": "object"
},
"targetValue": {
"description": "Target value to be compared with the expression value.",
"type": "string"
"type": "object"
},
"operator": {
"description": "Operator to compare the expression value and the target value.",
Expand Down