Node supports DBRef, does mongo?

hello - being a total newbie, i was under the impression that meteor is built on top of nodeJS. It appears that nodeJS supports DBRef.

Will meteor support DBRef anytime soon, since nodeJS appears to support it?

i have yet to even install node or try it (this shows what a total newbie i am) but i did watch this video series and found it very educational.

We are eager to rewrite several applications in meteor, but our specifications require many foreign-key relationships (referential integrity) that hopefully mongoDB DBRef will provide.

I doubt DBRef’s will be supported anytime soon since the Meteor team is focused on several others areas relating to the 1.3 release (and Galaxy of course). Are you sure you need to use DBRef’s though? If you’re concerned with handling foreign-key relationships, have you looked into some of the other approaches the community has come up with? Try Can a “Foreign Key” be implemented in Mongo? as a starting point.

thank you hwillson -

I incorrectly hoped that since nodeJS supported DBRef, meteor would also support it.

my two applications have many situations where a child record has more than one parent. this structure seems a little awkward without the DBRef.

my next question for the mongoDB community is how enforced the DBRef relationship is, if at all.

No problem at all - but take my answer with a large grain of salt; I’m purely speculating. @sashko (Meteor development group core member and official MDG forum representative) might be able to give you a more definitive answer regarding Mongo DBRef support in Meteor.

(Okay, I made that part about him being the official MDG forum rep up, but he wins that title in my book! :slight_smile: )

This official documentation: says “Unless you have a compelling reason to use DBRefs, use manual references instead.”

Meteor supports manual references just fine. In any case, you would only use such a thing when publishing data - most of the queries for actually displaying data would be made on the client anyway. Read more about relational data in the preview of the Meteor Guide:

And that’s why he’s forum king - thanks @sashko!

Thank you to the forum king and forum jester.

As impressed as i am with meteor, it may be a “tough sell” to abandon the SQL db for mongoDB, without better support for multiple parent relationships.

I suppose i will ask on a mongoDB forum in the days-of-old (way back in 2014 when Trump was just another blowhard billionaire) how the common “many-2-many” relationship is represented, given that in the SQL world, it resolves itself into dual “one-2-many” relationships, placing something of a dummy child table containing just the parent key values, in-between the two tables.

We may be forced to choose Laravel over Meteor, for now anyways.

The easiest way to represent a many-to-many relationship is to use an array. For example, if you have a tags collection, this is what a post could look like:

post = {
  title: "xxx",
  content: "xxx",
  tags: [ "tag1ID", "tag2ID", etc ]

Now you can do something that would be a hassle in SQL - find all of the posts with a certain tag - like this:

Posts.find({ tags: tagID });

Note that the query automatically traverses arrays.

I actually think in a lot of ways Mongo’s data modeling can be more intuitive, since in many cases you don’t need to have many extra tables just for relationships.

Anyway, we’re working on adding support for other databases soon.


thank you very much Sashko -

soon as in “just shut up and be patient” soon? :wink:

interesting idea on using an array. i have to wonder how you would differentiate between which ID is associated with each parent, and thats where i [possibly incorrectly] assumed that DBRef might have held the answer.

also, there does not appear to be any real solid way to enforce the embedded-key relationship with mongoDB. please dont get me wrong here, mongoDB looks really wonderful and i look forward to using it.

Yeah, there isn’t a good way to enforce the relationship at the database level in this case. Interestingly, if you’re operating on a high scale and need to shard to multiple SQL databases, you can’t enforce it there either, but that’s not necessarily an excuse.