Add render template support#975
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds experimental render template support to the Java SDK: a ChangesRender Template Experimental Feature
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/main/java/com/meilisearch/sdk/Client.java`:
- Around line 492-495: The Client.renderTemplate() method is currently always
callable, so the experimental opt-in is only documented and not enforced. Update
the Client API to gate renderTemplate behind explicit opt-in state on the
client, or expose it only through an opt-in-specific surface, and use the
existing Client and renderTemplate() symbols to ensure calls fail or are
unavailable until the caller has opted in first.
In `@src/main/java/com/meilisearch/sdk/model/RenderTemplateResult.java`:
- Around line 6-10: RenderTemplateResult currently has package-private fields
that Jackson’s default ObjectMapper won’t populate, so template and rendered
deserialize as null. Update the RenderTemplateResult model to make these
properties Jackson-visible by adding standard setters/getters or explicit
Jackson annotations on the existing template and rendered members, while keeping
the class name and field names unchanged so deserialization works correctly.
In `@src/test/java/com/meilisearch/sdk/RenderTemplateRequestTest.java`:
- Around line 13-85: The current tests only validate
RenderTemplateRequest.toString(), so they miss the real request serialization
path used by Client.renderTemplate() through BasicRequest and
JsonHandler.encode(...). Add coverage that exercises the actual outgoing body
serialization for RenderTemplateRequest, including the case where input is
absent, and assert the wire-format JSON produced by the request serializer
rather than only the model’s toString() output.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 02f51f49-4d32-4234-a18a-9d389a80f85f
📒 Files selected for processing (5)
.code-samples.meilisearch.yamlsrc/main/java/com/meilisearch/sdk/Client.javasrc/main/java/com/meilisearch/sdk/RenderTemplateRequest.javasrc/main/java/com/meilisearch/sdk/model/RenderTemplateResult.javasrc/test/java/com/meilisearch/sdk/RenderTemplateRequestTest.java
Adds request serialization coverage and response deserialization coverage, and updates RenderTemplateResult for safer JSON mapping.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/test/java/com/meilisearch/sdk/model/RenderTemplateResultTest.java`:
- Around line 11-20: The RenderTemplateResultTest currently only verifies the
scalar-string path in JacksonJsonHandler.decode, so add another case that
decodes a JSON object or array for the rendered field and asserts the structured
value is preserved. Reuse RenderTemplateResult and JacksonJsonHandler in the new
test, and verify both template and rendered so the new Object mapping is
covered.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9318707c-5f72-4704-9899-99f7b799071a
📒 Files selected for processing (3)
src/main/java/com/meilisearch/sdk/model/RenderTemplateResult.javasrc/test/java/com/meilisearch/sdk/RenderTemplateRequestTest.javasrc/test/java/com/meilisearch/sdk/model/RenderTemplateResultTest.java
🚧 Files skipped from review as they are similar to previous changes (1)
- src/main/java/com/meilisearch/sdk/model/RenderTemplateResult.java
|
Hi @Strift , Can you please review this? |
Pull Request
Related issue
Fixes #974
What does this PR do?
Adds Java SDK support for the experimental
/render-templateroute.RenderTemplateRequestto serialize the render template request bodyRenderTemplateResultto represent the API responseClient#renderTemplateto callPOST /render-template.code-samples.meilisearch.yamlHow I tested
./gradlew.bat spotlessApply./gradlew.bat compileJava./gradlew.bat test --tests "com.meilisearch.sdk.RenderTemplateRequestTest" -x jacocoTestCoverageVerificationbash ./scripts/lint.sh./gradlew.bat clean buildNote:
clean buildfails locally only onSettingsHandlerTestwithjava.net.ConnectExceptionbecause a local Meilisearch instance is not running.PR checklist
Please check if your PR fulfills the following requirements:
Thank you so much for contributing to Meilisearch!
Summary by CodeRabbit
renderTemplateAPI to obtain rendered output.toString()output, HTTP request serialization, builder/accessor behavior, and response deserialization.