Default Values about meteor-simple-schema HOT 5 CLOSED

The simple-schema package doesn't have this because the assumption is that you would set default values on the object before validating it, but there is development underway to add an autoValue schema option for the collection2 package. This function could be used to set a default value. See Meteor-Community-Packages/meteor-collection2#6 and Meteor-Community-Packages/meteor-collection2#9.

from meteor-simple-schema.

The question is: if I define a autovalue field in my schema and the user pass a document with a field with the same name, should we:

• overwrite the autovalue?
• overwrite the user field?
• return a validation error?

The first purpose of autoValue fields was to create createdAt and updatedAt automatically populated on insert/update. Of course there are other use cases, but I don't think that a default value is one of them. I don't want a user to be able to overwrite createdAt, updatedAt, nbUpdates or randomId field (see the implementation of those fields using autovalue).

So we need another option in the schema definition to handle the default value use case:

• One solution is to create a defaultValue function which works the same that autoValue but can be overwritten.
• The other possibility is to add a overwritable boolean, default to false, that works with the autoValue field

Thoughts?

from meteor-simple-schema.

My thinking was that if a user passed in a document without a field that had an autoValue or defaultValue set it would insert that document with the field's autovalue.

So for example, if I was tracking the number of comments on a post and a new post was created, the comments field would default to 0 rather than undefined. Of course, there are many ways around this such as setting { comments: 0 } in the object before it was passed to the collection like @aldeed mentioned, which might even make more sense. So by all means, don't feel like this should be implemented if it shouldn't be part of the schema.

If something is implemented in the future though, I'm in favor for a defaultValue function that would be overwritten if a value was passed in. So that way, like you said, the createdAt etc fields would still be locked.

from meteor-simple-schema.

The autoValue function receives the whole document so I thought maybe users could do the checking in there and return the user-supplied value if they don't want to overwrite the value. So:

• If you want to force a value regardless of what the user might enter, make sure autoValue returns the value you want.
• If you want to define a default value using autoValue, first check whether the value is already set. If so, return that value (or undefined), otherwise return the default value. We could also pass the user-supplied value as an argument so that each autoValue function won't have to individually implement the code to pull the value out of doc.

Then we would always overwrite unless they returned undefined.

from meteor-simple-schema.

Closing this since it's being addressed in collection2 package.

from meteor-simple-schema.