Permalink
Fetching contributors…
Cannot retrieve contributors at this time
134 lines (99 sloc) 2.78 KB

Collection Properties

modelClass

Every collection requires a Model for representing its records. This property directly references to the Model class.

Be defalult, it is set to the base Model class, which you can always override.

table

The name of the table that this Collection represents. Always as a string.

schema

Collections do not necessarily need to define their full schema, but you would need them for building fixtures (for tests) and also assigning validation rules, for e.g., later.

The keys of this object are the column names, and the value defines what type of column they are. For example:

{
  id: {
    type: 'integer'
  },
  title: {
    type: 'string'
  }
}

Column types can vary depending on the adapter you are using.

Additional information per column will also allow generating tables for fixtures more accurately:

{
  id: {
    type: 'integer',
    primary: true // Primary index
  },
  title: {
    type: 'string',
    length: 100, // 100 characters limit
    unique: true, // Unique index
  },
  description: {
    type: 'text',
    textType: 'longtext', // `longtext` or `mediumtext` in SQL
    nullable: true // allow field to accept `NULL`
  },
  cost: {
    type: 'float',
    precision: 8,
    scale: 2,
    comment: 'cost column' // additional comment in SQL
  },
  published: {
    type: 'enum',
    values: ['Y', 'N'],
    default: 'N', // default value in SQL
  }
}

You can also use the schema property to set validation rules.

For example:

{
  email: {
    type: 'string',
    validate: {
      rule: 'isEmail',
      message: 'Please enter a valid email address'
    }
  }
}

Validations will be discussed further later in its own section.

primaryKey

The name of the ID field, defaults to id.

displayField

This is the field that represents your record's display value. Usually title or name in most cases.

validationRules

Define rules logic which can be used for various fields.

Example:

{
  ruleName: function (field, value) {
    return true;
  },
  asyncRule: function (value, field, done) {
    return done(true);
  },
  ruleWithOptions: function (value, field, arg1, arg2) {
    return true;
  }
}

See Validations section later for more documentation on this.

behaviors

Array of behavior classes, in the order as you want them applied.

Example:

[
  TimestampBehavior,
  AnotherCustomBehavior
]

loadedBehaviors

Array of already loaded behaviors for this model

alias

Unless defined, alias always defaults to the table property. When associations get in the way, having a unique alias helps avoiding ambiguity when constructing complex conditions.

If you have a Posts collection for the table posts, with a model Post, it is safe to have an alias Post (in singular form).