[LUIS] Adding app version settings APIs to swagger file.

[LanaShafik]

This checklist is used to make sure that common issues in a pull request are addressed. This will expedite the process of getting your pull request merged and avoid extra work on your part to fix issues discovered during the review process.

PR information

• The title of the PR is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For information on cleaning up the commits in your pull request, see this page.
• Except for special cases involving multiple contributors, the PR is started from a fork of the main repository, not a branch.
• If applicable, the PR references the bug/issue that it fixes.
• Swagger files are correctly named (e.g. the api-version in the path should match the api-version in the spec).

Quality of Swagger

• I have read the contribution guidelines.
• My spec meets the review criteria:
  • The spec conforms to the Swagger 2.0 specification.
  • The spec follows the guidelines described in the Swagger checklist document.
  • Validation tools were run on swagger spec(s) and have all been fixed in this PR.

[msftclas]

All CLA requirements met.

[AutorestCI]

Automation for azure-sdk-for-ruby

Nothing to generate for azure-sdk-for-ruby

[AutorestCI]

Automation for azure-sdk-for-node

Nothing to generate for azure-sdk-for-node

[AutorestCI]

Automation for azure-sdk-for-python

The initial PR has been merged into your service PR:
Azure/azure-sdk-for-python#3362

[AutorestCI]

Automation for azure-sdk-for-java

Nothing to generate for azure-sdk-for-java

[AutorestCI]

Automation for azure-sdk-for-go

Encountered an unknown error: (azure-sdk-for-go)

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/azure_devtools/ci_tools/github_tools.py", line 33, in exception_to_github
    yield context
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/restapi/github.py", line 170, in rest_handle_action
    return rest_pull_close(body, restapi_repo, sdk_pr_target_repo, sdkbase, sdk_tag)
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/restapi/github.py", line 185, in rest_pull_close
    rest_pr_management(rest_pr, sdk_pr_target_repo, sdk_tag, sdk_default_base)
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/restapi/github_handler.py", line 151, in rest_pr_management
    sdk_tag=sdk_tag
  File "/usr/local/lib/python3.6/dist-packages/swaggertosdk/SwaggerToSdkNewCLI.py", line 309, in generate_sdk_from_git_object
    sdk_repo.git.push('origin', base_branch, set_upstream=True)
  File "/usr/local/lib/python3.6/dist-packages/git/cmd.py", line 548, in <lambda>
    return lambda *args, **kwargs: self._call_process(name, *args, **kwargs)
  File "/usr/local/lib/python3.6/dist-packages/git/cmd.py", line 1014, in _call_process
    return self.execute(call, **exec_kwargs)
  File "/usr/local/lib/python3.6/dist-packages/git/cmd.py", line 825, in execute
    raise GitCommandError(command, status, stderr_value, stdout_value)
git.exc.GitCommandError: Cmd('git') failed due to: exit code(1)
  cmdline: git push --set-upstream origin restapi_auto_cognitiveservices/data-plane/LUIS/Authoring
  stderr: 'To https://github.com/Azure/azure-sdk-for-go.git
 ! [rejected]          restapi_auto_cognitiveservices/data-plane/LUIS/Authoring -> restapi_auto_cognitiveservices/data-plane/LUIS/Authoring (fetch first)
error: failed to push some refs to 'https://AutorestCI:58ab395c311d1bd75b3e1db1cc8adaf9acc42afe@github.com/Azure/azure-sdk-for-go.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.'

[azuresdkci]

Can one of the admins verify this patch?

[mohabghanem]

@yangyuan Please have a look at this PR

[hovsepm]

@LanaShafik what is the difference between VersionSettingObject and VersionSettingUpdateObject models? they seems to have the same fields. Can they be merged into one?

[LanaShafik]

@hovsepm
They are the two different objects in the code base:

public class AppVersionSettingObject
    {
        [JsonIgnore]
        public Guid AppVersionId { get; set; }

        [JsonProperty("name")]
        public string Key { get; set; }

        [JsonProperty("value")]
      }

public class SettingUpdateObject
    {
        [JsonProperty("name")]
        public string Name { get; set; }

        [JsonProperty("value")]
        public string Value { get; set; }
    }

So, one contains the app version id while the other does not.

[hovsepm]

@LanaShafik my question is not about AppVersionSettingObject object. I'm asking about VersionSettingObject and VersionSettingUpdateObject objects. What are their differences?

[hovsepm]

@LanaShafik here is what your edits contain in the swagger:

    "VersionSettingObject": {
      "description": "Object model of an application version setting.",
      "type": "object",
      "properties": {
        "name": {
          "description": "The application version setting name.",
          "type": "string"
        },
        "value": {
          "description": "The application version setting value.",
          "type": "string"
        }
      }
    },
    "VersionSettingUpdateObject": {
      "description": "Object model of an application version updated setting.",
      "type": "object",
      "properties": {
        "name": {
          "description": "The application version setting name.",
          "type": "string"
        },
        "value": {
          "description": "The application version updated setting value.",
          "type": "string"
        }
      }
    }

there is no such object as AppVersionSettingObject.

[mohabghanem]

@hovsepm These two objects serve different purposes. They may currently have the same fields, since they are part of a relatively new feature. But later on as features get added, their attributes will differ. I personally think it is better to have them decoupled as two separate objects from the beginning.

[hovsepm]

@mohabghanem I need more explanation. What do you mean by their attributes will differ? If there is a filed that you want to stay read-only (i.e. clients will not send it back to server) you should rather mark those fields as "readOnly": true. Otherwise please explain what will be different in these two objects in the future.

According to your swagger changes VersionSettingObject will be used in Settings_List method and VersionSettingUpdateObject will be used in Settings_Update method. What I read from this is that you will have List and Update calls to the server from the client. Now from the developer point of view to accomplish some kind of their scenario they will have to List all the settings (through List) and may need to update some of them. And now for update after list call they will have to copy all the fields from the object retrieved from List call, modify whatever they need and send a new object to Server through Update call. I do not think forcing developers to implement Clone functionality for list/update scenario is a good approach.

[LanaShafik]

@hovsepm
please check the updates.