|
This is precisely why fields containing dots are not considered valid for storage, and the storage validation checks have to be overridden/ignored in order to get the documents in there in the first place (or they are legacy docs).
When you say:
db.test.update({}, { $rename : { "a.b" : "ab" }}, false, true)
|
^^^^^
|
or even just:
db.test.find( { "a.b" : "foobar" } )
|
^^^^^
|
is the "a.b" supposed to refer to a field like this:
{ _id: ..., "a.b": "foobar" }
|
^^^^^^^^^^^^^^^
|
or to a field like this:
{ _id: ..., a: { b: "foobar" } }
|
^^^^^^^^^^^
|
In the presence of dots in field names, this is always hopelessly ambiguous. You can't even query properly for fields like that. This is why dots are not allowed in field names, and the server chooses to interpret "a.b" in the latter style.
This means that the $rename operator will be looking for a field "a", not finding it, and so correctly performing a no-op. (eg. see SERVER-20171 and SERVER-15029.)
Fixing any documents that do happen to contain dotted fields like this will likely involve manually scanning and adjusting them (probably client-side).
|