You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We know for quite some time that at some point, we would need to support a way to have codegen ref an externally defined type, and not generate code for a model. This could be used to point to an azure-core type, or to a patched type.
Part of this, we discussed with @iscai-msft to support an update in rest_field that would look like this:
IOW, a way to explain that this rest_field points to something else.
The scope of this issue is to support the first scenario that Fundations.Error will ref to azure.core.exceptions.ODataV4Format. In the particular case of that class, since azure.core.exceptions.ODataV4Format do not support a common deserilization contract, we should have a if statement in model base to deserilize properly by calling the constructor.
Long term, we should conclude on the deserialization contract required for ref, and update azure-core ODataV4Format acordingly, but short term a quick hack wouldn't hurt anyone, and it will be transparent for users.
This particular isue, we initiate the ref because we recognized a known type from TSP Azure.Core. Long term, we likely would need a decorator like this:
We know for quite some time that at some point, we would need to support a way to have codegen ref an externally defined type, and not generate code for a model. This could be used to point to an azure-core type, or to a patched type.
Part of this, we discussed with @iscai-msft to support an update in rest_field that would look like this:
IOW, a way to explain that this
rest_field
points to something else.The scope of this issue is to support the first scenario that
Fundations.Error
will ref toazure.core.exceptions.ODataV4Format
. In the particular case of that class, sinceazure.core.exceptions.ODataV4Format
do not support a common deserilization contract, we should have aif
statement in model base to deserilize properly by calling the constructor.Long term, we should conclude on the deserialization contract required for ref, and update azure-core ODataV4Format acordingly, but short term a quick hack wouldn't hurt anyone, and it will be transparent for users.
This particular isue, we initiate the ref because we recognized a known type from TSP Azure.Core. Long term, we likely would need a decorator like this:
But it's another story for later, and doesn't impact what we're doing here.
The text was updated successfully, but these errors were encountered: