Schema "text_key" issue, redundant property

[pashva]

The init function accepts text_key as input, yet it is not being passed to the _default_schema function. Consequently, a property named "text" is hardcoded within the property.

Can I create a PR fixing this?

[hsm207]

@pashva thanks for your interest to contribute!

I noticed this too and wanted to get feedback from the community. Here's how I see it:

There's a lot of things you can customise in a weaviate schema. How do we decide which one is worth exposing to langchain users? If we expose all possible settings, then were are just building another abstraction on top of the weaviate client.

If we expose only some settings, then I feel it is an inconvenience for the user since there's now different settings have different ways of tweaking.

A solution I've been considering is to tell users this is what you get with the default schema. If you want something different, then use the weaviate client to create your desired schema, and when you use langchain, remember to specify the index name and which property is the text_key.

What do you think of this?

[pashva]

Yes it makes sense completely but then asking text_key as an input kind of confuses me personally as i believe if i specify the text key then my end schema created should have nothing but that text_key.

[hsm207]

asking text_key as an input kind of confuses me personally as i believe if i specify the text key then my end schema created should have nothing but that text_key

I've noted the confusion.

I believe this can be solved with proper documentation in the class' docstring and tutorials/user guides.

What do you think?

and zooming in on this point specfically:

my end schema created should have nothing but that text_key

fyi, by default, weaviate has autoschema enabled, so when you upload a langchain Document with any metadata, that property will be automatically added. What do you think of this behavior? Is this desirable and expected?