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

[ENH] Metadata indices #1724

Merged
merged 22 commits into from
Feb 22, 2024
Merged

[ENH] Metadata indices #1724

merged 22 commits into from
Feb 22, 2024

Conversation

beggers
Copy link
Contributor

@beggers beggers commented Feb 15, 2024

Description of changes

Summarize the changes made by this PR.

  • New functionality
    • Blockfile-based metadata indexing. Currently uses a HashmapBlockfile, easy to change.

Test plan

How are these changes tested?

  • Tests pass locally with pytest for python, yarn test for js

Documentation Changes

Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?

Copy link

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

  • Can you think of any use case in which the code does not behave as intended? Have they been tested?
  • Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
  • If appropriate, are there adequate property based tests?
  • If appropriate, are there adequate unit tests?
  • Should any logging, debugging, tracing information be added or removed?
  • Are error messages user-friendly?
  • Have all documentation changes needed been made?
  • Have all non-obvious changes been commented?

System Compatibility

  • Are there any potential impacts on other parts of the system or backward compatibility?
  • Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

  • Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)

@beggers beggers requested a review from HammadB February 15, 2024 22:54
@beggers beggers changed the title String metadata in-memory reference implementation [ENH] Metadata indices Feb 21, 2024
@beggers
Copy link
Contributor Author

beggers commented Feb 21, 2024

Reviewers: I think there are more clone()s than needed -- I'll do a pass to try to remove some but please be on extra lookout for this.

@@ -17,6 +17,7 @@ fn main() -> Result<(), Box<dyn std::error::Error>> {
.flag("-DHAVE_CXX0X")
.flag("-fpic")
.flag("-ftree-vectorize")
// .flag("-w") // Uncomment to suppress c++ warnings.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems worth having. Happy to remove.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's leave it out for now - I prefer the warnings cause pain until we have the correct solution to deal with them!

@@ -1,2 +1,5 @@
mod positional_posting_list_value;
mod types;

pub use positional_posting_list_value::*;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is the correct way to export these but please correct if not.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thats fine if you want to rexeport - you can also do pub mod positional_posting_list_value which exports the whole module under blockstore::positional_posting_list_value

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems like the correct way to export this but I still want to re-export types at top-level I think. Regardless, exporting positional_posting_list_value should be done in the PR that needs it, so deleting from here (Graphite learning curve :D)

use std::hash::{Hash, Hasher};

#[derive(Debug, Error)]
pub(crate) enum BlockfileError {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

}
for (key, rbm) in &self.uncommitted_rbms {
// TODO we shouldn't clone.
self.blockfile.set(key.clone(), Value::RoaringBitmapValue(rbm.clone()));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly what I wanted, ty

Copy link
Collaborator

@HammadB HammadB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

Copy link
Contributor Author

@beggers beggers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ty! Merging once CI passes.

}
for (key, rbm) in &self.uncommitted_rbms {
// TODO we shouldn't clone.
self.blockfile.set(key.clone(), Value::RoaringBitmapValue(rbm.clone()));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly what I wanted, ty

@@ -1,2 +1,5 @@
mod positional_posting_list_value;
mod types;

pub use positional_posting_list_value::*;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems like the correct way to export this but I still want to re-export types at top-level I think. Regardless, exporting positional_posting_list_value should be done in the PR that needs it, so deleting from here (Graphite learning curve :D)

@beggers beggers merged commit 2e93302 into main Feb 22, 2024
115 checks passed
atroyn pushed a commit to csbasil/chroma that referenced this pull request Apr 3, 2024
## Description of changes

*Summarize the changes made by this PR.*
 - New functionality
- Blockfile-based metadata indexing. Currently uses a HashmapBlockfile,
easy to change.

## Test plan
*How are these changes tested?*

- [x] Tests pass locally with `pytest` for python, `yarn test` for js

## Documentation Changes
*Are all docstrings for user-facing APIs updated if required? Do we need
to make documentation changes in the [docs
repository](https://github.com/chroma-core/docs)?*

---------

Co-authored-by: hammadb <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants