ixdi
October 16, 2019, 10:13am
1
Hi,
Any one has been successfull using user._id as an ObjectID instead of a string?
Object is the default mongo type but Meteor Accounts continues on using String.
We have tried the onCreateUser function but then the user is not created.
Accounts.onCreateUser(function(options, user) {
user._id = new Mongo.ObjectID();
return user;
});
Thanks in advance
cereal
October 16, 2019, 9:01pm
2
I believe the official stance is “get stuffed”.
opened 05:43PM - 11 Feb 14 UTC
closed 01:33AM - 13 Feb 14 UTC
**_2 Upvotes**_ Hi Core Dev Team!
A couple of us are getting the following erro… r when trying to connect Meteor apps to pre-existing Mongo databases that have legacy accounts with ObjectIds in the users._id fields.
#### setUserId must be called on string or null, not object
```
Exception while invoking method 'login' Error: setUserId must be called on string or null, not object
```
The problem was originally reported by Serkan, when he was trying the following code:
``` js
Accounts.onCreateUser(function(options,user) {
check(options, Object);
check(user, Object);
// options.profile.email = user.services.facebook.email;
// options.profile.facebookId = user.services.facebook.id;
// user.profile = options.profile;
// options._id = new Meteor.Collection.ObjectID(user._id); /* this one complains about _id being too short, naturally... */
options._id = new Meteor.Collection.ObjectID(); /* creates a new random ObjectID */
user._id = options._id;
return user;
});
```
#### {idGeneration : 'MONGO'}
I tried using another approach, by specifying `{idGeneration : 'MONGO'}` on the Accounts collection, like so.
``` js
Accounts = new Meteor.Collection("users", {idGeneration : 'MONGO'});
```
Predictably, this gave the following error, basically saying that the collection was already defined:
``` js
W20140211-12:28:05.698(-5)? (STDERR) Error: A method named '/users/insert' is already defined
W20140211-12:28:05.699(-5)? (STDERR) at packages/livedata/livedata_server.js:1210
W20140211-12:28:05.699(-5)? (STDERR) at Function._.each._.forEach (packages/underscore/underscore.js:87)
W20140211-12:28:05.699(-5)? (STDERR) at _.extend.methods (packages/livedata/livedata_server.js:1208)
W20140211-12:28:05.700(-5)? (STDERR) at Meteor.Collection._defineMutationMethods (packages/mongo-livedata/collection.js:673)
W20140211-12:28:05.700(-5)? (STDERR) at new Meteor.Collection (packages/mongo-livedata/collection.js:176)
W20140211-12:28:05.700(-5)? (STDERR) at app/accounts-objectid.js:1:47
W20140211-12:28:05.700(-5)? (STDERR) at app/accounts-objectid.js:112:3
W20140211-12:28:05.701(-5)? (STDERR) at /Users/abigailwatson/Code/ThinAire/accounts-objectid/.meteor/local/build/programs/server/boot.js:155:10
W20140211-12:28:05.701(-5)? (STDERR) at Array.forEach (native)
W20140211-12:28:05.701(-5)? (STDERR) at Function._.each._.forEach (/Users/abigailwatson/.meteor/tools/09b63f1ed5/lib/node_modules/underscore/underscore.js:79:11)
```
#### Bug Replication
The bug has been isolated in it's own repository, and can be viewed online, using the following links:
https://github.com/awatson1978/accounts-objectid
http://accounts-objectid.meteor.com/
#### Impact
This bug is preventing some of us from deploying Meteor applications in environments that already have production Mongo databases. In particular, it prevents deploying Meteor applications with user databases where the Users collection has to be accessed by external applications (i.e. Express apps), and where the Users._id field is already defined as an ObjectId.
Should be able to overwrite the default behaviour by using a local version of accounts-base
.
To do this, download the /packages/accounts-base
folder from Meteor’s github and place it in your /packages/
directory.
Then you can edit accounts_common.js
line 23-26 to set the id generation to Mongo with the option idGeneration : 'MONGO'
There’s likely to be a whole lot of errors in places that assume userIds are strings and you’ll need to go around fixing them