Skip to content

Support azure-json in azure-core-management#38322

Merged
alzimmermsft merged 11 commits into
Azure:mainfrom
alzimmermsft:AzManagement_ImplementJsonSerializableInManagementCore
Mar 5, 2024
Merged

Support azure-json in azure-core-management#38322
alzimmermsft merged 11 commits into
Azure:mainfrom
alzimmermsft:AzManagement_ImplementJsonSerializableInManagementCore

Conversation

@alzimmermsft

Copy link
Copy Markdown
Member

Description

Serializable model types in azure-core-management now implement JsonSerializable to support azure-json.

All SDK Contribution checklist:

  • The pull request does not introduce [breaking changes]
  • CHANGELOG is updated for new features, bug fixes or other significant changes.
  • I have read the contribution guidelines.

General Guidelines and Best Practices

  • Title of the pull request 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 more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

  • Pull request includes test coverage for the included changes.

@azure-sdk

azure-sdk commented Jan 16, 2024

Copy link
Copy Markdown
Collaborator

API change check

APIView has identified API level changes in this PR and created following API reviews.

com.azure:azure-core
com.azure:azure-core-management

Comment on lines +94 to +99
if ("id".equals(fieldName)) {
ProxyResourceAccessHelper.setId(resource, reader.getString());
} else if ("name".equals(fieldName)) {
ProxyResourceAccessHelper.setName(resource, reader.getString());
} else if ("type".equals(fieldName)) {
ProxyResourceAccessHelper.setType(resource, reader.getString());

@weidongxu-microsoft weidongxu-microsoft Jan 17, 2024

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We can do it here. But in SDK, seems won't able to do such in a subclass of Resource.

Maybe we do need to add a protected ctor.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yeah, I was thinking about adding that constructor. Though would we want to share that through all implementations, requiring these three values to be passed through the constructor.

@alzimmermsft

Copy link
Copy Markdown
Member Author

@weidongxu-microsoft, it looks this PR may require a code generation update to resource manager libraries alongside with the changes made.

@weidongxu-microsoft

weidongxu-microsoft commented Jan 18, 2024

Copy link
Copy Markdown
Member

@weidongxu-microsoft, it looks this PR may require a code generation update to resource manager libraries alongside with the changes made.

Yes, some change would affect / get affected by codegen change. E.g. for Resource we may want a protected ctor, or 3 protected setter (the choice would interfere with codegen when it generates the subclass of Resource -- so far mgmt does not use ctor with required parameters).

I am OK with current code though. It does not add protected API so far, so we can delay the change till we design codegen.

@weidongxu-microsoft weidongxu-microsoft left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

LGTM

@XiaofeiCao
Is it possible we do a live run on some service (e.g. Compute, or a service with SystemData) with the unreleased core and core-management, before PR gets merged?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think these classes under polling namespace are for our internal use. It would be serialized to JSON so that it be persisted to the PollingContext.

* @param value the value
* @return provisioning state or null if value cannot be parsed
*/
static String tryParseProvisioningState(String value, SerializerAdapter adapter) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

nit, Should we put a JsonSerializer interface on this API?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

@XiaofeiCao

We probably want some more test on the hybrid case (i.e. SubClass extends Resource, with Resource extends JsonSerializable, while SubClass does not).

Since the test requires dependency on unreleased core, I am fine you just add to your local, and put it after PR merge and both lib released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Azure.Core azure-core

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants