It has been pointed out in previous responses that MongoDB does not permit the use of characters like $ or . as map keys due to limitations on field names. However, according to information provided in the Dollar Sign Operator Escaping section, this restriction only applies to updating or querying documents with such keys, not inserting them.

The issue with simply replacing . with [dot] or

U+FF0E</code is what happens when a user legitimately wants to store a key as <code>[dot]

U+FF0E</code?</p>

<p>An alternative approach taken by Fantom's afMorphia driver is to utilize unicode escape sequences similar to Java, while ensuring the escape character is escaped first. This involves making the following string replacements:</p>

<pre><code>\  -->  \\
$  -->  \u0024
.  -->  \u002e

A reverse replacement is performed when reading map keys from MongoDB.

In Fantom code:

Str encodeKey(Str key) {
    return key.replace("\\", "\\\\").replace("\$", "\\u0024").replace(".", "\\u002e")
}

Str decodeKey(Str key) {
    return key.replace("\\u002e", ".").replace("\\u0024", "\$").replace("\\\\", "\\")
}

Users only need to consider these conversions when creating queries for such keys. Given the common practice of storing dotted.property.names in databases for configuration purposes, I find this approach more favorable than outright banning all map keys with special characters.

* afMorphia enforces proper Unicode escaping rules as described in Unicode escape syntax in Java, but the mentioned replacement sequence functions effectively as well.

The most recent update (v3.6.1) for MongoDB now allows for the use of dots (.) in both keys and field names.

Field names are now able to include dots (.) and dollar ($) characters

The MongoDB documentation recommends replacing special characters like $ and . with their corresponding Unicode versions.

In order to avoid conflicts, keys should replace the reserved $ and . symbols with alternate characters. It is suggested to use the full-width Unicode equivalents: U+FF04 (i.e. “＄”) and U+FF0E (i.e. “．”).

I recently came up with a new solution that I am extremely pleased with. The key name and value are now separated into individual fields, allowing me to maintain the characters identically without having to deal with any parsing hassles. The formatted document now appears as:

{
    ...
    keyName: "domain.com",
    keyValue: "unregistered",
    ...
}

Querying this information is still simple; just perform a find operation on both the keyName and keyValue fields.

Instead of using:

 db.collection.find({"domain.com":"unregistered"})

which may not yield the desired results, you should run:

db.collection.find({keyName:"domain.com", keyValue:"unregistered"})

This will provide you with the expected document.

If you want to enhance security, consider utilizing a hash in place of the value within the key and then saving that hash value within the JSON structure.

var crypto = require("crypto");

function md5(value) {
    return crypto.createHash('md5').update( String(value) ).digest('hex');
}

var data = {
    "_id": {
        "$oid": "..."
    },
    "make": "saab",
    "models": {}
}

var version = "9.7x";

data.models[ md5(version) ] = {
    "version": version,
    "years" : [
        2007,
        2008,
        2009,
        2010
    ]
}

In the future, you can retrieve the models by referencing the hash code.

