Can I use String as an identifier type for a mongodb document?

I am using java / morphia to work with mongodb. By default, ObjectId is not very convenient to use from the Java level. I would like to make it a string type, preserving the process of generating keys with ObjectId, say _id = new ObjectId.toString() .

I want to know if there are any side effects making it this way? For example, will this affect database performance or cause keyword conflicts in any way? Will this affect the environment of the fragments ...

+7
source share
4 answers

You can use any type of value for the _id field (except arrays). If you decide not to use ObjectId, you need to somehow guarantee the uniqueness of the values ​​(ObjectId will be cast into a string). If you try to insert a duplicate key, an error will occur and you will have to deal with it.

I am not sure what effect it will have on the fragment cluster when you try to insert two documents with the same _id into different fragments. I suspect that it will allow you to insert, but it will bite you later. (I have to check it out).

However, you should not have a problem with _id = (new ObjectId).toString() .

+18
source

I really did the same because I was having a problem converting ObjectId to JSON.

Then I did something like

 @Id private String id; public String getId() { return id(); } public void setId(String id) { this.id = id; } 

And everything worked fine until I decided to update the previously inserted document, when I received the Id object, sent it to the page via JSON and received the same updated object also via JSON, and then used the save function from the data store instead of updating the previous data he inserted a new document instead of updating an existing one.

In the worst case, the new document had the same identifier as the previously inserted one, something I was thinking about was impossible.

In any case, I set the private object as ObjectID and just left the get set as a string, and then worked as expected, not sure what helps in your case to think about.

 @Id private ObjectId id; public String getId() { return id.toString(); } public void setId(String id) { this.id = new ObjectId(id); } 
+4
source

Yes, you can use the string as _id.

I would recommend it only if you have any value (in the document), which, of course, is a good unique key. I used this design in one collection, where there was a string geotag, of the form "xxxxyyyy"; this unique field for the document was supposed to be in the document, and I needed to create an index on it ... so why not use it as a key? (This eliminated one additional key-value pair and avoided the second index in the collection, since MondoDB naturally builds the index on “_id.” Given the size of the collection, both of them added some significant space savings.)

However, from the tone of your question (“ObjectIDs are not very convenient”), if the only reason you want to use a string is that you don’t want to worry about how to carefully manage the ObjectID. I would advise you to spend your time thinking about them. I am sure that this is not a problem ... as soon as you deal with them.

Otherwise: what are your options? Will you construct string ids every time you use MongoDB in the future?

+1
source

I would like to add that it is not always useful to use the automatically created BSON object identifier as a unique identifier if it is passed to the application: it can potentially be manipulated by the user. Object identifiers seem to be generated sequentially, so if you fail to implement the necessary authorization mechanisms, an attacker can simply increase the value that he has to access resources that he should not have access to.

Therefore, the use of UUIDs will provide a level of protection against unauthorized access. Of course, authorization (this user is allowed to access the requested resource) is required, but you should be aware of the ObjectID function mentioned above.

To get the best of both worlds, generate a UUID that matches your ObjectID length (12 or 24 characters) and use it to create your own _id of type ObjectID.

+1
source

All Articles