apache/cassandra · error · ParseError

The length of given vector value '%d' is not equal to the ve

Error message

The length of given vector value '%d' is not equal to the vector size from the type definition '%d'

What it means

For a vector column, COPY FROM splits the CSV cell into individual coordinates and requires the count to equal the vector size declared in the schema (ct.vector_size). A different count raises this ParseError. Note the message itself misuses %d for what are string counts, but the semantic is a length mismatch.

Source

Thrown at pylib/cqlshlib/copyutil.py:2080

        def convert_list(val, ct=cql_type):
            return tuple(convert_mandatory(ct.subtypes[0], v) for v in split(val))

        def convert_set(val, ct=cql_type):
            return frozenset(convert_mandatory(ct.subtypes[0], v) for v in split(val))

        def convert_map(val, ct=cql_type):
            """
            See ImmutableDict above for a discussion of why a special object is needed here.
            """
            split_format_str = '{%s}'
            sep = ':'
            return ImmutableDict(frozenset((convert_mandatory(ct.subtypes[0], v[0]), convert(ct.subtypes[1], v[1]))
                                 for v in [split(split_format_str % vv, sep=sep) for vv in split(val)]))

        def convert_vector(val, ct=cql_type):
            string_coordinates = split(val)
            if len(string_coordinates) != ct.vector_size:
                raise ParseError("The length of given vector value '%d' is not equal to the vector size from the type definition '%d'" % (len(string_coordinates), ct.vector_size))
            return [convert_mandatory(ct.subtype, v) for v in string_coordinates]

        def convert_user_type(val, ct=cql_type):
            """
            A user type is a dictionary except that we must convert each key into
            an attribute, so we are using named tuples. It must also be hashable,
            so we cannot use dictionaries. Maybe there is a way to instantiate ct
            directly but I could not work it out.
            Also note that it is possible that the subfield names in the csv are in the
            wrong order, so we must sort them according to ct.fieldnames, see CASSANDRA-12959.
            """
            split_format_str = '{%s}'
            sep = ':'
            vals = [v for v in [split(split_format_str % vv, sep=sep) for vv in split(val)]]
            dict_vals = dict((unprotect(v[0]), v[1]) for v in vals)
            sorted_converted_vals = [(n, convert(t, dict_vals[n]) if n in dict_vals else self.get_null_val())
                                     for n, t in zip(ct.fieldnames, ct.subtypes)]
            ret_type = namedtuple(ct.typename, [v[0] for v in sorted_converted_vals])

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Supply exactly the declared number of coordinates, e.g. [1.0, 2.0, 3.0] for vector<float,3>
  2. Check the table schema (DESCRIBE) to confirm the vector size
  3. Verify quoting/delimiters so the value splits into the right number of elements

Example fix

// before (vector<float,3>)
1,"[1.0,2.0]"
// after
1,"[1.0,2.0,3.0]"
Defensive patterns

Strategy: validation

Validate before calling

vec = parse_bracketed(val)
if len(vec) != declared_vector_size:
    raise ValueError(f"need {declared_vector_size} coords, got {len(vec)}")

Try / catch

try:
    run_copy_from(...)
except ParseError as e:
    print(f"Vector length mismatch: {e}")  # pad/trim coordinates

Prevention

When it happens

Trigger: COPY FROM a CSV cell for a vector<float, 3> column that contains 2 or 4 elements, e.g. '[1.0, 2.0]' for a 3-dimensional vector, often from a delimiter mismatch producing wrong splits.

Common situations: Schema changed the vector dimension after the CSV was exported, wrong bracket/delimiter format causing the splitter to miscount, hand-written rows missing a coordinate.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/a970b335b840d173. Report an issue: GitHub.