generator-go-sdk: add nullable support for resource manager sdk

[wuxu92]

The resource manager SDK cannot support nullable values at present, so for some APIs, the JSON-MERGE-PATCH cannot be met by Pandora SDK. This PR works with hashicorp/go-azure-sdk#1147 to add nullable support for resource manager APIs without modifying the struct definitions, which means it won't break any existing code.

Fixes #hashicorp/go-azure-sdk#1143 also related to hashicorp/go-azure-sdk#387

[mryanlo]

Hi @wuxu92, is there any update on this PR? i am also encountering the issue where we cannot send null properties in the go-for-azure sdk, as said in this issue: hashicorp/go-azure-sdk#1143

Do we have an ETA of when this PR will be merged? If this does go through, how do we consume the change?

From your PR it seems that you can only make a property null if the property's ObjectDefinition.Nullable field is true. however every single property for my resources are marked false for nullable. How does one set it to true? What does the generator look at in the Azure ARM specification to mark this property as true or false?

pandora/api-definitions/resource-manager/DeviceRegistry/2024-11-01/AssetEndpointProfiles/Model-UsernamePasswordCredentialsUpdate.json

Line 10 in a7bf2ed

"nullable": false,

[wuxu92]

@mryanlo Yes, currently ObjectDefinition.Nullable is always false for resource manager SDKs. To avoid significant changes to the generated SDK, I added a nullableWorkaround to Pandora to manually set specific targets as nullable. Although workarounds in Pandora are no longer recommended, since nullable support is only required by a limited number of resources, this approach should suffice.

[mryanlo]

@mryanlo Yes, currently ObjectDefinition.Nullable is always false for resource manager SDKs. To avoid significant changes to the generated SDK, I added a nullableWorkaround to Pandora to manually set specific targets as nullable. Although workarounds in Pandora are no longer recommended, since nullable support is only required by a limited number of resources, this approach should suffice.

@wuxu92 thanks for the response! a few more questions:

1. so we'd have to manually call nullableWorkaround in the pandora code for our resources? what would that look like? i see the example in the comments of the second file of this PR, but what do we do with the nullable workaround after that?
2. do we have an ETA for this PR to be merged and can be consumed?

[wuxu92]

@mryanlo

1. Yes we need to add a line to initiate the nullableWoraround and add it to the workarounds list if this PR is mereged:

   pandora/tools/importer-rest-api-specs/internal/components/apidefinitions/parser/dataworkarounds/workarounds.go

   Lines 6 to 8 in a7bf2ed

   	var workarounds = []workaround{
   	// These workarounds are related to issues with the upstream API Definitions
   	workaroundAlertsManagement{},

2. Unfortunately, There is no ETA yet as this PR is still under internal discussion.

[magodo]

Instead of ad-hoc opt in the nullable behavior one by one (and regenerate the SDK), can we just update the marshal/unmarshal logic as a whole?