Composite key drops from routing after calling ODataConventionModelBuilder.EnableLowerCamelCase()

[spencershoell]

Assemblies affected ASP.NET Core OData 8.x

Describe the bug A clear and concise description of what the bug is.

Reproduce steps Grab sample from https://github.com/OData/AspNetCoreOData/tree/main/sample/ODataRoutingSample and run it without modification. The OData Endpoint Routing Debugger shows People(FirstName={keyFirstName},LastName={keyLastName}) as being a valid route.

In EdmModelBuilder class https://github.com/OData/AspNetCoreOData/blob/main/sample/ODataRoutingSample/Models/EdmModelBuilder.cs Add call to builder.EnableLowerCamelCase() in the GetEdmModel() method

Rebuild the app, and the People(FirstName={keyFirstName},LastName={keyLastName}) has dropped off

Data Model https://github.com/OData/AspNetCoreOData/blob/main/sample/ODataRoutingSample/Models/Person.cs

Expected behavior I would expect the composite key route to remain after changing to the Camel Case convention

[xuzhg]

@spencershoell EnableLowerCamelCase() calling changes the property name, including the key property.

By default, we use the case-sensitive to match the argument name with the property name in the model. So, if you 'EnableLowerCamelCase()', remember to change the argument in the controller's action.

https://github.com/OData/AspNetCoreOData/blob/main/sample/ODataRoutingSample/Controllers/PeopleController.cs#L48

Change public IActionResult Get(string keyFirstName, string keyLastName)

to public IActionResult Get(string keyfirstName, string keylastName)

should work.

If you don't want to change, we also have the option to enable property name case-insensitive. Set https://github.com/OData/AspNetCoreOData/blob/main/src/Microsoft.AspNetCore.OData/Routing/ODataRouteOptions.cs#L49 to true should work also.

Let me know any result. Thanks.

[spencershoell]

Thank you, that worked perfectly.

[corranrogue9]

Glad this worked for you @spencershoell, I'm going to re-open so that we can avoid future consumers from needing to use the same workaround.

[xuzhg]

We can draft a doc to include the information/tutorial here for other customers and close the issue.

[julealgon]

I'm going to re-open so that we can avoid future consumers from needing to use the same workaround.

It really is not a workaround but the intended design it looks like. Leaving an issue open as a form of documentation is a really bad idea IMHO.

[corranrogue9]

Thanks @julealgon, I wasn't intending to leave it open forever, but instead to address the fact that the intended design leaves consumers of the library confused after taking a natural approach to the behavior flag. I don't think that odata libraries should be dictating how customers case their variables so that we can avoid requiring them to set a few different booleans, and I also think that we should probably be setting those booleans on their behalf when it's really the only meaningful thing to do.

[corranrogue9]

After working through the issue and discussing with the team, I have created this issue to track instead, since the change requires some additional feature work in a couple of libraries, and changes are needed across repositories.

[xuzhg]

https://github.com/OData/AspNetCoreOData/blob/main/src/Microsoft.AspNetCore.OData/Extensions/ActionModelExtensions.cs#L92

[xuzhg]

https://github.com/OData/AspNetCoreOData/blob/main/src/Microsoft.AspNetCore.OData/Edm/EdmModelAnnotationExtensions.cs#L166

[corranrogue9]

Sam sent me this pointer for when the routes are built, I will look at what updates we can make so that this is more intuitive in the future. The serialization can be found here