Why Mongoose cant create an index in MongoDB Atlas? - mongodb

I have a Mongoose Schema which contains a field with a certain index:
const reportSchema = new mongoose.Schema({
coords: {
type: [Number],
required: true,
index: '2dsphere'
},
…
}
It works well on my local machine, so when I connect to MongoDB through the shell I get this output for db.reports.getIndexes():
[
{
"v" : 2,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "weatherApp.reports"
},
{
"v" : 2,
"key" : {
"coords" : "2dsphere"
},
"name" : "coords_2dsphere",
"ns" : "weatherApp.reports",
"background" : true,
"2dsphereIndexVersion" : 3
}
]
Then I deploy this app to Heroku and connect to MongoDB Atlas instead of my local database. It works well for saving and retrieving data, but did not create indexes (only default one):
[
{
"v" : 2,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "weatherApp.reports"
}
]
What may cause this problem? Atlas allow to create indexes through Web GUI and it works good as well as creating indexes form the shell. But Mongoose fails this operation for some reason.

I had the same issue when I was on mongoose version v5.0.16. However, since I updated to v5.3.6 it is now creating the (compound) indexes for me on Mongo Atlas. (I just wrote a sample app with both versions to verify this is the case).
I'm not sure which version fixed this issue, but it's somewhere between v5.0.16 and v5.3.6, where v5.3.6 is working.

Related

Why does dropping the last collection drop the database as well

I am trying to delete a collection from database using script file (.js).
My js file is a below
db1 = db.getSiblingDB('Books');
db1.TestBook.drop();
and executing like below
mongo localhost:27017 "d:/test.js"
When my database has multiple collection it is deleting that collection means "TestBook".
But if I try to deleted the last collection it is deleting the database as well.
Can anyone suggest what I am doing wrong.
This appears to be how MongoDB works:
MongoDB Enterprise > db.foo.insert({a:1})
WriteResult({ "nInserted" : 1 })
MongoDB Enterprise > db.getSiblingDB('admin').runCommand({listDatabases:1})
{
"databases" : [
{
"name" : "admin",
"sizeOnDisk" : NumberLong(8192),
"empty" : false
},
{
"name" : "config",
"sizeOnDisk" : NumberLong(12288),
"empty" : false
},
{
"name" : "local",
"sizeOnDisk" : NumberLong(8192),
"empty" : false
},
{
"name" : "test",
"sizeOnDisk" : NumberLong(8192),
"empty" : false
}
],
"totalSize" : NumberLong(36864),
"totalSizeMb" : NumberLong(0),
"ok" : 1
}
MongoDB Enterprise > db.foo.drop()
true
MongoDB Enterprise > db.getSiblingDB('admin').runCommand({listDatabases:1})
{
"databases" : [
{
"name" : "admin",
"sizeOnDisk" : NumberLong(8192),
"empty" : false
},
{
"name" : "config",
"sizeOnDisk" : NumberLong(12288),
"empty" : false
},
{
"name" : "local",
"sizeOnDisk" : NumberLong(8192),
"empty" : false
}
],
"totalSize" : NumberLong(28672),
"totalSizeMb" : NumberLong(0),
"ok" : 1
}
However, it appears that the database retains at least some of the configured state for the dropped database. For example, if you enable sharding on a database, then drop the last collection, then try to enable sharding on a new collection in that database, sharding on the collection will be enabled which requires the sharding to have already been enabled on the database.
Dropping collections does change the list of returned databases, which could be problematic for applications. You can report this as an issue via https://jira.mongodb.org/browse/server if you like.

Removing index from mongodb

I am new in MongoDB and did an import of DB to my local. I get the following error after running my node app.
(node:1592) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1): MongoError: exception: Index with name: expires_1 already exists with different options
I logged in to the mongo console and got the following indexes for collection - Session
Indexes for sessions:
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "db_staging.sessions"
},
{
"v" : 1,
"key" : {
"expires" : 1
},
"name" : "expires_1",
"ns" : "db_staging.sessions",
"background" : true
}
]
And then I got another same index name under system.indexes
Can I remove the duplicate key from system.indexes.
Any suggestion is highly appreciated. Thanks in advance.
Try delete all datas in indexes.

mongodb single node performance

