jab,

Oh the joys of working with #csharp and #dotnet

Here we got a class, in our regular #odata controller functions it produces #camelCase like we tell it to in our settings. However, in our non-base controller function it produces #PascalCase ... because, duck us?

Only on the expanded parts which are handled a little bit differently for efficiency, hense the need for the non-base controller function with odata.

Why, oh why didn't we do this with #graphql and something like #quarkus or even #fastapi?

TimPurdum,

@jab in both Newtonsoft.json and System.Text.Json, there is a way to control this behavior via "options" or custom converters. If it's part of your framework it might be obscured, but I would look for ways to adjust json serialization settings.

jab,

@TimPurdum but we did. I’m not sure if it’s because we are also using asp.versioning on top of it all. Which we probably shouldn’t have done to be completely honest, because so far we only have one version and it’s looking like we might never expose this outside our own frontend.

We’ve handled it by parsing the JSON on the consumption side. Not in our client in-house package for OData in Typescript but directly where it is consumed. That’ll have to do for now.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • CSharp
  • ngwrru68w68
  • rosin
  • GTA5RPClips
  • osvaldo12
  • love
  • Youngstown
  • slotface
  • khanakhh
  • everett
  • kavyap
  • mdbf
  • DreamBathrooms
  • thenastyranch
  • magazineikmin
  • megavids
  • InstantRegret
  • normalnudes
  • tacticalgear
  • cubers
  • ethstaker
  • modclub
  • cisconetworking
  • Durango
  • anitta
  • Leos
  • tester
  • provamag3
  • JUstTest
  • All magazines