Every multi2vec_* factory accepts vectorize_collection_name and then drops it.
The text factories forward it. The multimodal ones take the same argument and never use it.
Nothing is logged either, so vectorize_collection_name=False has no effect and the collection name is still folded
into the vectors.
Reproduced on 4.22.0 with no server, since these factories are pure config builders. Asking every
factory for vectorize_collection_name=False and reading the config it emits:
text2vec_cohere vectorizeClassName=False honoured=True
text2vec_openai vectorizeClassName=False honoured=True
multi2vec_cohere vectorizeClassName=<absent> honoured=False
multi2vec_clip vectorizeClassName=<absent> honoured=False
multi2vec_voyageai vectorizeClassName=<absent> honoured=False
multi2vec_jinaai vectorizeClassName=<absent> honoured=False
The key is absent rather than wrong, so the server applies its own default. The docstring on these
same methods says that default is True.
While confirming it I found something that probably decides which fix you want. None of the eight
_Multi2Vec*Config classes has a vectorizeClassName field at all. Both text config classes do. So
the factories are accepting an argument the config model below them has no slot to hold, which
reads less like a missed line and more like the parameter was copied into signatures where it was
never supported.
That leaves a question I cannot answer from the client, and it changes the fix:
- If Weaviate does support it for multimodal, the field needs adding to those config classes and
passing through.
- If it does not, the parameter cannot ever work there, and the fix is to drop it from those
signatures or raise on it.
Happy to write either patch once you say which.
A note on severity. Not a security hole. It is just quiet: someone turning it off
for a multimodal collection gets vectors they did not ask for, and nothing tells them.
What I did not check. multi2vec_google needs location and project_id to build, so it is
covered by reading the code and not by the run above. I also did not check the async client or the
non-named-vector Configure.Vectorizer paths, which look like they have the same shape.
Every
multi2vec_*factory acceptsvectorize_collection_nameand then drops it.The text factories forward it. The multimodal ones take the same argument and never use it.
Nothing is logged either, so
vectorize_collection_name=Falsehas no effect and the collection name is still foldedinto the vectors.
Reproduced on 4.22.0 with no server, since these factories are pure config builders. Asking every
factory for
vectorize_collection_name=Falseand reading the config it emits:The key is absent rather than wrong, so the server applies its own default. The docstring on these
same methods says that default is
True.While confirming it I found something that probably decides which fix you want. None of the eight
_Multi2Vec*Configclasses has avectorizeClassNamefield at all. Both text config classes do. Sothe factories are accepting an argument the config model below them has no slot to hold, which
reads less like a missed line and more like the parameter was copied into signatures where it was
never supported.
That leaves a question I cannot answer from the client, and it changes the fix:
passing through.
signatures or raise on it.
Happy to write either patch once you say which.
A note on severity. Not a security hole. It is just quiet: someone turning it off
for a multimodal collection gets vectors they did not ask for, and nothing tells them.
What I did not check.
multi2vec_googleneedslocationandproject_idto build, so it iscovered by reading the code and not by the run above. I also did not check the async client or the
non-named-vector
Configure.Vectorizerpaths, which look like they have the same shape.