Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Customizable Schema in LlamaIndex adaptor #4224

Open
aayan636 opened this issue Sep 9, 2024 · 0 comments
Open

Feature: Customizable Schema in LlamaIndex adaptor #4224

aayan636 opened this issue Sep 9, 2024 · 0 comments
Labels
feature New features or missing components of existing features

Comments

@aayan636
Copy link

aayan636 commented Sep 9, 2024

API

Python

Description

Currently if we use Kùzu's LlamaIndex KuzuPropertyGraphStore, we can only create an EntityNode which has the following allowed fields:

id STRING,
name STRING,
label STRING,
embedding DOUBLE[],
creation_date DATE,
last_modified_date DATE,
file_name STRING,
file_path STRING,
file_size INT64,
file_type STRING,
triplet_source_id STRING,
PRIMARY KEY(id)

This is too restrictive in the case where we are trying to manually insert nodes of different types having different fields. In case we add some node which has a differently named field, say contents, currently the LlamaIndex adaptor would allow the node to be added, but when we try to read back the same node, the new field contents would not show up.

By a quick inspecton of the code, I see two ways this could be done, (a) add a map parameter called properties inside EntityNodes which enable us to add any property (as long as the value is a string or a known type), or (b) allow the user to specify a custom schema for each node type.

@aayan636 aayan636 added the feature New features or missing components of existing features label Sep 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New features or missing components of existing features
Projects
None yet
Development

No branches or pull requests

1 participant