[dudanogueira]

What

Raw-JSON variants of the collection schema calls, on the sync and async clients:

client.collections.createFromJson(json);   // POST /schema, body sent as-is
client.collections.getConfigAsJson(name);  // GET /schema/{name} -> Optional<String>
client.collections.listAsJson();           // GET /schema -> String

Changes

• CreateCollectionRequest, GetConfigRequest and ListCollectionRequest are parameterized by payload type; a String payload/response is passed through unparsed (SimpleEndpoint.deserializeClass), so typed and raw calls share one request class.
• The create endpoint returns Void instead of parsing the echoed config, which a raw document may not fit into CollectionConfig.
• createFromJson reads the "class" key to return a handle; a document without one fails with IllegalArgumentException before sending (a failed future on the async client).

Breaking changes

The public _ENDPOINT fields on CreateCollectionRequest, GetConfigRequest and ListCollectionRequest are replaced by endpoint(...) factory methods.

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[bevzzz]

I suggest a different approach, probably one that will result in better code-reuse / less duplication.

The only difference between create(CollectionConfig) and createFromJson(String) is the payload. To add "from/to JSON" to the current client it should be enough to allow GetConfigRequest, CreateCollectionRequest, and ListCollectionsRequest to accept a generic parameter saying what the request/response payload should be:

public record GetConfigRequest(String collectionName) {
  public static final <T> Endpoint<GetConfigRequest, Optional<T>> endpoint(Class<T> cls) {
    return OptionalEndpoint
        .<GetConfigRequest, T>noBodyOptional(
            request -> "GET",
            request -> "/schema/" + request.collectionName,
            request -> Collections.emptyMap(),
            (statusCode, response) -> JSON.deserialize(response, cls));
  }
}

This way the same GetConfigRequest can be used to return:

• CollectionConfig, if used like so GetConfigRequest.endpoint(CollectionConfig.class)
• Raw JSON string, if used like so GetConfigRequest.endoint(String.class)

Same for list and create endpoints.

Would you like to take a stab at that? I'm happy to take this over, this seems like a small enough change.

---

Wrt to the "Not addressed here" section: if you find any bugs while working on a PR, please open a ticket for those. A PR description is not the right place to document bugs.

[dudanogueira]

Thanks — took a stab at it, done in 94de2ef.

GetConfigRequest, ListCollectionRequest and CreateCollectionRequest now take the payload type as a parameter, and CreateCollectionFromJsonRequest, GetConfigJsonRequest and ListCollectionJsonRequest are gone. The public client API is unchanged.

GetConfigRequest.endpoint(CollectionConfig.class | String.class)
ListCollectionRequest.endpoint(ListCollectionResponse.class | String.class)
CreateCollectionRequest.<CollectionConfig | String>endpoint()

Rather than a per-request deserializer, SimpleEndpoint.deserializeClass special-cases String.class and returns the body unparsed, so any endpoint parameterized by response type gets the raw option for free. On the write side a String payload is forwarded byte-for-byte and anything else is serialized first.

Two things I decided along the way, shout if you'd rather have them differently:

• The create endpoint now returns Void instead of parsing the echoed configuration into CollectionConfig. Both clients were discarding it, and a raw payload may describe a collection CollectionConfig cannot represent — that parse would have thrown.
• The "class" lookup moved to CreateCollectionRequest.collectionNameFromJson, which both clients call before sending, so an unusable document still fails before the request leaves the process.

On the "Not addressed here" section — fair point, moved out to #606 and #607 and trimmed the description down to a reference.

[dudanogueira]

@bevzzz gentle nudge on this one — the refactor you asked for went in as 94de2ef a couple of weeks ago and the two decisions I flagged are still open for you to overrule (the create endpoint returning Void rather than parsing the echo, and the "class" lookup moving into CreateCollectionRequest.collectionNameFromJson). CI is green.

No rush on the rest of my open PRs — if it helps, this is the one worth looking at first. The other six are independent single-defect fixes, but this one is the shape decision, and I would rather build on your answer here than guess.

One thing I would like your view on before proposing it separately: the same raw-JSON escape hatch is missing on the update side. WeaviateConfigClient.update only takes the typed builder, so there is still no way to send a definition the client cannot model, which is the half that runs on every configuration change rather than once at creation.

It looks like a close parallel to createFromJson under the refactored shape — UpdateCollectionRequest<T>(T updated, String collectionName), with the name coming from the caller rather than from the document. It would also remove code rather than add a parallel path: the typed request currently re-serializes the config and then patches skipDefaultQuantization back out of the original, which exists only because the typed round trip does not preserve what the server sent. A document forwarded byte-for-byte needs none of that.

Happy to add it to this PR or send it as a follow-up once this lands — whichever you prefer.

[Copilot]

🟡 Changes recommended

Outstanding review nits concern the misleading asyncClient name for a synchronous client and the unnecessary public exposure of a package-internal parsing helper.

2 open issues

• Rename asyncClient to clarify it is a synchronous client · New
• Make collectionNameFromJson package-private · New

What changed in this PR

Adds raw JSON schema operations to the synchronous and asynchronous collection clients, allowing callers to use schema options not represented by CollectionConfig.

Changes:

• Adds createFromJson, getConfigAsJson, and listAsJson, with collection-name validation before creation.
• Shares typed and raw endpoint implementations through factories, preserving raw strings and ignoring create-response bodies.
• Adds validation and round-trip tests, plus async-indexing support for integration-test containers.

File	Description
src/​test/​java/​io/​weaviate/​client6/​v1/​api/​collections/​GetConfigRequestTest.java	Tests typed/raw reads and missing-collection handling.
src/​test/​java/​io/​weaviate/​client6/​v1/​api/​collections/​CreateCollectionRequestTest.java	Tests payload serialization, validation, and failed futures.
src/​main/​java/​io/​weaviate/​client6/​v1/​internal/​rest/​SimpleEndpoint.java	Returns string responses without parsing.
src/​main/​java/​io/​weaviate/​client6/​v1/​api/​collections/​WeaviateCollectionsClientAsync.java	Adds asynchronous raw JSON operations.
src/​main/​java/​io/​weaviate/​client6/​v1/​api/​collections/​WeaviateCollectionsClient.java	Adds synchronous raw JSON operations and documentation.
src/​main/​java/​io/​weaviate/​client6/​v1/​api/​collections/​ListCollectionRequest.java	Adds an endpoint factory for typed or raw list responses.
src/​main/​java/​io/​weaviate/​client6/​v1/​api/​collections/​GetConfigRequest.java	Adds an endpoint factory for typed or raw optional responses.
src/​main/​java/​io/​weaviate/​client6/​v1/​api/​collections/​CreateCollectionRequest.java	Supports typed/raw payloads, validates names, and ignores response bodies.
src/​it/​java/​io/​weaviate/​integration/​CollectionsITest.java	Tests raw schema round trips and missing-name rejection.
src/​it/​java/​io/​weaviate/​containers/​Weaviate.java	Adds an async-indexing container setting.

_{Review effort: Max}