In MongoDB documentation, when I search for sort, it direct me to the cursor.sort() page. (btw the documentation doesn't specify what is returned out of this method.). So I used it in my meteor script Collection.find().sort('date':1), but got complained that find().sort is not a function. (I thought find() does returns a cursor, isn't it?)
So I did some further search, and found some tutorials tell me to use find({}, {sort: ...}).
So what is the difference between these two methods?
Using find({}, sort... Asks Mongo to do the sorting, and this is the most efficient way because the database server can optimise a sort if a field is indexed.
Meteor doesn't provide the full Mongo api, because mini Mongo in the browser does have all the features and they want to provide a consistent api in both client and server.
I haven't checked it but I think if you add a fetch () in between the find and the sort it will work because fetch will return an array which is sortable
In the Meteor framework, some things you need to do the Meteor way!
Just use Collection.find as specified in the Meteor Docs, and pass a Sort Specifier.
What is the difference between the two?
One has been wrapped by Meteor, and works inside the framework, the other one doesn't!
I don't believe you will see any performance difference between 'the Meteor api' from in the framework, or 'the standard MongoDB api' from (non meteor) nodejs.
Related
I am trying to use the aggregations feature in RestHeart which is described here: https://restheart.org/docs/aggregations/
I am using it to filter and group stuff in my collection based on a input variable, like this.
https://.../_aggrs/test-pipeline?avars={"country":"DE"}
As the documentation states querying the aggregation does not yield the result directly, but I have to query the newly created collection. I found out that it also works to just query the aggregation endpoint twice. But in any case I have to make two requests to get the result.
I am now worried about concurrent users. If two users are querying the aggregation at the same time (with different avars), one might get the result of the other.
I am wondering why this is not mentioned anywhere. It seems to me that everybody should have this problem when using variables (avars) in an aggregation.
How can I solve this? Might transactions be the solution? https://restheart.org/docs/transactions/
I cannot try it right now, because my mongoDB is refusing to start a transaction. But would it even work?
Are there any other solutions?
Best regards,
Tobi
I Want to query using part of id to get all the matched documents. So I tried “starts with” and "contains" which works find but is there any performance issue for large collection?
The best way to make this search optimum :
Add $text index on the fields you want to do search in. This is really important because internally it tokenize your string to that you could search for a part of it.
Use regex which is also quicker to do.
If you are using aggregate, read this mongodb official doc about aggregation optimization which might help you to implement this in efficient manner : https://docs.mongodb.com/manual/core/aggregation-pipeline-optimization/
Last but not the least, if you are not yet fully inclined towards mongodb and project is fresh, look out for elasticsearch service which is based on Lucene. Its extremely powerful doing these kinds of searches.
How can I determine what collection a Mongo document belongs to?
I'm using MeteorJS, but even if you don't use this, I'm pretty sure I have access to MongoDB's internal commands so please answer anyways.
Happy to close if this is a duplicate, but I didn't find anything close to this.
There isn't a real short command but to cycle through each collection and query for the field, or fields that uniquely identifies this document. Don't know MeteorJS but if you are looking for just a quick way to get the data to find out and not add a program function you can download RoboMongo. Think of it as SQL Management Studio for MongoDB. If you are looking for a program function to do this then I suggest you make it a jscript function you create inside MongoDB (similar to stored procedures) to do the work and return the results to you when done.
Are you querying the document now and wondering where it is coming from? If so, it should be in the code.
I am using MongoDB with Mongoose.
I was wondering, if it is bad practice to use MongoDB IDs outside of MongoDB context. Since a lot of my objects need an ID to be identified, I was wondering if I just could use the IDs MongoDB gives them anyway or is that bad practice?
Best regards
What I understand from your question is that if have a document from Mongodb that becomes an object in your application. To identify this object across the application, you want to use this _id so that changes to this object can be tracked easily. If this is the case, you should be using it happily. Because the ObjectId's of Mongodb are unique.
Infact, I do use this _id in my android application. example code here
studentUniqueId.setText(dataModelItem.get_Id());
where studentUniqueId is a hidden field in my android application.
Does MongoDB supports comparing two fields in same collection by using native operators (not $where and JavaScript)?
I already looked at similar questions and all answers used $where / JavaScript.
MongoDB documentation clearly states that:
JavaScript executes more slowly than the native operators listed on this page, but is very flexible.
My primary concern is speed and I would like to use indexes if possible. So is comparing two fields in MongoDB possible without using JavaScript?
This is not currently possible, but it will be possible through the new aggregation framework currently under development (2.1+). This aggregation framework is native and does not rely on relatively slow JavaScript execution paths.
For more details check http://www.mongodb.org/display/DOCS/Aggregation+Framework
and the progress at https://jira.mongodb.org/browse/SERVER-447
From reading the documentation you link it doesn't look like MongoDB has the ability to compare two document properties using only native operators.
Perhaps you can modify the documents themselves (and/or the code which saves the documents) to include a boolean property with value resulting from the comparison (ahead-of-time) and then simply query on that new property as needed. You could even index it for even better performance.