Enable multiple node types for single relationship type table (hashtag2866)

[vikramsubramanian]

Excited about the possibilities of Kuzu, thanks for your great work on this project! This issue may overlap with hashtag1644 (perhaps the "Data Manipulation" section?), but it felt important enough to be specific here.

I noticed that each REL table in Kuzu may only contain one node type for the FROM and TO specification ([docs]( This may be limiting in scenarios where a graph dataset includes relationships that involve multiple node types. I wanted to raise this issue to help explore and understand the capabilities within Kuzu to perhaps eventually use multiple node types in the FROM or TO specification for REL tables. Please don't hesitate to mention whether this is considered "out of scope" for the Kuzu roadmap more broadly.

I'm also interested in potential workarounds to this in the meantime, understanding it could take time for this feature to arrive if it's intended to be developed. Two that come to mind are:

• Generalize all NODE types to a single table of type / name nodes (enabling relationship tables to reference all nodes no matter their name).
• Create specific REL tables for each kind of relationship by distinct FROM, TO node pairs (specifying this within the REL table name somehow, i.e. rel_nodeone_to_nodetwo).

Both of these may come with ramifications that over-loosen or constrain the data, and I imagine there could be a performance element to these. Appreciate any input you may have on this topic! Thanks again.

)

[mayil-ai[bot]]

Summary: Request to enable multiple node types for a single relationship type table in Kuzu.

Possible Solution

To address the feature request for supporting multiple node types in the FROM or TO specification for REL tables in Kùzu, you can implement the following solution:

• Modify the REL table schema to include type information for nodes. This can be done by adding from_node_type and to_node_type columns to the REL table, as shown in the hypothetical REL table structure.

  ALTER TABLE rel_example
  ADD COLUMN from_node_type VARCHAR,
  ADD COLUMN to_node_type VARCHAR;

• Update the foreign key constraints to remove the restriction that from_node_id and to_node_id must reference the same node table. Instead, use triggers or application logic to ensure referential integrity.

• Modify the data manipulation methods to handle the new from_node_type and to_node_type columns. This includes updates to insertion, deletion, and query operations to consider the type of the nodes.

• Update the application code to support the new schema changes. This may involve changes to the C++ codebase, particularly in files related to schema management (e.g., src/catalog/table_schema.cpp, src/catalog/rel_table_schema.cpp) and query processing (e.g., src/processor/operator/scan/scan_multi_rel_tables.cpp).

• Ensure that the new schema design does not adversely affect query performance. This may require optimizing indexes and query plans to account for the additional type columns.

• Update the documentation to reflect the new feature and provide examples of how to define and interact with REL tables that support multiple node types.

• Consider the impact on existing APIs and client libraries (e.g., Rust API, Java API, Node.js API) and update them as necessary to accommodate the new feature.

• Run comprehensive tests to ensure that the new feature works as expected and does not introduce regressions.

• Communicate the changes to the users and update any related issues (e.g., hashtag1644) to reflect the progress on the feature request.

Code snippets to check

• src/catalog/table_schema.cpp

  This file likely contains the schema definitions for tables, which would need to be updated to allow multiple node types for a single relationship type.

• src/processor/operator/scan/scan_multi_rel_tables.cpp

  This file seems to be related to scanning multiple relationship tables, which could be relevant if the feature to enable multiple node types for a single relationship type is implemented.

• tools/nodejs_api/README.md

  The example usage shows how to create node and relationship tables. This documentation might need to be updated to reflect the new capability of having multiple node types for a single relationship type.