Hooks support

[prashaantt]

This looks like just the project I was looking for. Joi is awesome and it's great that you're using that.

Do you support pre and post hooks? I couldn't find any references to that in the docs. If not, is it anywhere on the roadmap?

[jedireza]

Thanks for opening an issue.

Do you support pre and post hooks? I couldn't find any references to that in the docs. If not, is it anywhere on the roadmap?

Pre and post hooks for what exactly?

[prashaantt]

Thanks for responding.

What I meant was the equivalent of the middleware in mongoose, or callbacks in Mongoid (where I'm just coming from to Node).

[jedireza]

Oh I see. This hasn't come up before. We don't have models in the sense that you'd change instance data and call a save method, although you could create a save method in your own models. Also keep in mind that we're not validating against the schema when creating or updating records, that's up to you to use.

My initial thoughts are;

• we don't have any existing life cycle events or extension points today
• since you're already creating a model for each collection, if you want to get in between (pre/post) of a call, you could overwrite some method in your model and proxy the call to mongo directly.

[prashaantt]

Sorry, I don't quite understand the bit about save. I do see insert and update methods here, but indeed no save. Does that mean I'll need to call save on the native mongodb client to actually persist the document? Do you have an example of this that works well with this project?

I'm new to hapi (and indeed Node) but I'm assuming schema validation à la mongoose should be fairly straightforward with Joi in the handler config itself, isn't it? That in fact is reason enough for me to consider this project, because I don't like the idea of introducing another DSL for validation.

Re pre/post, I'm still finding my way here but I think it'd be hard to beat the elegance of the lifecycle methods and it would be great if we could natively support them here.

[jedireza]

Sorry, I don't quite understand the bit about save.

Meaning when you create a model it doesn't come with a save method on it's prototype. And when you call insert or update on a model class you're passing in the object data you want persisted, it isn't coming from the "instance" of your model.

Does that mean I'll need to call save on the native mongodb client to actually persist the document?

Not exactly. From the docs you linked to:

Save

Shorthand for insert/update is save - if _id value set, the record is updated if it exists or inserted if it does not; if the _id value is not set, then the record is inserted as a new one.

As you can see, the native save method isn't related to models or documents persisting themselves.

Do you have an example of this that works well with this project?

Take a look at Frame.

Re pre/post, I'm still finding my way here but I think it'd be hard to beat the elegance of the lifecycle methods and it would be great if we could natively support them here.

I need some more convincing. I'd like to see what having these hooks allows us to do that we can't do without them.

[prashaantt]

Thanks for pointing me to Frame, will take a look at it.

I can't speak for others, but I've used callbacks variously as utilities to keep my code organised. It's useful to track the lifecycle of an object's creation if I don't have control of where or how it's getting created, as long as there are a few checks or additional things I can do to it or to other models that may be affected by its contents. I've also used it to set some fields to nil/null before saving if they're being received as empty strings from the client, etc (effectively, validation). One may argue that some of these things could and sometimes should be done just before/after the object is being directly saved, but callbacks give me the option of keeping things DRY.

Slightly off-topic, how well does HMM deal with nested documents?

[jedireza]

I'm not sure what HMM is.

[prashaantt]

I'm surprised you haven't yet thought of an acronym for your project ;)

I was trying to figure out from the docs and tests if hapi-mongo-models is designed to play well with (deeply) nested documents out of the box, but couldn't find anything. Admittedly, I haven't yet played with it enough to test that out myself.

[jedireza]

I'm surprised you haven't yet thought of an acronym for your project ;)

I see now. Haha.

I was trying to figure out from the docs and tests if hapi-mongo-models is designed to play well with (deeply) nested documents out of the box, but couldn't find anything.

If there are limitations they shouldn't be from this library. The more accurate question to ask is what limitations does mongodb have with nested documents and the same goes for Joi.

[prashaantt]

Makes sense, I'll look that up and open another issue if it doesn't work as expected.