meteor-community-packages / meteor-collection2 Goto Github PK

matb33/meteor-collection-hooks provides its API via adding two objects (before and after) to Meteor.Collection. The problem is that I can't access it on the collection2. It would be nice to do one of these things, in order of difficulty:

1. Provide/Document access to the Meteor.Collection.
2. Alias before and after to the Meteor.Collection.
3. Provide our own server-side hook system.

When I call collection2's overridden version of collection's insert it's inserting a copy of the object into client side collection without the autoValue calculated. Once the insert runs on the server, where autoValues are calculated, the client side collection is patched with the autoValue from the server as expected. I think it makes more sense to run it in both places so as to avoid a delay that is visible to the user. Thoughts @aldeed?

I've noticed some strange behaviors with Upserts and Collection2. I'd like to give some background on the issue I'm seeing and see if there might be a better way for me to accomplish it. I'm writing Yet Another Basic Chat project to try mind-bending myself into Meteor's way of thinking. In the process I've got Channels and I want to track who is a "visitor" to the channel. My first approach was maintaining an array inside of the Channel document to track users in that channel but I ran into problems (maybe I'll take another look at that another time). I ran away from that approach and I'm now working on a separate collection, Visitors.

Visitors maintains the following properties for now:

user [String]
channel [String]
active [Boolean], autoValue: -> true if not @.isSet
lastSeen [Date], autoValue: -> new Date
firstSeen [Date], autoValue: -> new Date if @.isInsert

I established a MongoDB unique index on user and channel so that there can only be one instance of a Visitor for each user/channel combination. My Collection2 configuration makes use of autoValue for the lastSeen and firstSeen Dates so that I can track those dates effortlessly. (autoValue, for what it's worth, is one of the most incredibly useful features Collection2 adds to Meteor. It's the bee's knees. I cannot say any more explicitly that core Meteor Collections could probably benefit greatly by integrating Collection2. Kudos.) Anyway, getting back to the point... On the server, in the Channel publisher I would like to go ahead and mark a user as a Visitor when they subscribe to a particular channel, like so:

if @.userId
    Channels.update { _id: id }, { $set: { lastVisited: new Date } }, { modifier: true }
    Visitors.upsert { user: @.userId, channel: id }, { }

This was firing off errors within MongoDB because I was attempting to insert a collection that violated the unique constraints. When I executed the same code against the standard Collection (Visitors._collection.upsert) it was OK. When I logged the value of the "args" that Collection2 was passing in to Visitors.upsert I can see it's passing the following data structure:

{
  "args": [
    {
      "user": "TMKNqdWcgS9zavoxA",
      "channel": "RzAW6EHT5Lsar9jFA",
      "active": "true",
      "lastSeen": "Mon Dec 23 2013 11:25:04 GMT-0600 (CST)"
    },
    {
      "$set": {
        "user": "TMKNqdWcgS9zavoxA",
        "channel": "RzAW6EHT5Lsar9jFA",
        "active": "true",
        "lastSeen": "Mon Dec 23 2013 11:25:04 GMT-0600 (CST)"
      }
    }
  ]
}

It would appear to me that the Collection is receiving the autoValue fields as selector fields which means the _insertOrUpdate check will fail to check for existence on the two fields I'd be interested in preventing collisions on. That is, at least, how I'm reading into the issue.

I noticed that if you have this as the collection 2 definition:

collection = new Meteor.Collection2("ognoCart", {
    'schema' : {
        'product' : {
            'type' : String,
            'label' : "Product _id reference"
        },
        'owner' : {
            'type' : String,
            'label' : "Owner _id reference"
        }
    }
});

Then you get a true in a lot of (to me) weird cases:

collection.insert({ 'product' : 'someId', 'owner'  : 'someId', 'alsoThis' : 'shouldnt work' }); // works
collection.insert({ 'product' : false, 'owner'  : true }); // works
collection.insert({ 'product' : 123, 'owner'  : 321 }); // works

Consider this:

Customers = new Meteor.Collection2("customers", {
    schema: {
        sales: {
            type: Number,
            label: "Total Sales",       
            allowObserve: true,
            autoValue: function() {
                var salesTotal = 0;
                Invoices.find({_id:this.id}).map(function(doc) {
                  salesTotal += doc.total;
                });
                return salesTotal;
            }
        }
    }
});

So I'm proposing an allowObserve property which would allow autoValue to update any time its calculation changes... observing the collections it's querying against.

Also It would be helpful to have an id property for this on autoValue.. unless I'm missing something.

Has there been any thought on this so far and what do you think?

When using Collection2, insert/update/remove rules for the collection don't seem to be applied. For example,

S = new Meteor.Collection2( "people", { schema: { name: { type: String } } });
S.allow({ insert: function() { return false } });
S.insert({name: 'john doe'})

The insert succeeds even though it shouldn't.

With virtualfields included, the fields with autoValue do not make into the database on an insert. If I remove the virtualFields, the autoValue fields are fine. Sample code:

Businesses = new Meteor.Collection2('businesses', {
  schema: {
    businessName: {
      type: String,
      label: "Business name",
      max: 50
    },
    owner: {
      type: String,
      label: "Owner name",
      max: 50,
      optional: true
    },

// autoValue fields:

    createdAt: {
      type: Date,
      autoValue: function() {
        if (this.isInsert) {
          return new Date();
        }
      },
      denyUpdate: true
    },
    createdBy: {
      type: String,
      autoValue: function() {
        if (this.isInsert) {
          return Meteor.userId();
        }
      },
      denyUpdate: true
    },
    updatedAt: {
      type: Date,
      autoValue: function() {
        if (this.isUpdate) {
          return new Date();
        }
      },
      denyInsert: true,
      optional: true
    },
    // Soft delete
    deletedAt: {
      type: Date,
      optional: true
    }
  },

// Virtual field code, e.g.

  virtualFields: {
    neighborhood: function(biz) {
      return "some hood";
    }
  }
});

is ie8 working with collections 2? Or i did something wrong?

I am having errors only in ie8.

SCRIPT1028: Expected identifier, string or number 
    collection2.js, line 28 character 9
SCRIPT1028: Expected identifier, string or number 
    autoform-common.js, line 12 character 9
SCRIPT5009: 'AutoForm' is undefined 
    autoform-client.js, line 1 character 14
SCRIPT445: Object doesn't support this action 
    sites.coffee.js, line 1 character 14
SCRIPT5009: 'Sites' is undefined 
    sites_list.coffee.js, line 26 character 5

Also, using autoform and smart-collections by arunoda.

Collection2 supports passing in an existing SmartCollection, but it might be nice to support a smart: true option in the constructor as well, which would create a new SmartCollection instead of Collection.

It might be nice to have a serverOnly schema option. Setting this to true would allow the key to be present only when the insert or update operation was initiated on the server. Note that it's not about where the validation is happening but rather where the operation initiated, meaning that the check would happen in the deny function on the server and on the client, but not in _insertOrUpdate on the server.

I've been loading some fixture data, where I want some values to be empty when created, but to be validated in all future updates. I was using the collection._collection.insert approach. This is gone now? Is there (or should there be) a parameter that can be passed to skip validation?

I tried this in coffeescript client side:

@OfflineProducts = new Offline.Collection "products"
@Products = new Meteor.Collection2 @OfflineProducts,
    smart:true
    schema:
        name:
            type:String

Server side I just did this

@Products = new Meteor.Collection2 "products",
    smart:true
    schema:
        name:
            type:String

There is a security/data integrity issue with the current implementation. Both client and server just check the doc against the schema and then call the normal collection insert/update/remove. This means that one could insert into the wrapped collection1 directly on the client (c2._collection.insert({})) and the insert would happen on the server without validation.

To fix this I will add the following to the end of the constructor function:

self._collection.deny({
  insert: function (userId, doc) {
    self._simpleSchema.validate(doc);
    return !self._simpleSchema.valid();
  },
  update: function (userId, doc, fields, modifier) {
    self._simpleSchema.validate(modifier);
    return !self._simpleSchema.valid();
  }
});

Add some validation checks for mongo operators that can't be done by SimpleSchema. See Meteor-Community-Packages/meteor-simple-schema#9.

• $rename (make sure existing values for the renamed key validate for the new key name)
• $inc (check min/max and allowed values)
• $addToSet (check maxCount)
• $push (check maxCount)
• $pull (check minCount)
• $pullAll (check minCount)
• $pop (check minCount)

Hi, I am experiencing a - from my point of view - strange behavior just having the following piece of code as a meteor project:

Books = new Meteor.Collection("books", {
  schema: new SimpleSchema({
    bool1: {
      type: Boolean,
      defaultValue: false
    }
  })
});

Now some commands within my Chromium 33 console:

Books.insert({bool1: false})
"HsCLp3o7y7KMbbHyN"
Books.findOne("HsCLp3o7y7KMbbHyN").bool1
false
Books.update("HsCLp3o7y7KMbbHyN", {$set: {bool1: true}})
undefined
Books.findOne("HsCLp3o7y7KMbbHyN").bool1
false

Shouldn't it be true in the very last line? I just installed all affected packages recently with mrt, so they should be up to date, just the default packages + simple-schema + collection2. Thanks for taking a look at it.

https://github.com/matb33/meteor-collection-hooks/blob/master/insert.js#L34

Collection hooks is expecting a function at args[1] but after collection2 0.3.0 upgrade args[1] is the validation context & the expected function is pushed to args[2].

I am defining models for each of my collection documents following the Animal example pattern in the meteor documentation for collection transforms.

Document inserts fail (with a simple 'access denied', and an empty ctx.invalidKeys() when coming from the client unless I add the method names I define by the transformed object as optional Function schema (makeNoise in the example below). My server side inserts work fine without them.

See example:

// An Animal class that takes a document in its constructor
Animal = function (doc) {
  _.extend(this, doc);
};
_.extend(Animal.prototype, {
  makeNoise: function () {
    console.log(this.sound);
  }
});

// Define a Collection that uses Animal as its document
Animals2 = new Meteor.Collection2("Animals2", {
  transform: function (doc) { return new Animal(doc); },
  schema: {
    name: { type: String },
    sound: { type: String },

    // XXX without this, inserting fails
    makeNoise: { type: Function, optional: true }
  }
});

Animals2.allow({                // even though we have the insecure package, this is necessary with Collection2(?)
  insert: function() {
    return true;
  }
});

if (Meteor.isClient) {
  Meteor.startup(function() {
    // Create an Animal and call its makeNoise method
    Animals2.insert({name: "raptor", sound: "roar"});
    Animals2.findOne({name: "raptor"}).makeNoise(); // prints "roar"
  });
}

I think this should work without adding cruft to the schema like I have above. Is this pattern supported with collection2?

Hi, I upgraded from 0.3.3 to the latest and autoValue stopped working, did something change in the way we're supposed to use it?

Thank you for your time!

Issue Initially posted in the autoform repository Meteor-Community-Packages/meteor-autoform#12, I've realized that Collection2 is the right place for this use case.

I've defined a required createdAt field of type: Date in the schema of one Meteor.Collection2 which I'd like to populate just before inserting. To be trustable this field has to be added (or at least validated) on the server.

One solution is to create a myCollection2 that extends Meteor.Collection2, then overwrite the insert method to create the createdAt field before calling super. In coffeescript:

class myCollection2 extends Meteor.Collection2
    insert: (doc, args...) ->
        doc.createdAt = new Date 
        super(doc, args...)

Posts = new myCollection2 'posts',
    schema:
        title:
            type: String
        content:
            type: String
        createdAt:
            type: Date
            # Off topic, but I'd like to define a "immutable",
            # or "not update-able" constraint

if Meteor.isClient
    Posts.insert
        title: "Hello world"
        content: "This is a test"

One other solution might be to add some beforeInsert, beforeUpdate and beforeDelete hooks that take the doc/query and modify it before the real database operation is done.

Moreover I wonder if you would like to have some rails convention over configuration strategy. In other words, if a field called createdAt or updateAt of type Date is present in the schema, fill it automatically without any other code.

The following is a schema design that incorporates a common base schema. (autovalues etc may not make sense, I just used them to see if features are interchangeable between collection2 and simple-schema)

/********************************
Base Collection Schema
********************************/
CoolProject.Collections.BaseSchema = new SimpleSchema({
  active: {
    type: Boolean
  },
  createdAt: {
    type: Date,
    min: new Date(),
    autoValue: function() {
      if (this.isInsert) {
        return new Date;
      } else if (this.isUpsert) {
        return {$setOnInsert: new Date};
      } else {
        this.unset();
      }
    },
    denyUpdate: true
  },
  updatedAt: {
    type: Date,
    min: new Date(),
    autoValue: function() {
      if (this.isUpdate) {
        return new Date();
      }
    },
    denyInsert: true,
    optional: true
  }
});

/********************************
Tag Collection Schema
********************************/
CoolProject.Collections.TagsSchema = new SimpleSchema([
  CoolProject.Collections.BaseSchema,
  {
    title: {
      type: String,
      label: 'Title',
      min: 5,
      max: 10
    },
    slug: {
      type: String,
      label: 'Slug',
      autoValue: function() {
        var title = this.field("title");
        if (title.isSet) {
          return URLify2(title.value);
        } else {
          this.unset();
        }
      }
    }
  }
]);

/********************************
The Actual Collection
********************************/
CoolProject.Collections.Tags = new Meteor.Collection('tags', {
  schema: CoolProject.Collections.TagsSchema,
  virtualFields: {
    virtualTest: function(tag) {
      return tag.title + ' // ' + tag.slug;
    }
  }});

Then on the browser console, I test the code by inserting some values using:

/********************************
Browser Console
********************************/
CoolProject.Collections.Tags.insert(
  {/*  WRITE SOME DOC HERE */},
  function(err,res) {
    if (err) return CoolProject.Collections.Tags.simpleSchema().namedContext().invalidKeys();   
  }
);

If the document is valid, it passes successfully through and I receive back the inserted document id. The autovalue, and nesting seems to be working. ( Except that the virtual field does not work, but it is already reported on another issue #47 )

THE PROBLEM:

If the doc is invalid (e.g. missing active or too short a title) then all I receive on the console output returns undefined whereas an array of error objects should have returned. This is reproducible on both 0.2.17 and 0.3.0

All the collection1 methods for update/insert/remove include the userId. This should also be available in the autoValue method of the schema.

Given the following collection as an example:

Assemblies = new Meteor.Collection2("assemblies", {
    schema: {
        name: {
            type: String,
            label: "Name",
            max: 200
        },
        customer: { 
            type: String,
            label: "Customer",      
            optional: true
        },
        coolField: {    
            type: String,
            label: "Cool Field",        
            optional: true,
            autoValue: function() {
                console.log(this.field("name").value);
                return "NEWVALUE";
            }
        }
    }
});

From the client console I do
Assemblies.insert({name: "Name1", customer:"Customer1"});
All normal.. this.field("name").value returns "Name1" (from the autoValue function)
Then I do Assemblies.update('DRCeTWGnMSMfZ4q4s', {$set: {name: "Name2"}});
All normal.. this.field("name").value returns "Name2"
Then I do Assemblies.update('DRCeTWGnMSMfZ4q4s', {$set: {customer: "Customer2"}});
Not Normal.. this.field("name").value returns undefined
Even if I do Assemblies.update('DRCeTWGnMSMfZ4q4s', {$set: {name: "Name3"}}); after that I can never get it to return the name field.. It's broken forever.

Not sure if this is unique to my setup or if you can reproduce this.. I cannot figure out what it is that's causing this.

I found an interesting issue today when exploring the use of $addToSet in conjunction with a Collection2 schema. I'll outline what I've done and what I've found.

First, a Collection:

@TeamMembers = new SimpleSchema
    memberId: 
        type: String
    accessLevel:
        type: String
        allowedValues: [ 'admin', 'developer', 'watcher' ]
    addedOn:
        type: Date
        autoValue: ->
            if @.isInsert
                new Date

@Teams = new Meteor.Collection2 'teams',
    schema:
        name:
            type: String
            unique: true
        members:
            type: [@TeamMembers]
            optional: true
        createdAt:
            type: Date
            autoValue: ->
                if @.isInsert
                    return new Date
            denyUpdate: true
        updatedAt:
            type: Date
            autoValue: ->
                new Date

Of importance here: createdAt is an autoValue for creation date, and it has the denyUpdate property set to true. Members is an array of an object of type TeamMembers. Awesome.

Now on the server I'm going to insert a team and add a team member to it. Maybe kind of like so (boy I hope I'm doing this right):

teamMember = 
    memberId:  userId
    accessLevel:  'admin'
    addedOn:  new Date

Teams.update { _id: team._id }, { $addToSet: { members: teamMember } }

This fails SimpleSchema validation. Upon stepping through in node-inspector I found that it was failing on the createdAt key. "That's weird, I didn't even supply a createdAt value..."

Anyway, in this function:

self._simpleSchema.validator(function(key, val, def, op)

key = createdAt
val = undefined
def = denyUpdate, autoValue, label, type
op = $addToSet

So the issue appears to be in this block:

    if (def.denyUpdate && op !== null) {                                                                       
      // This is an insert of a defined value into a field where denyUpdate=true                               
      if (op === "$set" && val !== void 0) {                                                                   
        return "updateNotAllowed";                                                                             
      } else if (op !== "$set") {                                                                              
        return "updateNotAllowed";     // This is getting hit!                                                                        
      }                                                                                                        
    }                 

My assumption here is that the there either needs to be some logic specifically for $addToSet so that it doesn't evaluate the parent object's keys, or there needs to be a check to see if the keyValue is undefined so that SimpleSchema will ignore it. When I removed the denyUpdate field the update went A-OK.

It may also be worth noting here that I have the updatedAt field which generated an additional $set. This is totally intended in this case.

Hello,
Congratulations for your awsome packages,

I may encounter some kind of bug.

i have schema that includes two other schemas, when inserting a new record, the inserted record loses value of one subschema (informations) and the other one (price) is stored

source : https://github.com/jboulhous/meteor-collection2-bug
demo : http://collection2-lose-sub-schema.meteor.com

go to the demo and insert a new APPLICATION.Produits Model, (there is a helper function newProduct on global scope to generate a model), the demo uses autopublish, you will see that the created entry in mongo loses the "informations" proprety value for an empty object

would you please help me with this.

Hi, I got this strange error server-side after updating to the latest version:

(STDERR) myCollection2.callbacks() is deprecated on the server; move to client-only code

I don't run myCollection2.callbacks() at any point though, I put the models in a root .coffee file so they are both server and client. Any ideas on what it could be?

Thanks in advance for your time

I've got a collection like the following:

ConnectionInvitations = new Meteor.Collection2('invitations', {
  schema: {
    'senderId': {
      type: String,
      label: "Sender"
    },
    'receiverId': {
      type: String,
      label: "Receiver"
    },
    'subject': {
      type: String,
      label: "Subject"
    },
    'message': {
      type: String,
      label: "Message"
    },
    'sender': {
      type: {
        'status': {
          type: String,
          allowedValues: [ 'pending', 'accepted' ]
        },
        'deletedAt': {
          type: Date,
          optional: true
        },
        'deletedBy': {
          type: String,
          optional: true
        }
      }
    }
  }
});

I provide all attributes (except the optional ones) on insert.

Problem is:
The document can never be inserted ... unless I stick an "optional: true" attribute on 'sender'. Note, of course, that I don't want the sender to be optional, and I especially do not want the 'sender.status' to be optional. I'm either doing something wrong, or this might best be coded some other way... please advise.

Second problem:
If I stick the "optional: true" attribute on "sender", than the document does get stored but it does not save the 'sender.status'. That is, all attributes are stored except for the sub-attributes.

BTW, in both problem cases I've tried both mongo dot-notation and the regular object hierarchical notation. Same result.

I just tried this:

@Orders = new Meteor.Collection2(
"orders" # collection name
smart:true # make it a smart collection
schema:
    recipients:
        type:[String]
        optional:true
)

I was able to do an insert of an array of document IDs but updating via $push failed

Orders.update(order._id,{$push:{recipients:@_id}})

I used underscore to check if _id was returning a string by using _.isString and I get true. I also tried changing the schema to this:

@Orders = new Meteor.Collection2(
"orders" # collection name
smart:true # make it a smart collection
schema:
    recipients:
        type:Array
        optional:true
            "recipients.$":
                    type:String
                    optional:true
)

But it still fails. Am I doing something wrong? What can I do to fix this?

Thanks in advance for the help!

Hi, I think this is a bug..

I've been using the package with 0 issues until I started getting validation errors on the db update method.

Everything seemed to be set up correctly, and it was. I noticed that 2 of 5 fields weren't validating for some reason.

Eventually I discovered only those two fields had placeholder attributes on them in the template, and each value within that placeholder didn't meet the schema. So I deleted them and the document was updated as intended.

Allow rules must be explicitly declared for all Meteor.Collection2's, otherwise 403 Access denied is thrown.

api.imply is not enough, I must use api.use to resolve error.

    if (typeof api.imply !== "undefined") {
        api.imply('simple-schema', ['client', 'server']);
    }
    api.use('simple-schema', ['client', 'server']);

Hi there,
from reading about meteor I picked up a prelimnary list of ideas concerning collection design. I think it would be interesting to discuss them with regard to collection2 and relation handling:

1. The database collections are primarily modelled for/after different pub/sub queries and to provide atomic documents, not as a normalized data object store.
2. Publications can contain documents from different collections.
3. The templates and partials model the (dom) objects that can join data from different (subscribed) collections, and are updated automatically when data changes.
4. The "less" css styles (with class inheritance) define the appearance (dom view).
5. Javascript event hooks are added to templates to modify data, which then triggers the computations of invalidated templates and code in Deps.autorun().

• Thus do a careful analysis of the most commonly used queries in your application.
• Design collections for optimized server/client data transfer.
• Collections should reflect/support the performance of the types of queries made.
• It can be ok to consolidate and merge multiple tables into one collection.
• Think in terms of documents with different schemas that may be in the same collection, rather than table schemas.
• In particular, instead of having to rely on a query that joins data from different tables, documents with different schemas may be fetched in one sweep from a single common collection.

However, separate collections can be handled easier when it comes to meteor publication/subscriptions.

And the templates (the dom model) can still join different queries together when rendered. As the data on the client is already reduced to a smaller subset, performance should be reasonably fast even with minimongo not yet supporting indexes.

• References (relation links) are used to reduce duplication/repetition.
• A reference may point to another document in the same or another collection.

I defined my insert function within a meteor.methods block. Within the insert's own callback, I check the error and if there is one, I throw a meteor.error containing the invalidkeys. Otherwise I return the generated id as the result.

For any validation error except for the unique check, my method callback receives the error.

But for unique error, I receive back an id although no actual db write happens.

If I do normal client side insert, then all is fine.

Hey there,

I tried using collection2 in a local package and I got the following exception:

ReferenceError: Match is not defined
at new Meteor.Collection2 (packages/collection2/collection2.js:20)

Is this a bug? I fixed it by adding 'check' as a dependency in collection2's package.js file:

api.use('check');

I have a rough idea of a way to handle on-the-fly conversions.

1. Add convert option to schema, false by default.
2. Override the find method. If convert: true and autoValue is set, call an asynchronous update for all of the documents that find is returning, right before they are returned.
3. For each update, get the complete current doc, pass that to autoValue for each field needing conversion, then do $set for that field with the returned auto value.

The idea is that most schema changes don't require large scale data conversions. Instead, each document can be converted the first time it is requested. Since we'd do the conversion updates asynchronously, it wouldn't affect find performance all that much. Unconverted documents would be used temporarily until the conversion completes, causing deps update.

One key would be to be able to track when the conversion has run for a doc. This likely requires creating an indexed tracking collection to be used internally by C2. This would do two things: prevent running the conversion more than once per doc, and allow the user to see when a conversion has been run on all docs, meaning that any code handling the old schema can be removed. To do this accurately, we might also need a version option, or maybe convert can be set to a version identifier instead of true.

Anyone with thoughts, feel free to comment.

Meteor.users is the default meteor collection storing users documents. It would be cool to be able to define extra fields with extra rules such as index or autoValue on this special collection.

Since this collection already have a kind of default schema, maybe we could use an extendSchema method to define new fields?

It seems that (server side?) updates fail when an it is done on a collection that has "Object" fields.

If you do something like:

@col = new Meteor.Collection2 "col",
    schema:
        "name":
            type: String
        "embed":
            type: Object
        "embed._id":
            type: String

The following will fail:

col.update {_id: ...},{$set:{name:"Updated name"}}

More specifically, you'll get an "invalid key" for "embed._id", even though it is simply not touched by the update. I guess this can be circumvented by using the _collection field directly, but that doesn't sound like what should happen here. (Sorry for using Coffeescript syntax.)

I have this collection2 :

Items = new Meteor.Collection2("items",{
schema: {
name: { type: String, max: 60 },
mainDirectory: { type: String, max: 65, unique: true },
mainPageThumbnail: { type: [Object]},
mainPageBackground: { type: [Object]},
category: { type: String },
cssStyle: { type: String },
inGridSize: { type: String },
mainRank: { type: Number, max: 999 },
itemSubCategories: { type: [Object] },
'itemSubCategories.$.name': { type: String },
'itemSubCategories.$.text1': { type: String, max: 5000 },
'itemSubCategories.$.text2': { type: String, max: 5000 },
'itemSubCategories.$.video': { type: String, regEx: SchemaRegEx.Url, max: 500 },
'itemSubCategories.$.songs': { type: [Object] },
'itemSubCategories.$.pictures': { type: [Object] },
'itemSubCategories.$.testimonialsPictures': { type: [Object] }
}
});

when I try update itemSubCategories.$.pictures
var modifier = {$set: {}};
modifier.$set[ "itemSubCategories." + activeItemSubCategories + ".pictures" ] = {name: "picture1.jpg", position: '1'},{name: "picture2.jpg", position: '2'} ;

I have this message :
Uncaught Error: When the modifier option is true, validation object must have at least one operator

I try lot of variations, always the same result.
All my others updates on client side work well.
As workaround, I go do my update server side, with the exact same syntax.

Is there a supported/proper way to have labels in the schema definition that can be translated?

In particular, for the the meteor message format:
https://github.com/gadicohen/meteor-messageformat
http://messageformat.meteor.com/

We have a Python app that is directly inserting information into MongoDB without passing through Meteor, and when using a normal Meteor Collection the Collection automatically updates based on the information entered into the DB, but when we use Collection2 with a schema, the collection doesn't automatically update even though the same information is being added. If we pass the information through a collection it works fine when entering information from the Meteor application, but not when inputting the information into the DB directly. Is this an intended use case of Collection2 that we have to work around (and if so, what is that workaround?), or is this a bug that we've stumbled onto here?

While designing a fairly large domain, I came to the conclusion that, incorporating collection-wide allow/deny rules within the schema definition itself could greatly improve code structuring.

Perhaps with a this similar to that of autovalue's and/or val, obj, operator like valueisallowed's.

I can't imagine how and if it should be implemented on the server, though.

Meteor.Collection's insert returns the ID of the new record. collection2 does appear to.

Hi, I'm getting this error not just on my computer but on other people's meteor installation. What do you think is wrong? Is it the smart.json?

/usr/local/lib/node_modules/meteorite/lib/sources/git.js:151
hrow "There was a problem checking out " + self.checkoutType + ": " + (self.co

I'm not sure if others have found this but I haven't been able to successfully query virtual fields on my Collection2. I can query fields successfully on non-virtual fields as one would expect.

Hi,

I'm trying to implement a common property, within all my schemas, called onDb which is false if the insert/update is still on the client and true if it has reached the server.

Normally, I'd achieve it by passing the onDb property within my insert/update statement and use this.isSimulation to get the correct value.

But I'm implementing this common property in a base schema which I extend all my other schemas and I like to further improve this abstraction by actually providing the value of onDb from within an autoValue function.

Since the this in this.isSimulation is another context that of which belongs to meteor.methods, is there a way I can access it?

When I add my model I get this error I'm running meteor 0.6.5

W20130817-22:40:13.774(-7)? (STDERR) /Volumes/Hybrid/Users/fda/.meteor/tools/4010e5731d/lib/node_modules/fibers/future.js:173
W20130817-22:40:13.856(-7)? (STDERR) throw(ex);
W20130817-22:40:13.857(-7)? (STDERR) ^
W20130817-22:40:13.857(-7)? (STDERR) TypeError: Object.keys called on non-object
W20130817-22:40:13.857(-7)? (STDERR) at Function.keys (native)
W20130817-22:40:13.857(-7)? (STDERR) at new SimpleSchema (packages/simple-schema/simple-schema.js:14)
W20130817-22:40:13.858(-7)? (STDERR) at new Meteor.Collection2 (packages/collection2/collection2.js:11)
W20130817-22:40:13.858(-7)? (STDERR) at app/model.js:14:21
W20130817-22:40:13.858(-7)? (STDERR) at app/model.js:39:3
W20130817-22:40:13.859(-7)? (STDERR) at mains (/Volumes/Hybrid/Users/fda/Documents/Development/Meteor/retrosoda/.meteor/local/build/programs/server/boot.js:153:10)
W20130817-22:40:13.859(-7)? (STDERR) at Array.forEach (native)
W20130817-22:40:13.956(-7)? (STDERR) at Function..each..forEach (/Volumes/Hybrid/Users/fda/.meteor/tools/4010e5731d/lib/node_modules/underscore/underscore.js:79:11)
W20130817-22:40:13.957(-7)? (STDERR) at /Volumes/Hybrid/Users/fda/Documents/Development/Meteor/retrosoda/.meteor/local/build/programs/server/boot.js:80:5
=> Exited with code: 1

this would be really nice to have and pretty simple implement i am guessing.

please make unique: true a reality

One of the natural evolution of the collection2/simpleSchema/autoForm stack is the ability to define some relationships between models. This feature is build in most popular frameworks (Rails [1], Django [2], Symfony [3]...) and there are no good package for this purpose on Meteor right now.

I'm sure you already think of this a lot @aldeed. Could you share what are your plans to support relations at the current state?

Some of the questions raised by this topic:

• What relations do we want? For instance rails split the one to many relation into belongs_to and has_one. Do we need this kind of distinction?
• Do we automatically add fields to collections when we need, or do we let the user define explicitly fields names for relationships with other models?
• How organize the code related to relations, is it more a collection2 or a simpleSchema functionality?
• How do we manage autoForms with relations?
• API to declare a relation? Something like this?

    Manufacturers = new Meteor.Collection2('manufacturers', { schema: {
        name: {
            type: String
        }
    }});

    Cars = new Meteor.Collection2('manufacturers', {schema: {
        manufacturer: {
            // Associate a relationship type with another model/collection2
            oneToMany: Manufacturers 
        },
        color: {
            allowedValues: ['white', 'black']
        }
    }});

• How do we validate a object with relations? Could we add constraints on relations (for instance we might want to limit a blog post to 5 related tags, where posts and tags are both models)?

I think a lot a Meteor users will be interested by this topic, so feel free to post suggestions here :-)

[1] : http://guides.rubyonrails.org/association_basics.html
[2] : https://docs.djangoproject.com/en/1.6/topics/db/models/#relationships
[3] : http://symfony.com/doc/current/book/doctrine.html#entity-relationships-associations

When I set a min value for a field and make it zero, it wont do an update with an $inc of a negative value.

i.e.
schema:{
Value:{
type:Number,
min:0}
}

BlahBlah.update({_id:Meteor.userId(),{$inc:{Value:-5}}) does not work.

Meteors _ensureIndex could be used until the stable API comes along.
http://stackoverflow.com/questions/11392566/mongo-geospatial-index-and-meteor