[Feature Request]: Support for Integer Document and Node ids

[AmeanAsad]

Feature Description

Requesting to add support for using integer ids for Documents and BaseNode:

• Document
• BaseNode

Reason

The document and basenode ids are simply only allowed to be string values so setting them to something else breaks the static type checks.

Value of Feature

The current behaviour forces users to use a string primary key for their vector store if they want to populate the vector store via llamaindex. It would be better to support integer primary keys for the following reason:

• Integer primary keys are usually faster to index and query. This gives flexibility for the user to pick their own vec store based on their performance needs.
• the vector store embedding rows key might reference primary keys from other tables that use integer format.

[logan-markewich]

It's a little late to change such a core type I think -- a lot of integrations are built on relying this to be a string (some vector dbs even enforce it being a uuid, like qdrant)

We could force casting them to strings if you pass in an int

[logan-markewich]

Of course, any vector db could also cast it as an int for storage

[AmeanAsad]

thanks for getting back so quickly!

It's a little late to change such a core type I think -- a lot of integrations are built on relying this to be a string (some vector dbs even enforce it being a uuid, like qdrant)

just so I understand correctly, the implication here is that if we add support for integers such that those ids can be either string or integers, if a user opts in for using integers then other things might break since a lot of llama-index machinery is built relying on document ids being strings.

We could force casting them to strings if you pass in an int

I think probably let the user cast it to strings themselves, that way they are fully aware that they have to use string ids. Casting it in the Document or Node let users a falsely assume that they can operate with integer ids and have things break downstream when data is being inserted, etc.

Of course, any vector db could also cast it as an int for storage

That is correct. My pain point here is that the db client im using (supabase) doesn't support casting, so i'll have to manually write those upsert queries myself to add in the casting logic.

does seem odd that the Document and Node types never supported integer ids though as it is such a ubiquitous primary key type.

[logan-markewich]

Sounds like you could write your own vector store class, or override the add method of the existing supabase vector store, to get things to work how you need

[AmeanAsad]

Yeah agreed here that this could be resolved at the vector store level. Thanks for the help and clarification, closing this.