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

How to disable @odata.type Field in serialized Object #3064

Open
gathogojr opened this issue Sep 18, 2024 Discussed in #3011 · 1 comment
Open

How to disable @odata.type Field in serialized Object #3064

gathogojr opened this issue Sep 18, 2024 Discussed in #3011 · 1 comment

Comments

@gathogojr
Copy link
Contributor

Discussed in #3011

Originally posted by TobiasForbrich July 1, 2024
Hi community,

sorry for my bad english and probably stupid question: I am using the new OData Client for .NET 8.0 and have following issue:

I have a given OData Rest API Service with a Object "ProductionOrder" which has several Enum-Properties.

When I create a POST Message using the DataServiceContext Client-Classes generated by the ConnectedServices Visual Studio Plug-In, the serialized JSON-Body contains extra "@odata.type" fields for each Enum-Member of the ProductionOrder. Here a simplified example with the enum-Property "Status"

{ "@odata.type": "#MESOGanttplan.Api.Module.BusinessObjects.ProductionOrder", "ProductionOrderId": "test2", "[email protected]": "#MESOGanttplan.Model.Enums.ProductionOrderStatusEnum", "Status": "NotPlanned" }

The Backend OData Service I use can't handle this extra properties and fails.
If I manually remove the "[email protected]" property, like following, the request succeeds.

{ "@odata.type": "#MESOGanttplan.Api.Module.BusinessObjects.ProductionOrder", "ProductionOrderId": "test2", "Status": "NotPlanned" }

Is there any way to avoid the extra Json-Field for the enum-Propertytypes?

A am happy for any advice!
regards,
Tobias

@gathogojr
Copy link
Contributor Author

I tested this and confirmed that OData client includes @odata.type property annotations for both declared and dynamic enum properties. This is odd behaviour because we don't do the same for other declared properties.

It'd probably be a breaking change to rectify it in a minor version but we can consider it for the next major release

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

No branches or pull requests

1 participant