Le littéral composite utilise des champs sans clé

Question

Je travaille avec le nouveau pilote officiel mongodb pour golang. J'ai créé une requête complexe pour insérer les données dans la base de données Mongo, puis les trier en fonction de la valeur d'un élément. J'utilise un filtre dans lequel j'ai créé le type bson en utilisant :-.

filter := bson.D{{"autorefid", "100"}}

Mais il affiche un avertissement disant :

primitive.E littérale composite utilise des champs non clavés

Les avertissements créent un désordre dans mon code.

Answer 1

Les avertissements peuvent être arrêtés en mettant le drapeau de contrôle à false.

$ go doc cmd/vet

Par défaut, tous les contrôles sont effectués. Si un drapeau est explicitement défini à true, seuls ces tests sont exécutés. Inversement, si un drapeau est explicitement mis à faux, seuls ces tests sont désactivés. Ainsi, -printf=true exécute le test printf, -printf=false exécute tous les tests sauf le test printf.

Unkeyed composite literals

Flag: -composites

Composite struct literals that do not use the field-keyed syntax.

Mais l'avertissement est dû au fait que le nom de la clé n'a pas été fourni lors de la définition de la valeur dans l'application. primitive.E struct.

Touches de réglage pour primitive.E struct supprimera les messages d'avertissement. Par exemple

filter := bson.D{primitive.E{Key: "autorefid", Value: "100"}}

Le paquet primitive contient des types similaires aux primitives Go pour BSON. peuvent ne pas avoir de représentations directes des primitives de Go.

type E struct {
    Key   string
    Value interface{}
}

E représente un élément BSON pour un D. Il est généralement utilisé à l'intérieur d'un D.

Pour plus d'informations, consultez le site primitif.E

Answer 2

Puisque personne d'autre ne l'a signalé, l'avertissement est là pour vous protéger contre les modifications de l'API d'un tiers qui briseraient votre code en silence.

Ignorer cela vet peut potentiellement conduire à des bogues d'exécution vraiment désagréables et difficiles à détecter. toujours spécifier les clés de la tierce partie struct s explicitement .

Ce serait le cas si les responsables de la bibliothèque que vous utilisez décidaient de changer l'ordre des éléments dans leur fichier struct pour quelque raison que ce soit. Par exemple, la commutation Key avec Value dans le cas de l'OP. Votre code semblerait toujours bien compiler, mais ce que vous vouliez être la clé serait maintenant passé comme valeur et vice versa, et les choses commenceraient à se briser de manière inattendue.

Answer 3

Vous pouvez simplement changer :

filter := bson.D{{"autorefid", "100"}}

à :

filter := bson.D{{Key: "autorefid", Value: "100"}}

//Skip primitive.E comme dit par Chris W

Answer 4

Vous pouvez changer :

filter := bson.D{{"autorefid", "100"}}

à :

filter := bson.D{primitive.E{Key: "autorefid", Value: "100"}}

Answer 5

En fait, si commandé la représentation d'un document BSON n'est pas nécessaire, vous pouvez modifier votre document BSON pour non ordonné représentation en changeant simplement

filter := bson.D{{"autorefid", "100"}}

à

filter := bson.M{"autorefid": "100"}

Voir ce réponse de stackoverflow pour plus de détails sur bson.D vs bson.M . Le serveur MongoDB est suffisamment intelligent pour trouver les indices correspondants, quel que soit l'ordre utilisé.