how are you using collection2 are you inserting a doc via the client or meteor method
It depends.
First of all, I make sure I am very thorough with the schema definition. Especially with very extensive custom validations with cross check other fields as well as the current user’s role and rights.
Then, if the collection does not have complex rules about the conditions which allow/deny its insert/update, I write my access rules using ongoworks:security and do normal insert/update. Ongoworks:security helps here because it allows creation of reusable constraint filters and it is all based on deny, which is much safer than allow.
Also, if I’m using autoform, I’m usually more inclined towards using insert/update rather than methods.
But, if the collection has rather complex modifier rules, or rules that can only be run on the server, I then set up a method.
Finally, if I need to partially update a document, where a full form that represents the complete schema is not what I want, I proceed with a method.
Is’nt this a bit of overhead for nothing
Collection2 is very valuable here not only because it provides automatic schema validation, but it also provides a very extensive this context within autoValue and custom which allow me to implement business rules within the schema along with the schema rules. So it definitely pays of.
Some may argue that business rules and schema rules are two different contexts and should be separated.
Well, I do agree but have a different take. As you might perhaps already have gathered from my explanation above:
- I set up business rules outside the schema
- I set up the complete schema with schema (type) rules, but also incorporate the business rules into autovalue and custom blocks
- I then reuse those business rules elsewhere, like ongoworks:security chains and method bodies.