-
Notifications
You must be signed in to change notification settings - Fork 1.9k
[ENH]: Add models and migration for Create/Delete/Get Tasks (#5546) #5573
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
## Description of changes _Summarize the changes made by this PR._ - Improvements & Bug fixes - Added db models and SysDB routes to Create, Delete and Get Tasks. - New functionality - ^^^ `CreateTask` here does not kick off the requisite backfill task runs in this change. That is left as followup work. ## Test plan Tests have been added in `go/pkg/sysdb/metastore/db/dao/task_test.go`. - [ ] Tests pass locally with `pytest` for python, `yarn test` for js, `cargo test` for rust ## Migration plan _Are there any migrations, or any forwards/backwards compatibility changes needed in order to make sure this change deploys reliably?_ ## Observability plan _What is the plan to instrument and monitor this change?_ ## Documentation Changes _Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the_ [_docs section](https://github.com/chroma-core/chroma/tree/main/docs/docs.trychroma.com)?_
Reviewer ChecklistPlease leverage this checklist to ensure your code review is thorough before approving Testing, Bugs, Errors, Logs, Documentation
System Compatibility
Quality
|
Add Task, Operator Models and Migrations for Create/Delete/Get Tasks API with Cross-Language Constant Sync This PR introduces models, migrations, and service implementations for creating, retrieving, and deleting Key Changes• Added new Affected Areas• This summary was automatically generated by @propel-code-bot |
// Debug logging | ||
log.Info("Found task", zap.String("task_id", task.ID.String()), zap.String("name", task.Name), zap.String("input_collection_id", task.InputCollectionID), zap.String("output_collection_name", task.OutputCollectionName)) |
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.
[BestPractice]
The comment indicates this is for debug logging, but it's using log.Info
. To avoid potentially noisy logs in a production environment for a read operation, it would be more appropriate to use log.Debug
to align with the stated intent.
// Debug logging | |
log.Info("Found task", zap.String("task_id", task.ID.String()), zap.String("name", task.Name), zap.String("input_collection_id", task.InputCollectionID), zap.String("output_collection_name", task.OutputCollectionName)) | |
// Debug logging | |
log.Debug("Found task", zap.String("task_id", task.ID.String()), zap.String("name", task.Name), zap.String("input_collection_id", task.InputCollectionID), zap.String("output_collection_name", task.OutputCollectionName)) |
⚡ Committable suggestion
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
Context for Agents
[**BestPractice**]
The comment indicates this is for debug logging, but it's using `log.Info`. To avoid potentially noisy logs in a production environment for a read operation, it would be more appropriate to use `log.Debug` to align with the stated intent.
```suggestion
// Debug logging
log.Debug("Found task", zap.String("task_id", task.ID.String()), zap.String("name", task.Name), zap.String("input_collection_id", task.InputCollectionID), zap.String("output_collection_name", task.OutputCollectionName))
```
⚡ **Committable suggestion**
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation.
File: go/pkg/sysdb/coordinator/task.go
Line: 172
deleteCollection := &model.DeleteCollection{ | ||
ID: collectionUUID, | ||
TenantID: task.TenantID, | ||
DatabaseName: task.DatabaseID, |
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.
[BestPractice]
There appears to be a naming inconsistency here. You are assigning task.DatabaseID
to the DatabaseName
field of model.DeleteCollection
. This could be confusing for future readers, as it seems an ID is being stored in a field named for a name. If SoftDeleteCollection
indeed expects a database ID, consider renaming the field in model.DeleteCollection
to DatabaseID
for better clarity, if possible within the scope of this change.
Context for Agents
[**BestPractice**]
There appears to be a naming inconsistency here. You are assigning `task.DatabaseID` to the `DatabaseName` field of `model.DeleteCollection`. This could be confusing for future readers, as it seems an ID is being stored in a field named for a name. If `SoftDeleteCollection` indeed expects a database ID, consider renaming the field in `model.DeleteCollection` to `DatabaseID` for better clarity, if possible within the scope of this change.
File: go/pkg/sysdb/coordinator/task.go
Line: 216
Merge activity
|
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.
We could save the operator codegen and probably use protobuf enums, right?
DatabaseName: task.DatabaseID, | ||
} | ||
|
||
err = s.SoftDeleteCollection(ctx, deleteCollection) |
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.
Is there not a way to do this transactionally?
Description of changes
Summarize the changes made by this PR.
This is a redo of this change which inadvertently merge conflicted with another change when it landed. That change generated task operator constants in rust by moving the go operator constants file into each service and manually generating a corresponding rust file during each docker containers build phase. This would've required every new service to make sure to copy in this Go file during build even if it didn't otherwise need Go code.
This diff changes that by having a contributor manually generate said constants in rust using a supplied script to avoid the above logistics. There is a rust unit test to make sure the generated constants are in sync with what is prepopulated in the SysDB operators table.
Test plan
How are these changes tested?
pytest
for python,yarn test
for js,cargo test
for rustMigration plan
Are there any migrations, or any forwards/backwards compatibility changes needed in order to make sure this change deploys reliably?
Observability plan
What is the plan to instrument and monitor this change?
Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the _docs section?_