How to avoid breaking changes when redeploying Sanity API

Hello again! I went to re-deploy my api and got a lot of warnings re: dangerous changes. Should I be concerned about these? Is there a specific reason these would all be changing like this? I don’t remember modifying the schemas this much. Here’s a sample:
Found BREAKING changes from previous schema:
- BlogPost._id changed type from ID! to ID.
- BlogPost._type changed type from String! to String.
- BlogPost._createdAt changed type from DateTime! to DateTime.
- BlogPost._updatedAt changed type from DateTime! to DateTime.
- BlogPost._rev changed type from String! to String.
- Document._id changed type from ID! to ID.
- Document._type changed type from String! to String.
- Document._createdAt changed type from DateTime! to DateTime.
- Document._updatedAt changed type from DateTime! to DateTime.
- Document._rev changed type from String! to String.
- SanityImageAsset._id changed type from ID! to ID.
- SanityImageAsset._type changed type from String! to String.
- SanityImageAsset._createdAt changed type from DateTime! to DateTime.
- SanityImageAsset._updatedAt changed type from DateTime! to DateTime.
[….]

Hi Stu!
In the vast majority of cases this particular change is not something you should be worried about.

A while back we discovered that the schema incorrectly said that these fields were "always" present - but that people were embedding document types inside of other documents, which makes that assumption false (in those cases).

We added a flag to let you get the old behavior back, should you not want the change - add the

--non-null-document-fields

flag to the command. Eg:

sanity graphql deploy --non-null-document-fields

Ok, good to know - thanks a lot!

We added a flag to let you get the old behavior back, should you not want the change - add the

--non-null-document-fields

flag to the command. Eg:

sanity graphql deploy --non-null-document-fields

Hi Stu!
In the vast majority of cases this particular change is not something you should be worried about.

A while back we discovered that the schema incorrectly said that these fields were "always" present - but that people were embedding document types inside of other documents, which makes that assumption false (in those cases).