Azure-cosmos-dotnet-v2: Is LINQ not using JsonConverter ?

[scorbiere]

In Partitioning project, in Program.RunCrudAndQuerySample, the UserProfile available iteration cannot work.

            query = this.client.CreateDocumentQuery<UserProfile>(database.SelfLink).Where(u => u.Status == UserStatus.Available);
            foreach (UserProfile activeUser in query)
            {
                Console.WriteLine(activeUser); // never executed
            }

The document created has a Status value "Available" when the query generated is using the int value (0).
I could fix it with the removing of the JsonConverter attribute, but I expected the LINQ query builder to use the JsonConverter attribute to keep an homogeneous behavior.

[mutzl]

Similar use case:

[JsonProperty("ca")] 
[JsonConverter(typeof(DateTimeToEpochConverter))] 
public DateTime CreatedAt { get; set; }

DateTime compareDate; 
Client.CreateDocumentQuery<T>(...).Where(item => item.CreatedAt > compareDate);

In this example, the compareDate should also be converted by the DateTimeToEpochConverter.

This is also reported on UserVoice http://feedback.azure.com/forums/263030-documentdb/suggestions/8981752-linq-provider-should-respect-jsonconverters-on-pro

[kspearrin]

See this gist for an example using enums: https://gist.github.com/kspearrin/ffbe164c55ef102b8595

[kspearrin]

Also, I fixed the partitioning sample with this pull request for now: https://github.com/Azure/azure-documentdb-net/pull/63

[ghost]

Thanks for reporting these issues. We're working on addressing these in the next release.

[sgamperl]

When will be this issue fixed? Is there a workaround?

[jamesthurley]

It would also be helpful if it checked the list of converters in the JsonSerializerSettings (and also for the CamelCasePropertyNamesContractResolver) to save putting the attributes on every property.

At the moment I set these to JsonConvert.DefaultSettings, and the DocumentDB API picks them up for serializing/deserializing, but not for LINQ queries.

[botne]

Hi! Any news on when a fix will be included in the client to support StringEnumConverter in queries?
I have used SQL directly to mitigate this so far - but it seems like I am getting in trouble by combining SQL queries and LINQ on some queries. A fix so that StringEnumConverter works in linq queries would be greatly appreciated!

(any also if anyone has viable workarounds while waiting that would be awesome)

[ghost]

No news on this yet. the best workaround is to use SQL instead of LINQ.
I do not understand what you mean by "combining SQL queries and LINQ". are you trying to use SQL and LINQ in the same statement?

[botne]

@ryancrawcour: yes; For fun I tried to get the query through a SqlQuerySpec and then filtering with LINQ. Seems to work fine for most linq where clauses, but when playing with expressions it fails with: Method 'AsSQL' is not supported. Only LINQ Methods are supported.

For reference; the same linq filtering works when used in combination with the same base query written in linq (but then I run into the StringEnumConverter issue..)

[jstawski]

Running into the same issue: http://stackoverflow.com/questions/37489768/how-to-tell-documentdb-sdk-to-use-camelcase-during-linq-query.

Is there an estimate if or when this will be solved?

[arramac]

With https://www.nuget.org/packages/Microsoft.Azure.DocumentDB/1.10.0, we have added support for common JsonConverters in the LINQ provider - StringEnumConverter, IsoDateTimeConverter and UnixDateTimeConverter.

Note: We had to be selective in which JsonConverters we support in order to correctly handle potential type differences, versus any custom converter. If you have other popular requests, or if you do need customization, please let us know.

[erizzo]

My project is referencing Microsoft.Azure.DocumentDb 1.13.1 and we're still seeing a LINQ query that converts an enum to its numeric value. A Where() predicate like this
request => request.Source == sourceId && request.State == state

generates a query like this
{SELECT * FROM root WHERE ((root["Source"] = "5c196602-1a60-406a-81cd-1be5ac23eb18") AND (root["State"] = 0))) }

State is an enum and is correctly serialized/stored in the DB as its string value, per our serializer settings.

What might we be doing wrong? Do we have to register the JSON converters with the LINQ provider or something?