I have a MongoDB collection and I'm trying to update all the entries in it to change the name of a field used to store a reference. The Query I'm using is
db.products.find().forEeach(function(p) {
p.newField = p.oldField;
db.products.save(p);
});
The problem is that p.oldField is a DBRef following the standard format of { "$ref": "collection", "$id": ObjectId("...")}. When I try to run the db.products.save(p); Mongo returns the following error:
Sat Oct 1 13:00:57 uncaught exception: field names cannot start with $ [$db]
I'm using version 1.8.2 of the MongoDB shell. I have seen this work on an older version of the shell (1.6.5), which is where I originally came up with this query. But I can't seem to make this work on newer versions.
Related
Updated to pymongo 4.1.1 and upgraded mongoengine to 0.24.1 but received the following error:
pymongo/collection.py", line 1610, in find
return Cursor(self, *args, **kwargs)
TypeError: __init__() got an unexpected keyword
argument 'modifiers'
I was under the impression the latest versions would work together. Are they not compatible? The error appears in pymongo itself and not in my code.
This pymongo error seems to come from a removed option.
From the pymongo API docs:
Changed in version 4.0: Removed the modifiers option. Empty
projections (eg {} or []) are passed to the server as-is, rather than
the previous behavior which substituted in a projection of {"_id": 1}.
This means that an empty projection will now return the entire
document, not just the "_id" field.
In addition, currently (2022-05-04) there seem to be several pymongo >= 4.0 issues against the mongoengine codebase.
I'm getting an error for mongo query in mongo version 3.6.22 error as follows
MongoError: arguments to $lookup must be strings, let: { profileIds:
"$ProfileIDs" } is type object
But this same query works fine in mongo version 4.4.3 enterprise, and the ProfileIDs are String
3.6 does not support let in $lookup. You need to write your query differently.
when I run any query containing $expr operation against Embedded Mongo I get the following error:
UncategorizedMongoDbException: Query failed with error code 2 and error message 'unknown top level operator: $expr' on server
The command runs fine against my local instance of mongo.
This is the version of embedded mongo I'm using: testCompile('de.flapdoodle.embed:de.flapdoodle.embed.mongo:2.1.1')
This is the query for reference:
Criteria.where("$expr").ne(Arrays.asList("$val.a", "$val.b"))
Found it.
flapdoodle was downloading a version of Mongodb that didn't have that feature by default.
You can override the default version by specifying the following in your
src/test/resources/application.properties
spring.mongodb.embedded.version=3.6.4
spring.mongodb.embedded.features=SYNC_DELAY,NO_HTTP_INTERFACE_ARG,ONLY_WITH_SSL
When i try to insert data on mongodb 3 through command line it's showing following error
use video;
switched to db video
db.movies.insertOne({ "title": "Jaws", "year": 1975, "imdb": "tt0073195" });
2018-03-26T12:42:42.233+0530 E QUERY TypeError: Property 'insertOne' of object video.movies is not a function at (shell):1:11`
but video db also not created
Please help me to rectify this problem.
MongoDB supports db.collection.insertOne() from version 3.2, please check your mongodb version by using the mongo shell command
db.version()
References:
insertOne
version
Try with db.movies.insert instead of db.movies.insertOne and check If it's working fine. If it's working then your mongo version is less than 3.2. If not then share your mongoDb console Screenshot.
I'm trying to dump a database from another server (this works fine), then restore it on a new server (this does not work fine).
I first run:
mongodump --host -d
This creates a folder dump/db which contains all of the bson documents.
Then in the dump folder, I'm running:
mongorestore -d dbname db
This works and iterates through the files, but I get this error on dbname.system.users
Wed May 23 02:08:05 { key: { _id: 1 }, ns: "dbname.system.users", name: "_id_" }
Error creating index dbname.system.usersassertion: 13111 field not found, expected type 16
Any ideas how to resolve this?
If it realy different versions, use --noIndexRestore option. And create all index after that.
Any chance the source and destination are different versions?
In any case, to get around this, restore the collections individually using the -c flag to the target DB and then build the indexes afterward. The system collection is the one used for indexes, so it is fairly easy to recreate - try it last once everything else has been restore, and if it still fails you can always just recreate the relevant indexes.
The issue could also caused by this bug in older versions of Mongo (In my case it was 2.0.8):
https://jira.mongodb.org/browse/SERVER-7181
Basically, you get 13111 field not found, expected type 16 error when it should actually be prompting you to enter your authentication details.
And example of how I fixed it:
root#precise64:/# mongorestore /backups/demand/ondemand.05-24-2013T114223/
connected to: 127.0.0.1
[REDACTED]
Fri May 24 11:48:15 going into namespace [test.system.indexes]
Fri May 24 11:48:15 { key: { _id: 1 }, ns: "test.system.users", name: "_id_" }
Error creating index test.system.usersassertion: 13111 field not found, expected type 16
# Error when not giving username and password
root#precise64:/# mongorestore -u fakeuser -p fakepassword /backups/demand/ondemand.05-24-2013T114223/
connected to: 127.0.0.1
[REDACTED]
Fri May 24 11:57:11 /backups/demand/ondemand.05-24-2013T114223/test/system.users.bson
Fri May 24 11:57:11 going into namespace [test.system.users]
1 objects found
# Works fine when giving username and password! :)
Hope that helps anyone who's issue doesn't get fixed by the previous 2 replies!
This can also happen if you are trying to mongorestore into MongoDB 2.6+ and the dump you are trying to restore contains a system.users table in any database other than admin. In MongoDB 2.2 and 2.4 the system.userscollections could occur in any database. The auth schema migration associated with MongoDB 2.6 moved all users into the system.users table in the admin database, but left behind the system.users tables in the other databases (MongoDB 2.6 just ignores these). This seems to cause this assertion when importing into MongoDB 2.6.