We currently pick the store type of a property based on its CLR type. While this works well enough for most cases, there are some cases where the same CLR type can be mapped to multiple store types:
- On SQL Server, string can be mapped to
nvarchar(4000) (limited length) or to nvarchar(max) (cannot be indexed). See #10975.
- string can also be mapped to json, xml, and other text types in the various relational databases.
- On PostgreSQL, DateTime can be mapped to
timestamp with time zone (UTC) or timestamp without time zone (unknown/unspecified/local timezone). On SQL Server, it can be mapped to datetime or datetime2.
We could make this a provider-specific annotation (#10359). Or, if basically all databases allow the store type to be specified via a simple string, we can simply add a StoreType string property directly to VectorStoreRecordProperty.
I don't see this as urgent for the Build release.
We currently pick the store type of a property based on its CLR type. While this works well enough for most cases, there are some cases where the same CLR type can be mapped to multiple store types:
nvarchar(4000)(limited length) or tonvarchar(max)(cannot be indexed). See #10975.timestamp with time zone(UTC) ortimestamp without time zone(unknown/unspecified/local timezone). On SQL Server, it can be mapped todatetimeordatetime2.We could make this a provider-specific annotation (#10359). Or, if basically all databases allow the store type to be specified via a simple string, we can simply add a StoreType string property directly to VectorStoreRecordProperty.
I don't see this as urgent for the Build release.