Difficult/impossible to conditionally deploy resource with different discriminator value

[StijnDevogel]

Is your feature request related to a problem? Please describe.
The PostGreSQL ARM template has a serverpropertiesforcreate object that also requests for an additional set of keys depending what purpose your server has (create, restore, georestore or replica).
The issue I'm having at the moment is that the extra keys are not and extra object in the ServerPropertiesForCreate object.
Which limits a more dynamic setup for a bicep module (E.G.: use of variables).
Another issue is that the createmode key does not accept a string if you want this to be a parameter in bicep. It needs to be on of the following values: ( Default | GeRestore | PointInTimeRestore | Replica) (screenshot)

Describe the solution you'd like
A possible solution would be to add and extra object under properties (createProfile) which would then use the keys of the object it needs:

This however will need an API change.

example of the solution in bicep:

properties: {
    version: version
    sslEnforcement: sslEnforcement
    minimalTlsVersion: minimalTlsVersion
    publicNetworkAccess: publicNetworkAccess
    infrastructureEncryption:infrastructureEncryption
    storageProfile: {
      storageMB: skuSizeMB
      backupRetentionDays: backupRetentionDays
      geoRedundantBackup: geoRedundantBackup
      storageAutogrow: storageAutoGrow
    }
    createProfile: {
      createMode: 'GeoRestore'
      sourceServerId: /subscription/resourcegroup/objectId
    }
}

[alex-frankel]

Another issue is that the createmode key does not accept a string if you want this to be a parameter in bicep. It needs to be on of the following values: ( Default | GeRestore | PointInTimeRestore | Replica) (screenshot)

This is because the createMode property actually affects the shape of all the other properties that follow it, so having this be a parameter means there's only so much we can validate. We advise against this pattern, but we admittedly don't have great alternatives at the moment. You could try something like the following:

param createMode string {
  default: 'GeoRestore'
  allowed: [
    'GeoRestore'
    'Replica'
  ]  
}

resource postgres 'microsoft.dbforpostgresql/servers@2017-12-01' = if (createMode == 'GeoRestore') {
  name: 'foo'
  location: 'eastus'
  properties: {
    createMode: 'GeoRestore'
    sourceServerId: '<ID>'
  }
}

resource postgres2 'microsoft.dbforpostgresql/servers@2017-12-01' = if (createMode == 'Replica') {
  name: 'foo2'
  location: 'eastus'
  properties: {
    createMode: 'Replica'
    sourceServerId: '<ID>'
  }
}

I'll caveat that this is a bit awkward because you would end up with two different symbolic names for the resources (there's also a separate bug (#1410) that I just found that requires the actual names to be different). Ideally, if we implement if/else (#1171) syntax this gets easier.

The issue I'm having at the moment is that the extra keys are not and extra object in the ServerPropertiesForCreate object.
Which limits a more dynamic setup for a bicep module (E.G.: use of variables).

This one I am not sure I'm following, but might also relate to the above issue. If I hardcode the value of createMode, intellisense & validation are working as expected:

If I set it to a var, I don't get any warnings, but intellisense no longer shows possible properties:

Once we have constant folding (#444), this should be resolved right @majastrz / @anthony-c-martin ?

[StijnDevogel]

@alex-frankel,

You are right that you can fill in the value into a variable.
I did not explain my variable example very well. it was a suggestion based on my proposed solution.
You can ignore that as it sounds right in my head, but I can't translate it well enough on paper.

If/else would indeed help to persuade the DRY principle.
I'm aware that the createMode property affects other properties.
That's why I proposed an object that could hold both the mode you need for postgreSQL as the additional properties it relies on. But that would affect the API.

On a sidenote: compute/virtualmachine has the same issue with certain properties.
Depending if you choose windows or linux (wadconfig/ladconfig,...)

[alex-frankel]

Yeah this discriminator pattern leads to some interesting API design questions. I think we'll revisit this issue when we have if/else, but unfortunately I'm not sure what we could do to make this easier in the meantime other than the Postgres team revisiting their API design.