Meteor: Different collections, different databases

Question

My site will have two types of users: customers and admins. They all need accounts. And for accounts the built-in meteor accounts system makes use of the users collection. Are there any ways to separate these two types of users into separate collections (say, customers and admins) rather than have them all in that one single collection? I might also want to have these types of users in separate databases (on different servers): one database for customers and the other one for admins. So, how to tell Meteor which database to use for which collection?

It's an e-commerce type of site. Can anyone tell me why one single collection would be better to use for both customers and admins? What are the pros and cons of using one collection instead of the two when creating a web shop?

You could also use a usertype to seperate them and use a query to make sure you get one for each — Tarang, Apr 01 '13 at 07:31
Yes, of course. But I think it would be better to keep them separate in this case. — Bob Torrent, Apr 01 '13 at 07:50
As they are too different types, have very different roles in the site, and each of which will use different panels, I think separate collections for them make more sense. — Bob Torrent, Apr 01 '13 at 07:59
Not necessarily, Using 2 collections wouldn't make it any more secure than using the publish functions to ensure that non users,users and admins all see different sets of the collection. — Tarang, Apr 01 '13 at 08:13
If you really want it is possible but it needs edits on the accounts-base & accounts-password packages, is it only going to be password login? — Tarang, Apr 01 '13 at 08:22
I sure can try hacking the core but it is simply not what I am after. It's a pity if such things are not configurable. Isn't it a common use case? — Bob Torrent, Apr 01 '13 at 08:35
Hope someone from the Meteor team can come up and tell why there are no methods to do such separations. — Bob Torrent, Apr 01 '13 at 08:38
Maybe I can help with an answer is it going to be facebook-login or just password login, the more common design pattern is to use roles, if the design is for two completely different collections it might be better to use a seperate meteor app and make them communicate with each other using Meteor.connect — Tarang, Apr 01 '13 at 08:39
Just password login for starters. Meteor.connect might be what I need to look into. Thanks for pointing out. But still... can't one Meteor app work with more than one database? — Bob Torrent, Apr 01 '13 at 08:49
Like I said, one database for customers and the other one for admins. How to tell Meteor which database to use for which collection? — Bob Torrent, Apr 01 '13 at 08:52
I have checked out `Meteor.connect` but it doesn't seem possible to share the `users` collection with another Meteor app that already makes use of its own `users` collection. — Bob Torrent, Apr 01 '13 at 12:07
You can use a method to fetch users data from a different meteor instance using meteor.connect — Tarang, Apr 01 '13 at 12:09
And also `update` it like a normal collection? Can you show how to do it? — Bob Torrent, Apr 01 '13 at 12:12

score 0 · Answer 1 · answered Apr 01 '13 at 07:31

0

You might want to try the roles Roles package. https://github.com/alanning/meteor-roles

You won't need to separate the collections, just assign different roles for different users.

answered Apr 01 '13 at 07:31

Kristoffer K

2,053
18
23

Yes, as a workaround it'll do but is not what I am looking for. – Bob Torrent Apr 01 '13 at 07:52
Roles for admins - yes, but mixing admins with customers smells like a bad design. – Bob Torrent Apr 01 '13 at 08:02
Why would that be bad design? I personally thinks keeping several collections for different users smells like bad design. Oh, and Wordpress does it. http://codex.wordpress.org/Roles_and_Capabilities – Kristoffer K Apr 01 '13 at 08:13
It's not just different users but rather two different worlds, so I would like to deal with them as such. – Bob Torrent Apr 01 '13 at 08:30
I'm talking about an e-commerce type of site. Blogging soft like WordPress where a reader can eventually become an admin might do absolutely well with that database schema. But web shops are a different beast. A buyer will never ever become an admin because it's not like that same user type but with additional rights (i.e. can read a blog post and also edit it). – Bob Torrent Apr 01 '13 at 09:05
Doesn't mean they need different collections or databases. If you write secure code one collection should suffice. But of course you do it in which every way you want to, this is just my opinion. – Kristoffer K Apr 01 '13 at 09:47
I mentioned different databases sorely because of the way Meteor handles user authentication: one `users` collection Meteor is taught to work with. If it were possible to have the `users` split into two different collections in one database then I would go for it, of course. But as it cannot be done without loosing the whole lot of Meteor's internal functionality (which would make it useless) I cannot use just one same database. And it's not about security. It's just a design point of view, I've already said. – Bob Torrent Apr 01 '13 at 10:21

Tarang · Accepted Answer · 2013-04-01T12:39:13.803

0

Why not split your meteor into 2 instances, one for your client and one for your administration interface. Personally I would use roles but there isn't much wrong if this is you're preference:

Your admin meteor client js code

OtherMeteor = Meteor.connect("http://other_meteor_url")

//get user with username "admin"/connect to a custom method
OtherMeteor.call("getuser",{username:admin}, function(err,result) {
    console.log("result")
})

OR you could directly attach to a collection on another meteor instance

remote_meteor = Meteor.connect("http://other_meteor_url");
users2 = new Meteor.Collection("users", {manager: remote_meteor})

//wait for the subscription to finish first then use:
console.log(users2.find().fetch())
users2.up

Code in the other meteor that does custom functionality:

Server js:

Meteor.methods({
    'getuser':function(query) {
        return Meteor.users.find(query).fetch();
    },
    'updateuser':function(query,modifier) {
        return Meteor.users.update(query,modifier);
    }
})

edited Apr 01 '13 at 12:39

answered Apr 01 '13 at 12:26

Tarang

75,157
39
215
276

You can, if you see the second example i've attached directly to the users collection – Tarang Apr 01 '13 at 12:39
On one app: `Meteor.publish 'shared', -> Meteor.users.find({})`. On the other: `shared = new Meteor.Collection 'shared', {manager: conn}`, then `conn.subscribe 'shared'`. Then `console.log shared.find({}).count()` is 0. – Bob Torrent Apr 01 '13 at 12:42
are you waiting for the subscription to finish? – Tarang Apr 01 '13 at 12:44
Also is there a collection called 'shared'? its supposed to be users at Meteor.Collection 'shares' should be Meteor.Collection 'users' – Tarang Apr 01 '13 at 12:46
I can't create a collection by the name of `users` as it is already in use by Meteor's core. – Bob Torrent Apr 01 '13 at 12:47
Looks like it would conflict for the users collection then, you might be stuck having to use the methods to ferry messages in and out – Tarang Apr 01 '13 at 12:54
Oh, sorry, mate. My bad. Now it is working after renaming the name as you said. – Bob Torrent Apr 01 '13 at 12:55
I will accept your answer though it doesn't exactly answer my question. But I don't think I will be able find more help here. Thanks for telling me about `Meteor.connect`. And yeah - Meteor creators, your docs suck! :) – Bob Torrent Apr 01 '13 at 13:01
You shouldn't accept the answer as its not specifically an answer to this question, if others come around looking they wont find what they're looking for – Tarang Apr 01 '13 at 13:03
Unfortunately, `Meteor.connect` cannot be used for what I need because it can only be called on the client and servers can not yet connect to other servers. – Bob Torrent Apr 01 '13 at 22:37

Meteor: Different collections, different databases

2 Answers2

Linked