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.
Related
I want to use the collections as DBs!.. make a connection from nodejs where you can use a collection as a normal database.??
The purpose of this is that I'm going to create two totally different apps, with different collections and documents, but there are data that I need to relate between the two apps. And if the two apps are using the same database, it would be much easier for me.
Well.. MongoDB doesnt do that, what can you do is something like give a prefix name to your collections, "projectA_Users , projectB_Users" and to relate data use the $lookup Aggregate operator to get your relationship. I see something like that on FireBase that you can create a collection inside a document and use find, update, remove on it (here)
Is there a way to add a restriction when deleting collections that are referenced by id in other collections using mongodb or mongoose?
I need something like "on delete restrict" from sql to use on mongodb.
References from one collection to another are not explicit. So Mongo has no way to know that an ObjectId property in a document refers to the id of another document, nor in which collection. So I believe it's not possible to have such restrictions.
MongoDB doesn't support this feature, you can implement in your own application.
Keep a refcount field in your document to track referenced count.
db.coll.remove({refcount: 0})
I planned to create a document with an _id before inserting it into the DB.
I wanted to generate this _id using Meteor.uuid() (which theoretically always return a unique id) but I felt on this following git issue
Thanks, good catch. The reason that this wasn't documented is that
we'd eventually like to move away from string _ids to native binary
Mongo _ids. Since it's used in an example though, I think we should go
ahead and document it and cross that bridge later. I'll do this
It seems to be a difference between a string id and a binary mongo one. Back to my question, is there a good reason I should then avoid using my custom _id ?
When you create a Mongo.Collection you have the option to select the way Meteor handles creating _id for documents which do not have and _id already. You can read more about it here.
The key point to take away is if it does not already have an _id. You are free to use whatever custom _id field you want. At this point this is no longer a Meteor question, but a Mongo question. Read up on the pros and cons of manually setting the _id field in Mongo.
Back to your question, with respect to Meteor there is no reason to avoid creating your own _id fields. If the custom _id you want to use uniquely identify's that document, then you are good to go.
And don't worry about Meteor.uuid(). It's no longer documented, so I'd imagine it will eventually disappear.
MongoDB ObjectID are guaranteed unique by the algorithm, so are totally conflict-safe. You could have the same safeness only actually having somewhere a sort of incremental counter shared by all your application servers and persisted, so actually reimplementing what already on you db server.
From my POV you should choose between accepting a little risk and generating a random large ID, or using MongoDB to bring them to you in advance.
With the latter I mean you could implement your custom ID generation as an empty save on your collection, that you could later user within the actual document save: you'll pay the price of an additional database roundtrip but if your function involve moving files I'm sure it would be negligible.
My personal advice is the latter solution.
It is not recommended to use ElasticSearch as the only storage from some obvious reasons like security, transactions etc. So how it is usually used together with other database?
Say, I want to store some documents in MongoDB and be able to effectively search by some of their properties. What I'd do would be to store full document in Mongo as usual and then trigger insertion to ElasticSearch but I'd insert only searchable properties plus MongoDB ObjectID there. Then I can search using ElasticSearch and having ObjectID found, go to Mongo and fetch whole documents.
Is this correct usage of ElasticSearch? I don't want to duplicate whole data as I have them already in Mongo.
The best practice is for now to duplicate documents in ES.
The cool thing here is that when you search, you don't have to return to your database to fetch content as ES provide it in only one single call.
You have everything with ES Search Response to display results to your user.
My 2 cents.
You may like to use mongodb river take a look at this post
There are more issue then the size of the data you store or index, you might like to have MongoDB as a backup with "near real time" query for inserted data. and as a queue for the data to indexed (you may like to use mongodb as cluster with the relevant write concern suited for you application
What is the best way to store references to IDs with the node-mongodb-native driver?
I am currently storing an ID like 4e2675b04aa5520000000002 on its own. Should I instead be storing ObjectID('4e2675b04aa5520000000002')?
Thanks!
If your ID is actually a mongo ObjectId (meaning, the "4e2675b04aa5520000000002" is actually one) then it is much more efficient to store it as such rather than a string, both in terms of size and performance.
Note that there's actually a reference convention defined as well, details here : http://www.mongodb.org/display/DOCS/Database+References#DatabaseReferences-DBRef
Most drivers will allow you to automatically retrieve the referred documents without manually having to query for them. Since that's behaviour that can get in the way I think it's usually preferred to just store ObjectId("4e2675b04aa5520000000002") as the value as you suggest.
do you have to use your own IDs? mongodb creates them for you if you don't supply them (_id). if you have to set them manually, then use ObjectID and save them in _id.