Closed petr24 closed 7 years ago
From what I know of the code base we don't separate them, if an option is passed in for a method that options object gets passed into the hook and then also the actual method. So it is actually up to the advice
(the code that runs the defined hooks) to look for the options it needs and use it, but it's not modified after that and just passed through to the actually defined hook also and then through to the underlying method.
However I do believe only fetchPrevious
is the option that is being used by the update advice
.
So we don't modify the options object, each "step" is responsible to just reading the options it needs.
You should be able to modify the options object in your defined hook and in that case the underlying method would get this modified options object. Just remember this won't work if you replace the variable that holds the options object.
Gotcha. Do I have to worry about taking out my options if I am using "multi: true" for example?
I can modify the options to remove the extra stuff in the before hook. Anything that doesn't belong to the actual query, don't know if will do anything internally to options.
I don't know mongo low level enough to know what it does with options it can't use, but it seems to work just fine with the extra options in there currently.
We currently assume that meteor/mongo just use what i wants and ignores the rest. So just make sure your own custom options doesn't have the same name as meteor/mongo options.
Right on, thanks!
Just wondering how you differentiate between the two, when you actually write to the DB.
Example Lets say I am making an update, and need to update multiple documents. I would do something like this.
When this is called, the collection hook gets "{multi: true}" as the options. So If I wan't to add some hook options to that, it would be.
How do you extract the options that go to mongo vs options I use in the hook itself?
Thanks.