[FEATURE] Apply schema default values immediately on instantiation of a document
See original GitHub issueProposal:
-
Add dynamoose.model.defaults key of
createWithDefaults
(default false to make a non breaking change) -
Set to true, your defaults would be applied immediately on creating a new document whether its saved or not.
-
In the case a user modifies the document breaking the defaults which have already been applied, thatd be a user error and the call to save would either fail or succeed with their intentionally changed document.
Code sample:
Schema
dynamoose.model.defaults = { createWithDefaults: true };
const MyModel= dynamoose.model('MyModel', {
id: {
type: String,
default: () => uuid(),
hashKey: true,
},
email: {
type: String,
required: true,
},
verified: {
type: Boolean,
required: true,
default: false,
},
});
const modelInstance = new MyModel({ email: 'test@example.com'});
const modelInstance = await MyModel.create({ email: 'test@example.com'});
/*
Should both produce:
{ id: '9981f6d0-92ca-41b8-9c44-2c1d09effd3b', email: 'test@example.com', verified: false }
Regardless of the document being saved/created to the DB or not.
Instead of just:
{ email: 'test@example.com' }
*/
Issue Analytics
- State:
- Created 3 years ago
- Reactions:3
- Comments:24 (4 by maintainers)
Top Results From Across the Web
Rails: How can I set default values in ActiveRecord?
We put the default values in the database through migrations (by specifying the :default option on each column definition) and let Active Record...
Read more >API Reference: ApolloServer - Apollo GraphQL Docs
This article documents the ApolloServer class from the @apollo/server package. You can use the ApolloServer class to create an instance of Apollo Server ......
Read more >Customizing quicktype
We'd like to specify default values for some properties, such as the hit points of a player or monster. We want quicktype to...
Read more >Initial Value Templates - Sanity.io
You can define a single set of initial values to apply to all new documents of the same type; Define a set of...
Read more >Frequently Asked Questions - python-jsonschema
In other words, for many use cases, schema authors may wish to use values for the format keyword but have no expectation they...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Is there any progress with this feature? It’s quite critical for us because we need to return back a document with default values after save or create. Currently, as a workaround we execute create method with { ‘return’: ‘request’ } settings to prefill default values and then save the document with all attributes. But it would be nice to get the correct document back by default or with an extra setting.
@jdrydn I’m confused about what point you are trying to make. Read https://github.com/dynamoose/dynamoose/issues/905#issuecomment-651558108.
If after reading that you are in disagreement, or have additional comments, please leave them. I’m really looking for feedback here (hence why this issue is tagged with discussion).
Remember, this issue has gotten sidetracked in a major way. The original post says:
A lot of this post is now referring to an issue where
model.create
anddocument.save
don’t return items with default values.To me, these are two different issues.
new Model
returning default values, I’m unconvinced if that is a good idea. I also think it raises complexity around async stuff.Model.create
anddocument.save
should return the object they sent to the DB.I almost consider item 2 to be blocked by #1059. I know they are pretty unrelated, but it touches the same logic/function, and there is a chance that the two are connected somehow.
I also consider item 2 to be unrelated to the original issue/post, tho a lot of recent conversation has focused on that item. So maybe your comment about this being a bug, is related to the tag on this issue saying
type:enhancement
or theFEATURE
in the title? If so, that is because I consider the original issue to be related to point 1, not point 2.