Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accept ref to azure.core.exceptions.OdataV4Format in model definition. #2853

Open
lmazuel opened this issue Sep 23, 2024 · 0 comments
Open
Assignees

Comments

@lmazuel
Copy link
Member

lmazuel commented Sep 23, 2024

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:

details: List[ODataV4Frmat] = rest_field(ref=azure.core.exceptions.OdataV4Format)

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:

@ref("azure.service.MyType")
property: TypeWeDontGenerate

But it's another story for later, and doesn't impact what we're doing here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants