-
Notifications
You must be signed in to change notification settings - Fork 966
pass pydantic model to cognify #369
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
Conversation
WalkthroughThe changes in the pull request primarily involve updates to the Changes
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🔇 Additional comments (4)cognee/api/v1/cognify/cognify_v2.py (4)
The imports are well-organized, properly grouped, and the explicit line continuations improve readability. Line range hint The error handling implementation includes:
Implement batch processing or remove unused configuration. The task_config with batch_size parameter is still not being utilized in the extract_graph_from_data implementation. This could lead to memory issues when processing large datasets since all chunks are processed simultaneously. Consider either:
This applies to other tasks in the pipeline that have similar batch_size configurations. #!/bin/bash
# Check implementation of extract_graph_from_data for batch processing
ast-grep --pattern 'def extract_graph_from_data($$$)' -A 20
# Check other task implementations for batch processing
fd "tasks.*\.py$" --exec ast-grep --pattern 'batch_size' {}
The function signature changes are well-implemented with proper type hints and backward compatibility. However, let's verify that all callers are prepared for this change. Also applies to: 62-62 ✅ Verification successfulThe graph_model parameter change is safe and backward compatible All existing calls to Key findings from the codebase scan:
🏁 Scripts executedThe following scripts were executed for the analysis: Script: #!/bin/bash
# Search for direct calls to cognify or run_cognify_pipeline
rg "cognify\(|run_cognify_pipeline\(" -A 2
# Search for any test files that might need updating
fd "test.*cognify.*\.py$" --exec cat {}
Length of output: 4769 Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
cognee/api/v1/cognify/cognify_v2.py (2)
Line range hint
33-61: Update cognify function to handle graph_model parameterThe
cognifyfunction callsrun_cognify_pipelinebut doesn't pass thegraph_modelparameter. While this works due to the default value, consider exposing this parameter in thecognifyfunction signature for consistency and to allow users to specify custom models at the top level.-async def cognify(datasets: Union[str, list[str]] = None, user: User = None): +async def cognify( + datasets: Union[str, list[str]] = None, + user: User = None, + graph_model: BaseModel = KnowledgeGraph +): if user is None: user = await get_default_user() # ... for dataset in datasets: dataset_name = generate_dataset_name(dataset.name) if dataset_name in existing_datasets_map: - awaitables.append(run_cognify_pipeline(dataset, user)) + awaitables.append(run_cognify_pipeline(dataset, user, graph_model))
Line range hint
62-90: Consider documenting the graph_model parameter usageThis change introduces flexibility in graph model customization, which is a significant architectural enhancement. Consider:
- Adding docstring documentation for the
graph_modelparameter- Creating example custom models in the documentation
- Adding validation to ensure custom models have required fields/methods
This will help users understand how to properly implement and use custom graph models.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
cognee/api/v1/cognify/cognify_v2.py(3 hunks)
🔇 Additional comments (2)
cognee/api/v1/cognify/cognify_v2.py (2)
5-24: LGTM! Clean import organization
The imports are well-organized and the addition of BaseModel from pydantic supports the new type annotation.
62-62: Verify KnowledgeGraph model inheritance
Let's verify that KnowledgeGraph actually inherits from BaseModel to ensure type safety.
✅ Verification successful
KnowledgeGraph inheritance is correctly implemented
The verification confirms that KnowledgeGraph properly inherits from pydantic.BaseModel as shown in cognee/shared/data_models.py. The default value in the function signature is type-safe and correctly implemented.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for KnowledgeGraph class definition
ast-grep --pattern 'class KnowledgeGraph($$$BaseModel$$$):'
Length of output: 61
Script:
#!/bin/bash
# Let's try a broader search for KnowledgeGraph class definition and its imports
rg "class KnowledgeGraph" -A 5
# Also search for imports related to KnowledgeGraph and BaseModel
rg "from.*KnowledgeGraph|import.*KnowledgeGraph|from.*BaseModel|import.*BaseModel"
Length of output: 4190
9e24973 to
1c9fe01
Compare
Summary by CodeRabbit