Using Mongo's random id's instead of Meteors?

core
1

I found a good article on it here:

The longer ID does seem like it would have have merit, and maybe using the default Mongo approach would make it easier to switch the back end stack if one needed to?

I’m curious what you guys think. I’m about to put something in production and am debating if it’s worth fixing this up

1 Like
2

As far as I know there is no advantage at all to use IDs generated by Mongo over Meteor’s. Also you will lose the optimistic UI for inserts since that relies on IDs being generated in the client.

1 Like
3

other than MongoID’s contain timestamp and are sortable by it - as long as I know

4

That’s a fair trade off. On that subject, how does one generate Meteor id’s these days? I tried using Random but it looks like it’s no longer available

5

@msavin

meteor add random

2 Likes
6

@shock @msavin the method described in that post does not product actual mongodb object id’s and they do not contain natural sort order or timestamp information.

they are random strings wrapped in an ObjectID() constructor.

7

Wait, when you instantiate a Mongo.Collection isn’t possible to set how id generation is done in the options param?

http://docs.meteor.com/#/full/mongo_collection

8

yep, that’s what the blog post is about

9

Yes but both of those are generated by Meteor, before the data hits the database. Maybe I’m overthinking the question.

1 Like
10

@sashko that’s right, this is already built in to meteor, given the generated id has no meaning. If you ever want to take a stab at this though, there’s this very old issue about the accounts system not supporting objectid at all

2 Likes
11

My data schema draws from MongoDb best practices where the user id is composed by base64 encoding MongoDb’s objectid. I’m having problems with is because meteor’s user accounts collection doesn’t support mongodb id generation (to me this seems like a non-trivial limitation). My user document has several nested fields and participates in several more one to many relationships with documents from other collections. From what I’ve read, my case seems like one where I should avoid the user accounts profile field. My question, should I customize the users collection or should I establish a separate userProfiles collection? For instance

Meteor User Accounts collection
user._id : ‘string’ // meteor generated id
…

User Profile collection
userProfile._id: ‘ObejectId(…)’ // mongodb generated id
userProfile.user_id: 'base64 (userProfile._id)'
userProfile.meteor_id: ‘Meteor.user()’ // fk reference to meteor accounts
…

Other related collections
…
user_id: ‘userProfile.user_id’ // fk reference.

Thanks in advance. Btw, I ask the question here because I was lead to this tread by following @awatson1978 post. I also read a remark by @sashko that it might be best to creat a separate collection to hold nested user profile data.

12

Could _id duplicate or not? If I install my app on 2 PCs

13

Could _id duplicate or not? If I install my app on 2 PCs

I think this is an important unanswered question.

This article by mongodb does a good job of going over how unique MongoIds can be.

Do we know anything about the uniqueness of the MongoIds generated by Meteor’s client?

14

MongoDB would reject the write if the _id is duplicate, which is even worse if you ask me.

I have heard of this happening… it’s probably rare but a very discomforting.