Comment utiliser DocumentDb, LINQ et F # pour renvoyer plusieurs propriétés?

Question

Obtention d'une erreur lors de l'exécution de la version F # du code ci-dessous alors que la version C# ci-dessous fonctionne. Des idées sur la façon de retourner plusieurs propriétés documentdb à partir d'une requête linq avec F # en général?

2016-12-29T23:57:08.504 Exception while executing function: Functions.GetTags. mscorlib: Exception has been thrown by the target of an invocation. mscorlib: One or more errors occurred. Microsoft.Azure.Documents.Client: Constructor invocation is not supported.  

C#

var userTagsQuery = 
    userDocument.Where(user => user.topics != null && user.education != null) 
    .Select(user => new {topics=user.topics, education=user.education}); 

F #

type UserTagRecord = {topics : string list; education : string list} 
    let userTagsQuery = 
    user.Where(fun user -> user.topics <> null && user.education <> null) 
    .Select(fun user -> {topics=user.topics :?> string list; education=user.education :?> string list}) 

Answer 1

L'erreur dit "invocation Constructor est pas pris en charge". C'est une limitation raisonnable, la plupart des fournisseurs LINQ l'ont.

Dans votre code F #, l'appel du constructeur est la création de l'enregistrement. Les enregistrements F # sont compilés en tant que classes avec un ensemble de propriétés en lecture seule et un seul constructeur qui prend les valeurs de ces propriétés en tant que paramètres. Selon le message d'erreur, l'appel de ce constructeur n'est pas pris en charge. Malchance. Une chose intéressante à noter est que les types anonymes C# (employés dans votre code C#) fonctionnent exactement de la même manière que les enregistrements F # - ce sont des classes avec un tas de propriétés en lecture seule et un seul constructeur, - et pourtant, ils sont soutenus. La gestion des types anonymes C# en tant que cas particulier est, encore une fois, une pratique courante pour les fournisseurs LINQ. Beaucoup de fournisseurs de LINQ géreraient cela de manière plus générale, ce qui couvrirait aussi les enregistrements F #, mais dans ce cas, ce n'est apparemment pas le cas. Si j'étais vous, j'ouvrirais un problème à ce sujet.

Ce que vous pouvez essayer est de remplacer votre dossier avec une classe avec des propriétés mutables et construire avec la syntaxe d'initialisation de la propriété:

type UserTagRecord() = 
    member val topics : string list = [] with get, set 
    member val education : string list = [] with get, set 

let userTagsQuery = 
    user 
     .Where(fun user -> user.topics <> null && user.education <> null) 
     .Select(fun user -> UserTagRecord(topics=user.topics :?> string list, education=user.education :?> string list)) 

Je voudrais aussi aller sur une branche ici et suggère que vous pourriez avoir plus problème avec l'utilisation des listes F #. Premièrement, DocumentDb pourrait ne pas les aimer par eux-mêmes, et deuxièmement, je ne sais pas ce que sont user.topics et user.education, mais je suis assez sûr qu'ils ne sont pas une sous-classe de string list, donc vos lancements échoueront probablement.