HNHacker News
TopNewBestAskShowJobs

lourd

6 karma · joined July 7, 2014

submissionscomments
lourd··on Meteor and Qt
My web development experience started with Rails, Postgres, and SQLite about 16 months ago and starting using Meteor about 10 months ago. In the handful of Rails apps I made, all of my interactions with the database were done through Active Record; I was an abstraction away from any SQL queries. I declared my relationships and got the data I wanted with simple `object.attribute` syntax.

In Mongo, I do the same thing but without an ORM. I declare objects and insert them. If I want relationships between collections I have to declare them myself, but that's just declaring some foreign key fields. I denormalize my data model in some places so I don't have to do that too often, though. And Meteor gives me this interface on the client as well — that along with data reactivity and a pub-sub architecture is a lot of fun to build with.

I've seen a lot of hate for Mongo and I'm not sure why. SQL and NoSQL databases are both capable of doing the same thing, they just have different use cases that they excel at. This video (https://www.youtube.com/watch?v=rRoy6I4gKWU) is the clearest talk I've seen explaining their differences, and having watched that I'm unsure of why people are so rabidly for or against each type of database.

lourd··on Meteor and Qt
This is more of a data modeling and permissions question, more dependent on the database choice rather than the framework I'd say. Since Meteor only supports Mongo right now, I'll use Mongo terms (collections & documents)

Meteor gives you an accounts collection so you don't have to declare it yourself. But we do need to declare the Groups Collection

    Groups = new Mongo.Collection('groups');
Let's assume we want Users and Groups to have a many to many relation, so each User doc has an attribute `groups`. `groups` is an array of which each element is the unique id of a Group document. Similarly, Group documents have an attribute `members`, an array of which each element is a User document unique id.

There is a third Collection needed, documents.

    Documents = new Mongo.Collection('documents');
Each document in the Documents Collection has an `owner` field that is the unique id of a Group document.

To handle the security for inserting or updating the Documents Collection, you need to set 2 allow rules on the Collection to check if the document.owner is in the user.groups array.

    Documents.allow({
      insert: function(userId, doc) {
        // doc's owner must be one of logged in user's groups
        return Meteor.user().groups.indexOf(doc.owner) > -1;
      },
      update: function(userId, doc, field, modifier) {
        return Meteor.user().groups.indexOf(doc.owner) > -1;
      }
    }
As for reading the document, you do that when declaring your Publications. Easiest would be to publish all of them, but you could also pass in a groupId or array of groupIds if you wanted to have some restrictions.

    Meteor.publish("documents", function() {
      return Documents.find();
    };
lourd··on Meteor hits 1.0
Quite the opposite. Those who can choose anything choose Meteor.