Comme mentionné dans d'autres réponses, MongoDB n'autorise pas les caractères $
ou .
comme clés de carte en raison des restrictions sur les noms de champ . Cependant, comme mentionné dans Dollar Sign Operator Échapper à cette restriction ne vous empêche pas d' insérer des documents avec de telles clés, cela vous empêche simplement de les mettre à jour ou de les interroger.
Le problème du simple remplacement .
par [dot]
ou U+FF0E
(comme mentionné ailleurs sur cette page) est le suivant: que se passe-t-il lorsque l'utilisateur souhaite légitimement stocker la clé [dot]
ou U+FF0E
?
Une approche adoptée par le pilote afMorphia de Fantom consiste à utiliser des séquences d'échappement unicode similaires à celles de Java, mais en veillant à ce que le caractère d'échappement soit d'abord échappé. En substance, les remplacements de chaînes suivants sont effectués (*):
\ --> \\
$ --> \u0024
. --> \u002e
Un remplacement inversé est effectué lorsque les clés de la carte sont ensuite lues à partir de MongoDB.
Ou en code Fantom :
Str encodeKey(Str key) {
return key.replace("\\", "\\\\").replace("\$", "\\u0024").replace(".", "\\u002e")
}
Str decodeKey(Str key) {
return key.replace("\\u002e", ".").replace("\\u0024", "\$").replace("\\\\", "\\")
}
Le seul moment où un utilisateur doit être conscient de ces conversions est lors de la construction de requêtes pour ces clés.
Étant donné qu'il est courant de stocker dotted.property.names
dans des bases de données à des fins de configuration, je pense que cette approche est préférable à l'interdiction simplement de toutes ces clés de carte.
(*) afMorphia exécute en fait des règles d'échappement Unicode complètes / appropriées comme mentionné dans la syntaxe d'échappement Unicode en Java, mais la séquence de remplacement décrite fonctionne tout aussi bien.