pathwaycom/pathway · error · ValueError

vector column {vector._name!r} does not belong to the provid

Error message

vector column {vector._name!r} does not belong to the provided table. Pass a column reference from the same table, e.g. vector=table.{vector._name}.

What it means

The Weaviate output connector requires the `vector` column reference to belong to the same pw.Table instance passed as `table`, since the vectors written must line up row-for-row with the table being indexed. write() compares vector._table to table and raises this ValueError pointing at the correct expression when the reference comes from another table object.

Source

Thrown at python/pathway/io/weaviate/__init__.py:122

    >>> pw.io.weaviate.write(  # doctest: +SKIP
    ...     table,
    ...     collection_name="Docs",
    ...     primary_key=table.doc_id,
    ...     vector=table.embedding,
    ... )
    >>> pw.run(monitoring_level=pw.MonitoringLevel.NONE)  # doctest: +SKIP
    """
    _check_entitlements("weaviate")

    if primary_key is not None and primary_key._table is not table:
        raise ValueError(
            f"primary_key column {primary_key._name!r} does not belong to the "
            f"provided table. Pass a column reference from the same table, "
            f"e.g. primary_key=table.{primary_key._name}."
        )
    if vector is not None and vector._table is not table:
        raise ValueError(
            f"vector column {vector._name!r} does not belong to the provided "
            f"table. Pass a column reference from the same table, "
            f"e.g. vector=table.{vector._name}."
        )

    pk = primary_key._name if primary_key is not None else None
    vector_field = vector._name if vector is not None else None

    # Weaviate reserves "id" and "vector" as object-level keys and rejects them as
    # property names. The primary key (encoded in the UUID) and the vector column
    # are never sent as properties, so they may freely use these names; any other
    # column that does collides and is reported up front.
    reserved_property_columns = [
        column_name
        for column_name in table.schema.column_names()
        if column_name in ("id", "vector")
        and column_name != pk
        and column_name != vector_field

View on GitHub (pinned to fa2f74a464)

Solutions

Write from the table that actually holds the embedding column and reference it directly: pw.io.weaviate.write(t_embedded, vector=t_embedded.embedding).
Add the embedding column to the table you intend to pass: t = t + embedded.select(embedding=pw.this.embedding) before write().

Example fix

# before
t_emb = t + t.select(embedding=pw.apply(embed_fn, pw.this.text))
pw.io.weaviate.write(t, collection_name="Docs", vector=t_emb.embedding)

# after
pw.io.weaviate.write(t_emb, collection_name="Docs", vector=t_emb.embedding)

Defensive patterns

Strategy: validation

Validate before calling

def check_column_belongs(table, col, arg="vector"):
    if col is not None and col._table is not table:
        raise ValueError(f"{arg} column {col.name!r} is not from the given table")
    return True

Prevention

Compute embeddings with table + table.select(...) style expressions so the resulting object owns the embedding column, then write that object.
Lint for the anti-pattern of passing table_a/table_b.mix mixes: both table and column arguments should come from one variable.

When it happens

Trigger: Calling pw.io.weaviate.write(table_a, ..., vector=table_b.embedding) where table_b is a different table instance — typically the pre-transform table or a side table produced by an embedding step.

Common situations: Computing embeddings on one table (t_embedded = t + t.select(embedding=pw.apply(embed))) and then passing the original t as `table` with vector=t_embedded.embedding; keeping stale references after refactor; joining metadata onto an embedded table and mixing up which object to pass.

Related errors

AI-assisted analysis of pathwaycom/pathway@fa2f74a464 (2026-08-15). Data as JSON: /api/errors/6bdff8ec57cb0c2c. Report an issue: GitHub.