docs: add info about read/write only behavior #608
Conversation
WalkthroughThe documentation for request validation has been significantly updated to enhance clarity and comprehensiveness. It now includes detailed explanations of Go struct tags used for JSON Schema validation, including field naming, optional and required fields, nullable fields, and validation tags. The documentation also clarifies the behavior of strict versus loose field validation and introduces advanced validation features for custom JSON Schemas. Changes
Assessment against linked issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #608 +/- ##
=======================================
Coverage 92.83% 92.83%
=======================================
Files 22 22
Lines 3923 3923
=======================================
Hits 3642 3642
Misses 236 236
Partials 45 45 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (1)
docs/docs/features/request-validation.md (1)
140-147: LGTM! Clear explanation of read-only and write-only field behavior.The added section provides valuable clarification on how Huma handles read-only and write-only fields, which aligns well with the PR objectives. It effectively communicates that these validations are for documentation purposes and that the responsibility for managing these fields lies with the service author.
There's a minor typographical issue on line 144. Consider revising the sentence structure:
-The server should ignore both the presence and value of the created date, otherwise clients have to make potentially many modifications before data can be sent back to the server. +The server should ignore both the presence and value of the created date. Otherwise, clients have to make potentially many modifications before data can be sent back to the server.🧰 Tools
🪛 LanguageTool
[typographical] ~144-~144: The word “otherwise” is an adverb that can’t be used like a conjunction, and therefore needs to be separated from the sentence.
Context: ...h the presence and value of the created date, otherwise clients have to make potentially many m...(THUS_SENTENCE)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
- docs/docs/features/request-validation.md (1 hunks)
🧰 Additional context used
🪛 LanguageTool
docs/docs/features/request-validation.md
[typographical] ~144-~144: The word “otherwise” is an adverb that can’t be used like a conjunction, and therefore needs to be separated from the sentence.
Context: ...h the presence and value of the created date, otherwise clients have to make potentially many m...(THUS_SENTENCE)
Add information about read-only and write-only field behavior so that expectations are set about what Huma will handle vs. the service author themselves.
Fixes #604 with some documentation.
Summary by CodeRabbit