Great stuff, suggestions

[Tim Shnaider]

Really nice Scott, pretty much a light weight version of mongoose schema support, exactly what I'm looking for.

Please look at applying some of the concepts mongoose has such as:

• supporting an array of validator functions
• .validate() method return array of errors
• set/get path style

The validation should be checked explicitly instead of silently ignoring sets that do not meet rules.

[Tim Shnaider]

I'll fork this project and look to enhance it as above.

[scotthovestadt]

I've been planning on adding validation. I'm happy to add you as a contributor, but please add unit tests for any new functionality.

[scotthovestadt]

Added you as contributor.

There are two parts to implementing validation, rejected data and validation of accepted data.

Right now, the default behavior for any rejected data is to simply ignore it. For example, if you try to set an array on a string, it's just ignored. If you're using the library for validation, there will be use-cases where this isn't OK. However, the current behavior is valid for many use-cases too. I think that the solution to this is a mode that allows exceptions to be thrown when a completely wrong type of value is set on an index. Like, an array on a string type. You can always use "any" type if you don't want to enforce.

Then, on top of this, there are validators, which are simple to implement -- just a function that checks the value after it's been accepted & typecasted and can return an error. Then you can check the whole object for errors or just check individual fields.

Thoughts?

[Tim Shnaider]

My thoughts are, do it like pretty much every other validation library :)
Which is: set all properties, and then do validation.

Then you get an array of all errors back, instead of an error at a time.

User corrects data from all the error messages, then submit/validate again.

You then minimise the number of potential round trips for input/validation.

I can't think of a use case where I want a set to be silently ignored.
Sure you could throw an Error on the set if it fails validation, but you have the same issue of only handling one error at a time.

As I said originally, I like the Mongoose JS style of schema/model implementation.

I'd actually use Mongoose as my object wrapper if it wasn't so heavy weight, and you schema-object comes a close second:

• validation (with concerns above)
• enforcement of schema i.e. no spurious/extra properties are included in toObject()

I have a tight deadline for a project right now, so I'm going to use the module as is and quickly add support for validate function/array allowing custom validators, and a validate function, with options support for SchemaObject indicating whether to ignore invalid values .. you see where I'm going.

I'd be keen on incorporating Backbone.Model style change tracking and event notification as well, the ultimate Schema/Model library!
http://blog.andyet.com/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/

[scotthovestadt]

OK, go for it, I agree with you. In retrospect, it's not necessary to ignore invalid values, as long as there is an easy mechanism to retrieve a "clean" validated-only version of the object.

[Paul Em]

Hey guys, this is the exact conversation i wanted to start right now. How is the validation going? My thoughts would have been:

add a "validate" or "required" option to some (all?) types, if it is set to true and the value does not fit and typecast is not working you can add it to an error array that you can return in the end.

Anyhow, great work!

[scotthovestadt]

That's a good suggestion. I'll look into implementing that.

I'm not exactly sure how errors should work though. A getErrors and clearErrors call?

[Paul Em]

Since I needed to check all fields (even those not in the data) i had to rewrite the whole plugin and ended up with this : https://github.com/paul-em/mongo-schema

My way is: Editing the object directly and returing an array of errors.

[scotthovestadt]

The next version of schema object will include the ability to check an object for errors (getErrors), clear existing errors (clearErrors), and catch when an error is thrown by a value being set (onError property).

I expect to release this within a week.

[scotthovestadt]

OK, attempts to set invalid values will no longer fail silently.

var SO = new SchemaObject({
  string: {type: String, minLength: 15}
});
 var o = new SO();
 o.string = '1234';
 console.log(o.getErrors());

// Outputs:
[ { errorMessage: 'String length too short to meet minLength requirement.',
    setValue: '1234',
    originalValue: undefined,
    fieldSchema: { type: 'string', minLength: 15 } } ]

I'm working on documentation for this feature.