var version = "9.7x";
collection.find( { _id : ...}, function(e, data ) {
    var models = data.models[ md5(version) ];
}

Now it's officially supported

MongoDb 3.6 now allows the use of dots and dollar signs in field names. Check out this related JIRA ticket:

Consider upgrading your Mongodb version to 3.6 or higher for optimal functionality.

In order to protect your keys, it is essential to escape them properly. Many individuals struggle with understanding the process of escaping strings, so here are simple steps to help:

1. Start by selecting an escape character that is not commonly used. For example, you can choose '~'.
2. When escaping, begin by substituting all occurrences of the escape character with a specific sequence preceded by your chosen escape character (e.g. '~' becomes '~t'). Then replace the targeted character or sequence with another sequence preceded by the escape character (e.g. '.' turns into '~p').
3. For unescaping, start by eliminating the escape sequences from all instances of your second escape sequence (e.g. '~p' transforms back to '.'). Next, convert your escape character sequence back to a single escape character (e.g. '~s' reverts to '~').

Additionally, keep in mind that MongoDB restricts keys that begin with '$', requiring a similar approach for handling such cases.

Below is a piece of code that executes this process efficiently:

// Function to escape a MongoDB key
exports.escape = function(key) {
  return key.replace(/~/g, '~s')
            .replace(/\./g, '~p')
            .replace(/^\$/g, '~d')
}

// Function to unescape a MongoDB key
exports.unescape = function(escapedKey) {
  return escapedKey.replace(/^~d/g, '$')
                   .replace(/~p/g, '.')
                   .replace(/~s/g, '~')
}

According to the MongoDB documentation, key names cannot contain the '.' character. You may need to devise an encoding method or find an alternative solution.

Although this response is slightly delayed, in the case of utilizing Spring and Mongo together, Spring can handle the conversion process for you using MappingMongoConverter. This approach was initially proposed by JohnnyHK but implemented through Spring.

@Autowired
private MappingMongoConverter converter;

@PostConstruct
public void configureMongo() {
 converter.setMapKeyDotReplacement("xxx");
}

If your stored JSON looks like this:

{ "axxxb" : "value" }

When accessed through Spring (MongoClient), it will be interpreted as:

{ "a.b" : "value" }

One suggestion raised by a different user is that encoding or decoding this may pose challenges in the future, so it might be simpler to just substitute all keys containing a period. Below is a recursive function I crafted to replace keys with '.' occurrences:

def modify_json_keys(dictionary):
    new_dict = {}
    if type(dictionary) is dict:
        for k, v in dictionary.items():
            new_k = k.replace('.', '-')
            if type(v) is dict:
                new_dict[new_k] = modify_json_keys(v)
            elif type(v) is list:
                new_dict[new_k] = [modify_json_keys(i) for i in v]
            else:
                new_dict[new_k] = dictionary[k]
        return new_dict
    else:
        return dictionary

if __name__ == '__main__':
    with open('path_to_json', "r") as input_file:
        d = json.load(input_file)
    d = modify_json_keys(d)
    pprint(d)

You can adjust this code to also handle replacing '$' since that's another character not allowed in a MongoDB key.

In my JavaScript code, I always make sure to escape object keys properly using the following method:

key.replace(/\\/g, '\\\\').replace(/^\$/, '\\$').replace(/\./g, '\\_')

What stands out to me is that this approach specifically targets and replaces only the $ character when it appears at the beginning of a key. Additionally, by avoiding the use of unicode characters, it ensures compatibility with consoles that may not handle them well. The substitution of an underscore (_) in place of potentially problematic characters like $ or . enhances readability for future developers and maintains consistency by using standard escape sequences.

Imperfect, yet suitable for most scenarios: substitute the forbidden characters with something else. As they are part of keys, these new characters should be uncommon.

/** To ensure compatibility for MongoDB insert, this function replaces \ with ⍀, ^$ with '₴', and dots with ⋅ in the object.
Caveats:
    1. If your original documents contain ⍀, ₴ or ⋅, they will be converted to \$ upon decoding.
    2. Recursive structures pose challenges. Limiting levels can prevent a stack overflow. The default max level is set at 10.
 */
encodeMongoObj = function(o, level = 10) {
    var build = {}, key, newKey, value
    //if (typeof level === "undefined") level = 20     // default level if not provided
    for (key in o) {
        value = o[key]
        if (typeof value === "object") value = (level > 0) ? encodeMongoObj(value, level - 1) : null     // Recurse if object

        newKey = key.replace(/\\/g, '⍀').replace(/^\$/, '₴').replace(/\./g, '⋅')    // Replace prohibited chars in mongo keys
        build[newKey] = value
    }
    return build
}

/** Decode an object encoded using the above function. Assumes non-recursive structure from Mongodb */
decodeMongoObj = function(o) {
    var build = {}, key, newKey, value
    for (key in o) {
        value = o[key]
        if (typeof value === "object") value = decodeMongoObj(value)     // Recurse if object
        newKey = key.replace(/⍀/g, '\\').replace(/^₴/, '$').replace(/⋅/g, '.')    // Replace prohibited chars in mongo keys
        build[newKey] = value
    }
    return build
}

Try it out:

var nastyObj = {
    "sub.obj" : {"$dollar\\backslash": "$\\.end$"}
}
nastyObj["$you.must.be.kidding"] = nastyObj     // Make it recursive

var encoded = encodeMongoObj(nastyObj, 1)
console.log(encoded)
console.log( decodeMongoObj( encoded) )

Here are the results - note that the values remain unaltered:

{
  sub⋅obj: {
    ₴dollar⍀backslash: "$\\.end$"
  },
  ₴you⋅must⋅be⋅kidding: {
    sub⋅obj: null,
    ₴you⋅must⋅be⋅kidding: null
  }
}
[12:02:47.691] {
  "sub.obj": {
    $dollar\\backslash: "$\\.end$"
  },
  "$you.must.be.kidding": {
    "sub.obj": {},
    "$you.must.be.kidding": {}
  }
}

There is a less conventional method for querying data not advised for usage in applications, but rather for debugging purposes (specifically for embedded objects):

db.getCollection('mycollection').aggregate([
    {$match: {mymapfield: {$type: "object" }}}, //narrow down to objects with correct field type
    {$project: {mymapfield: { $objectToArray: "$mymapfield" }}}, //transform map into an array of {k: key, v: value} objects
    {$match: {mymapfield: {k: "my.key.with.dot", v: "myvalue"}}} //execute query
])

In PHP, I replace the HTML value for the dot with ".".

When stored in MongoDB, it looks like this:

  "validations" : {
     "4e25adbb1b0a55400e030000" : {
     "associate" : "true" 
    },
     "4e25adb11b0a55400e010000" : {
       "associate" : "true" 
     } 
   } 

Here is the corresponding PHP code snippet...

  $entry = array('associate' => $associate);         
  $data = array( '$set' => array( 'validations.' . str_replace(".", `"."`, $validation) => $entry ));     
  $newstatus = $collection->update($key, $data, $options);      

Utilizing Lodash pairs can transform

{ 'user.id': '12345678' }

to

[ [ 'user.id',
'12345678' ] ]

by simply using

var newObject = _.pairs(oldObject);

You have the option to save it as is and then transform it into a more readable format later

This specific code snippet was crafted in Livescript. To run it, you can head over to livescript.net website for evaluation

test =
  field:
    field1: 1
    field2: 2
    field3: 5
    nested:
      more: 1
      moresdafasdf: 23423
  field3: 3



get-plain = (json, parent)->
  | typeof! json is \Object => json |> obj-to-pairs |> map -> get-plain it.1, [parent,it.0].filter(-> it?).join(\.)
  | _ => key: parent, value: json

test |> get-plain |> flatten |> map (-> [it.key, it.value]) |> pairs-to-obj

Upon execution, this will generate

{"field.field1":1,
 "field.field2":2,
 "field.field3":5,
 "field.nested.more":1,
 "field.nested.moresdafasdf":23423,
 "field3":3}

To enhance efficiency, consider utilizing JSON.stringify to store Objects/Arrays that have keys containing dots. Then, when retrieving data from a database, parse the string back into an Object using JSON.parse for processing.

Alternatively, you could modify your schema as follows:

key : {
"keyName": "a.b"
"value": [Array]
}

The most recent version of MongoDB now allows keys with a dot, but the Java MongoDB driver does not offer support for this feature. To address this, I extracted code from the GitHub repository of the Java MongoDB driver, made necessary modifications to their isValid Key function, compiled a new JAR file, and am currently utilizing it.

Substitute the asterisk(*) or hashtag(#) with alternative characters that are never used in the authentic document. Then revert back to the asterisk(*) or hashtag(#) when accessing the document. This method will not affect the data that readers see.

You may choose the character from all characters.

In my experience with mongojs, I've noticed a strange behavior. I can successfully create a document with a dot in the key if I manually set the _id field, but it fails when the _id is auto-generated:

Example that works:

db.testcollection.save({"_id": "testdocument", "dot.ted.": "value"}, (err, res) => {
    console.log(err, res);
});

Example that does not work:

db.testcollection.save({"dot.ted": "value"}, (err, res) => {
    console.log(err, res);
});

Initially, I thought updating a document with a dot key would work, but it seems to interpret the dot as a subkey.

After observing how mongojs handles dots (subkeys), I've decided to avoid using dots in my keys to prevent any issues.

As mentioned by @JohnnyHK, it is crucial to avoid using punctuations or '.' in your keys to prevent issues as your dataset grows larger. This can lead to problems when performing operations like $merge, where accessing and comparing keys is necessary and any errors that arise can be difficult to troubleshoot. Learn from my mistakes and make sure to start off on the right foot.

Our users do not directly query properties with periods, but they have the ability to create them.

To address this, we serialize our model and replace all instances of specific fields. The period fields can appear in various locations and the data structure is unpredictable.

    var dataJson = serialize(dataObj);
    foreach(pf in periodFields) 
    {  
         var encodedPF = pf.replace(".", "ENCODE_DOT");
         dataJson.replace(pf, encodedPF);
    }

After flattening our data, we substitute the encodedPF instances with the decoded version for writing into our files

Given that a field named ENCODE_DOT is unlikely to be needed, it poses no issue in our scenario.

This results in records such as color.one being stored as colorENCODE_DOTone in the database

For file writing purposes, we revert ENCODE_DOT back to .

Starting with version 5.0, MongoDB now supports the $setField operation. Here's an example from a document: https://www.mongodb.com/docs/manual/reference/operator/aggregation/setField/

db.inventory.aggregate( [
   { $match: { _id: 1 } },
   { $replaceWith: {
        $setField: {
           field: "price.usd",
           input: "$$ROOT",
           value: 49.99
    } } }
] )