Is there a way I can update every field in a MongoDB document without just listing all the fields, which might change later? Something like this?
db.update(
{foo:"bar"},
{$unset: {{}:""}}
)
Consider the cogency of an operation like this. How are you updating all of the fields meaningfully without considering their specific types or values? It looks like you are trying to unset the fields or set them to a default, null-like value. What does it mean to unset every field in a document? Isn't it really just removing the document? Are you excluding _id and other immutable fields (shard key!) somehow? What is the default value for the possible field types? What is the default value for a field that can be an integer or an array of integers in a data model? It's also dangerous to try to do something like this, especially with flexible schemas. Needing to do the above operation indicates a good chance that you need to rethink your data model.
Related
I am new in MongoDB. I have a collection in MongoDB. I would like to shift a column in collection of MongoDB. I would like to place image as last column and email as before the last column. How can I do that ?
I agree with others who mentioned that the order of keys in a document should not matter.
But if you still want to learn more about it, it is mentioned in the docs that:
MongoDB preserves the order of the document fields following write
operations...
Considering that, you can actually alter the order of fields by removing and re-inserting them (using $unset and $set) or by using the $rename operator which does exactly that. But you will need to do a couple of operations: First rename the image field to something else, than re-rename it back to image like so:
db.test.updateMany({}, {$rename: {image: 'image_'}})
db.test.updateMany({}, {$rename: {image_: 'image'}})
Since this will actually re-insert the image field, it will cause that field to be last in the document.
I have some JSON entries in MongoDB but I plan to add new attributes into all my entries, like how you would create a new column and appoint a default value in RDBMS.
Is there any way to do it with MongoDB?
If you mean that every new document needs to be guaranteed to have the new fields, I'm afraid that it's not possible in MongoDB itself, because it is schemaless. I am however not familiar with mongoose, and there can be a solution using it.
If, like your title suggests, you just want to add the new fields to all existing documents you can do it with an update with empty filter like this:
db.collection.updateMany({}, {"newfield1":"val1","newfield2":"val2"})
I have a class/object that have a guid and i want to use that field as the _id object when it is saved to Mongodb. Is it possible to use other value instead of the ObjectId?
Is there any performance consideration when doing bulk insert when there is an _id field? Is _id an index? If i set the _id to different field, would it slow down the bulk insert? I'm inserting about 10 million records.
1) Yes you can use that field as the id. There is no mention of what API (if any) you are using for inserting the documents. So if you would do the insertion at the command line, the command would be:
db.collection.insert({_id : <BSONString_version_of_your_guid_value>, field1 : value1, ...});
It doesn't have to be BsonString. Change it to whatever Bson value is closest matching to your guid's original type (except the array type. Arrays aren't allowed as the value of _id field).
2) As far as i know, there IS effect on performance when db.collection.insert when you provide your own ids, especially in bulk, BUT if the id's are sorted etc., there shouldn't be a performance loss. The reason, i am quoting:
The structure of index is a B-tree. ObjectIds have an excellent
insertion order as far as the index tree is concerned: they are always
increasing, meaning they are always inserted at the right edge of
B-tree. This, in turn, means that MongoDB only has to keep the right
edge of the B-Tree in memory.
Conversely, a random value in the _id field means that _ids will be
inserted all over the tree. Then the machine must move a page of the
index into memory, update a tiny piece of it, then probably ignore it
until it slides out of memory again. This is less efficient.
:from the book `50 Tips and Tricks for MongoDB Developers`
The tip's title says - "Override _id when you have your own simple, unique id." Clearly it is better to use your id if you have one and you don't need the properties of an ObjectId. And it is best if your ids are increasing for the reason stated above.
3) There is a default index on _id field by MongoDB.
So...
Yes. It is possible to use other types than ObjectId, including GUID that will be saved as BinData.
Yes, there are considerations. It's better if your _id is always increasing (like a growing number, or ObjectId) otherwise the index needs to rebuild itself more often. If you plan on using sharding, the _id should also be hashed evenly.
_id indeed has an index automatically.
It depends on the type you choose. See section 2.
Conclusion: It's better to keep using ObjectId unless you have a good reason not to.
In MongoDb ObjectId is a 12-byte BSON type.
Is there any way to reduce the size of objectID?
No. It's a BSON data type. It's like asking a 32-bit integer to shrink itself.
Every object must have _id property, but you are not restricted to ObjectId.
Every document in a MongoDB collection needs to have a unique _id but the value does not have to be an ObjectId. Therefore, if you are looking to reduce the size of documents in your collection you have two choices:
Pick one of the unique properties of your documents and use it as the _id field. For example, if you have an accounts collection where the account ID--provided externally--is part of your data model, you could store the account ID in the _id field.
Manage primary keys for the collection yourself. Many drivers support custom primary key factories. As #assylias suggests, going with an int will give you good space savings but, still, you will use more space than if you can use one of the fields in your model as the _id.
BTW, the value of an _id field can be composite: you can use an Object/hash/map/dictionary. See, for example, this SO question.
If you are using some type of object/model framework on top of Mongo, I'd be careful with (1). Some frameworks have a hard time with developers overriding id generation. For example, I've had bad experience with Mongoid in Ruby. In that case, (2) may be the safer way to go as the generation happens at the driver layer.
I have collections with huge amount of Documents on which I need to do custom search with various different queries.
Each Document have boolean property. Let's call it "isInTop".
I need to show Documents which have this property first in all queries.
Yes. I can easy do sort in this field like:
.sort( { isInTop: -1 } );
And create proper index with field "isInTop" as last field in it. But this will be work slowly, as indexes in mongo works best with unique fields.
So is there is solution to show Documents with field "isInTop" on top of each query?
I see two solutions here.
First: set Documents wich need to be in top the _id from "future". As you know, ObjectId contains timestamp. So I can create ObjectId with timestamp from future and use natural order
Second: create separate collection for Ducuments wich need to be in top. And do queries in it first.
Is there is any other solutions for this problem? Which will work fater?
UPDATE
I have done this issue with sorting on custom field which represent rank.
Using the _id field trick you mention has the problem that at some point in time you will reach the special time, and you can't change the _id field (without inserting a new document and removing the old one).
Creating a special collection which just holds the ones you care about is probably the best option. It gives you the ability to logically (and to some extent, physically) separate the documents.
Newly introduced in mongodb there is also support for a "sparse" index which may fulfill your needs as well. You could only set the "isInTop" field when you want it to be special, and then create a sparse index on it which would not have the problems you would normally have with a single indexed boolean field (in btrees).