refactor: use get_nerghbors in storage instead of building adj_list

[ChenZiHong-Gavin]

This PR refactors the graph partitioning mechanism by shifting the responsibility of neighbor retrieval from individual partitioner algorithms to the core graph storage layer.

[gemini-code-assist]

Summary of Changes

Hello @ChenZiHong-Gavin, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly refactors the graph partitioning mechanism by shifting the responsibility of neighbor retrieval from individual partitioner algorithms to the core graph storage layer. This change centralizes the logic for fetching node neighbors, reducing code duplication across different partitioners and allowing for storage-specific optimizations. The result is a cleaner, more modular, and potentially more performant architecture for graph operations.

Highlights

• Centralized Neighbor Retrieval: An abstract get_neighbors method has been introduced in base_storage.py, requiring all concrete storage implementations (like KuzuDB and NetworkX) to provide their own efficient way of retrieving a node's neighbors.
• Removed Redundant Adjacency List Construction: The _build_adjacency_list static method, previously responsible for creating adjacency lists, has been removed from base_partitioner.py as its functionality is now handled by the storage layer.
• Refactored Partitioner Implementations: The BFS, DFS, and ECE partitioners have been updated to directly utilize the new get_neighbors method from the graph storage, eliminating the need for them to build and maintain their own adjacency lists.
• Storage Proxy Updates: The GraphStorage and RayGraphStorage classes in init_storage.py now include proxy methods for get_neighbors, ensuring that calls are correctly delegated to the underlying graph storage.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request is a good refactoring that centralizes neighbor retrieval logic into the storage layer by introducing a get_neighbors method. This simplifies the partitioner implementations by removing the need for them to build their own adjacency lists. I've identified a critical issue in the KuzuStorage implementation of get_neighbors that would lead to incorrect partitioning, as well as a couple of medium-severity issues related to code correctness and best practices. My review includes specific suggestions to address these points. Overall, this is a valuable change once the feedback is incorporated.

[gemini-code-assist]

Printing to standard output in a library function is generally discouraged. It can clutter the output of the application using the library and may not be desirable in all contexts (e.g., when running in production or as part of a larger pipeline). It's better to either use a proper logging framework or simply return an empty list, letting the caller decide how to handle the 'node not found' case. The empty list sufficiently signals that there are no neighbors, which is true if the node doesn't exist.

Suggested change

	print(f"Node {node_id} not found in the graph.")
	return []
	return []