Where to hook in pre and path schema extensions?

[mathiasm74]

At the moment I've added my pre and path schema extensions in the implementation of a doInit() static function that I call for each document type on node-startup. Is this the way to do it, or is there a better (undocumented) way? If not, could you add something, similar to that for virtuals? E.g.

exports.pre = {
  save: function(next) {
  }
}

exports.paths = {
  theProperty: {
    set: function(newValue) {
      return ...
    }
    validate: function(newValue) {
      return ...
    }
  }
}

[chevcast]

I'm not deeply familiar with these mongoose features. Can you better explain to me what you mean by "pre and path schema extensions" and what those do in mongoose? It definitely seems like these should be supported the same way but I first want to understand them better. If you wouldn't mind explaining or linking me to an explanation then I'll take a look at it this evening :)

[mathiasm74]

Looking closer at it now, I guess the path() function is just the selector you call on a property before you can go on to set other things for that property, like the default value, index, match-pattern etc. Some of these things you already cater for in the exports.schema section, but the things I came across now are custom setters and validators. You already support this for virtual properties, but as far as I can tell not for regular properties (or at least the document doesn't mention it). I guess logically those should go in the blocks specifying each property in the schema section, although I also like the way the schema section at the moment is brief and easy to read. I'd hate to clutter it with custom setter implementations...

The pre() operations ("init", "save", "validate", "remove", see http://mongoosejs.com/docs/middleware.html) are useful for performing actions e.g. before a document is saved. In my case I hash the user's password (see http://stackoverflow.com/questions/14588032/mongoose-password-hashing) and make sure immutable properties don't have their value changed (which when I come to think if it might be a feature you could offer). The pre-operations might warrant their own section, more so than the path() I mentioned before.

[chevcast]

I don't think the paths property makes sense here, as you said in your last comment. However, adding in functionality for pre seems to make sense. I will explore and see how this best fits into simpledb.