azure-cosmos-dotnet-v3: Latest release does not fix GetItemLinqQueryable issue [Still broken 3/2/23]
Describe the bug
#3406 does not completely address #3207, with respect to enum handling in LINQ queries; it will still use the enum’s integer value, discarding the serializer preference set on the Cosmos context;
i.e.
enum MyEnum
{
ValueA = 0
}
When querying
query.Where(c => c.Item == MyEnum.ValueA)
will translate to
WHERE root["Item"] = 0
-- Should be WHERE root["Item"] == "ValueA", if JsonStringEnumConverter is configured on JSON Serializer settings
About this issue
- Original URL
- State: open
- Created a year ago
- Reactions: 1
- Comments: 20 (15 by maintainers)
I haven’t been able to get around to this yet. I’m hoping I will be able to tackle it in May
Bump!
May was a few months ago. Any update?
@onionhammer Are you using System.Text.Json in your custom serializer? If so, I’d try decorating the property with
[System.Text.Json.Serialization.JsonConverterAttribute(typeof(System.Text.Json.Serialization.JsonStringEnumConverter))](full namespaces included for clarity)
What’s literally bonkers about this is, we’re using the custom serializer 100% as intended, and it’s FUNDAMENTALLY BROKEN. And it has been FUNDAMENTALLY BROKEN for numerous releases. Do the people coding this not realize how their code is intended to be used? Both inexplicable and unforgiveable. Where’s the testing? Where are the unit tests? Where’s QA? Where’s the PM? Where’s the accountability?
I’ll go ahead and add that the 3.32.0 release also does not properly handle the property name, i.e. if the converter specifies camel casing, the where clause should be
WHERE root[“item”] = 0
and not
WHERE root[“Item”] = 0
And to be super specific, in the case of System.Text.Json (which is what everyone attempting to use custom converters is doing), if the property is decorated with the System.Text.Json.Serialization.JsonPropertyNameAttribute, that’s what should be showing up in the sql query.
And to state the obvious, all of these cases should be covered in unit tests.
A new SDK release containing the hot fix to revert the code change that introduces this regression has been released. I am still working on another fix for the original issue.
We are actively investigating this issue from our side. As a temporary mitigation, we will be reverting the PR that introduces this regression and put out a more wholistic fix that addresses the original issue