I use MongoDB for an internal ADMIN type of application used by my team.
Mongo is installed on 1 box and no replica sets.
ADMIN application inserts 70K to 100K documents/per day and we maintain 4 months of data. DB has ~100 million documents at any given time.
When the application was deployed, it all started fine for few days. As the data kept accumulated to reach the 4 months max limit, I see severe performance issues with MongoDB.
I installed MongoDB 3.0.4 as-is on a Linux box and did not fine tune any optimization settings.
Are there any optimization settings I need to adjust?
ADMIN application has schedulers which runs every 1/2 hr to insert and purge outdated data. Given below collection with indexes defined on createdDate,env,messageId,sourceSystem, I see few queries were taking 30 min to respond.
Sample query: Count of documents with a given env,sourceSystem, but between a given range of dates. ADMIN app uses grails and the above query is created using GORM. It used to work fine in the beginning. But over the period of time, performance degraded. I tried restarting the application as well. It didn't help. I believe using the MongoDB as-is (like a Dev Mode) might be causing performance issue. Any suggestions on what to tweak in settings (perhaps cpu/mem limits etc)?
{
"_id" : ObjectId("5575e388e4b001976b5e570f"),
"createdDate" : ISODate("2015-06-07T05:00:34.040Z"),
"env" : "prod",
"messageId" : "f684b34d-a480-42a0-a7b8-69d6d18f39e5",
"payload" : "JSON or XML DATA",
"sourceSystem" : "sourceModule"
}
Update:
Indices:
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "admin.Message"
},
{
"v" : 1,
"key" : {
"messageId" : 1
},
"name" : "messageId_1",
"ns" : "admin.Message"
},
{
"v" : 1,
"key" : {
"createdDate" : 1
},
"name" : "createdDate_1",
"ns" : "admin.Message"
},
{
"v" : 1,
"key" : {
"sourceSystem" : 1
},
"name" : "sourceSystem_1",
"ns" : "admin.Message"
},
{
"v" : 1,
"key" : {
"env" : 1
},
"name" : "env_1",
"ns" : "admin.Message"
}
]

In a MongoDB index, what do the options "safe" and "force" mean?

I'm looking at our Mongo (2.4.10) indexes, using collection.getIndexes(). I see options that aren't discussed in any doc I can find. Specifically, I see the options "safe" and "force". For example below:
{
"v" : 1,
"name" : "status_1",
"key" : {
"status" : NumberLong(1)
},
"ns" : "db.mycoll",
"force" : true,
"background" : true
},
What do "force" and "safe" mean?
The options you mention ("force" and "safe") are not valid index options for MongoDB 2.4.
They likely resulted from a developer accidentally ensuring an index including these as index options (perhaps having intended for those fields to be part of the index criteria?).
You can reproduce this outcome in the mongo shell:
> db.foo.ensureIndex({foo: true}, {force: true, safe: true})
{
"createdCollectionAutomatically" : true,
"numIndexesBefore" : 1,
"numIndexesAfter" : 2,
"ok" : 1
}
> db.foo.getIndexes()
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"name" : "_id_",
"ns" : "stack.foo"
},
{
"v" : 1,
"key" : {
"foo" : true
},
"name" : "foo_true",
"ns" : "stack.foo",
"force" : true,
"safe" : true
}
]
>
Unknown index options will be ignored (at least as at MongoDB 3.0), so while this is confusing the impact is currently benign. Unfortunately the only way to remove the invalid options would be dropping & rebuilding the affected index(es) as there is no API for changing an existing index.
It's possible that index option validation may be added in a future MongoDB release, but this should be noted as a compatibility change in the release notes. For example, MongoDB 2.6 has several index changes including better field name validation and enforcement of index key length.

Mongoose schema: 'unique' not being respected

I'm trying to use Mongoose with this schema
var RestoSchema = new Schema({
"qname" : {type: String, required: true, unique: true},
...
});
The problem is that this still permits new entries to the database to be created with an existing qname. From what i can see below the index has been created, but without any demonstrable impact when I use the .save method. What am I misunderstanding?
> db.restos.getIndexes()
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"ns" : "af.restos",
"name" : "_id_"
},
{
"v" : 1,
"key" : {
"qname" : 1
},
"ns" : "af.restos",
"name" : "qname_1",
"background" : true,
"safe" : null
}
]
The getIndexes output shows that the index on qname wasn't created as a unique index. Mongoose doesn't alter an existing index, so you'll have to manually drop the index and then restart your app so that Mongoose can re-create it as unique.
In the shell:
db.restos.dropIndex('qname_1')
ByronC's response here seems to have solved it for me. I even tried dropping the collection and recreating and it still didn't work until I used the node.js NPM plugin called "mongoose-unique-validator" which you can learn more about here.
That said, the weird thing is that my unique index worked up until a schema change that implemented the "uuid" plugin which I use now for setting the _id value. There may have been something else going on but it is working for me now so I'm moving on.