In-place columns for hot counters and flags

In-place columns for hot counters and flags #

Fields that change constantly — view counters, stock levels, feature flags, ranking scores — used to pay a full document rebuild on every partial update. Marking a numeric or boolean field with "inplace": true gives it a dedicated typed column instead:

PUT /my-collection
{
  "properties": {
    "title": { "type": "keyword" },
    "views": { "type": "integer", "inplace": true },
    "score":  { "type": "double",  "inplace": true },
    "active": { "type": "boolean", "inplace": true }
  }
}

Partial updates on such fields become O(1) column writes — no fetch, merge, and re-index of the document. Atomic-style operators work directly against the column:

Get collection schema

Get collection schema #

Returns schema information about one or more collections.

Examples #

The following request gets the schema information of all the collections under the default namespace:

GET /default:*/_schema

Retrieve the schema information of all the collections:

GET /_schema

Request #

GET /<target>/_schema

Path Parameters #

• target
  (Optional, String) Comma-separated, names of the collections to get (wildcard supported)

Update collection schema

Update collection schema #

Apply an additive schema diff (new or updated field definitions) to an existing collection. The change is replicated through Raft and every shard engine of the collection picks it up.

Field deletion is not supported by design — a schema diff can only add or update properties.

Examples #

Add a title text field and a non-indexed user.name keyword field to the collection my-collection:

semantic_text — one-field semantic search

semantic_text — one-field semantic search #

Semantic search used to mean wiring two fields: a text field for the source, a dense_vector field with vector_options pointing back at it. The semantic_text field type collapses all of that into one declaration:

PUT /my-collection
{
  "schema": {
    "properties": {
      "body": {
        "type": "semantic_text",
        "service": "zai",
        "model": "GLM-4.6V",
        "dims": 3072
      }
    }
  }
}

From there everything derives. Writes carry plain text — the vector is embedded server-side at write time, in bulk and after partial updates alike. Search needs no field names and no vectors: