Fix bug in subtype deserialization

[annatisch]

No description provided.

[lmazuel]

@annatisch no test for that? You sure it still works with current generated code?
If I understood well the patch, now you use attribute_map keys and no more sub_type keys correct? Is this for commerce?

[annatisch]

It's mostly tested via the AutoRest tests - though I can add more deserialization tests to msrest now that we no longer have that verification...

In the older generator: Attribute name, subtype key and attribute mapping (i.e. service name) were all identical - so the attribute could be identified by the subtype key.

Older generator:
Previously we identified attribute: 'Name' by looking at the subtype key: 'Name'.

_attribute_map = {
    'Name': {'key': 'Name', 'type': 'str' },
    'location': {'key': 'Location', 'type': 'str'}
}
_subtype_map = {'Name': {'subClassA': 'SubClassA', 'subClassB': 'SubClassB'}

Now with the new generator, the subtype key and the attribute mapping are the same, but the attribute name will be pythonic (so it might be the same by chance, but likely will have alternative casing).
This means that now that attribute name must be identified by matching the attribute mapping to the subtype key. In the older generator where all the values were the same, this will make no difference.

New generator:
Now we identify attribute 'name' by matching subtype key: 'Name' with attribute['key']: 'Name'.

_attribute_map = {
    'name': {'key': 'Name', 'type': 'str' },
    'location': {'key': 'Location', 'type': 'str'}
}
_subtype_map = {'Name': {'subClassA': 'SubClassA', 'subClassB': 'SubClassB'}

So the new behavior should work with both old and new generation.

[lmazuel]

@annatisch I think I remember you told me to wait on this? What's the status now?

[annatisch]

@lmazuel
Ho. I knew there was something else lingering from 2016 that I'd forgotten about....
Sorry, I'll try and figure out where I got to with this....

[lmazuel]

@annatisch given your message, it's not what I see:
https://github.com/lmazuel/azure-sdk-for-python/blob/master/azure-mgmt-monitor/azure/mgmt/monitor/models/rule_condition.py

 _attribute_map = {
        'odatatype': {'key': 'odata\\.type', 'type': 'str'},
    }

  _subtype_map = {
        'odatatype': {'Microsoft.Azure.Management.Insights.Models.ThresholdRuleCondition': 'ThresholdRuleCondition', 'Microsoft.Azure.Management.Insights.Models.LocationThresholdRuleCondition': 'LocationThresholdRuleCondition', 'Microsoft.Azure.Management.Insights.Models.ManagementEventRuleCondition': 'ManagementEventRuleCondition'}
    }

special case because of the escaping?

[lmazuel]

Same with Machine Learning:

    _attribute_map = {
        'package_type': {'key': 'packageType', 'type': 'str'},
    }

    _subtype_map = {
        'package_type': {'Graph': 'WebServicePropertiesForGraph'}
    }

It seems both keys in both dicts are Pythonic

[lmazuel]

@annatisch I think this is included in #12?

I commited you doc update directly on master:
2ab2622