[ENH] Export types from chroma crate

[rescrv]

Description of changes

For ergonomics, export every type referenced by the chroma::collection crate from chroma::types::*.

Test plan

CI

Migration plan

N/A

Observability plan

N/A

Documentation Changes

N/A

[propel-code-bot]

Export Additional Types from chroma Crate via types.rs

This pull request enhances the ergonomics of the chroma crate by expanding the set of types re-exported through chroma::types::*. All types referenced by the chroma::collection crate are now made accessible from this module. This change involves a single update to the rust/chroma/src/types.rs file, making these types readily available for downstream use.

Key Changes

• Added a pub use chroma_types::{...} block in rust/chroma/src/types.rs to re-export all collection-related types, including but not limited to SearchPayload, AddCollectionRecordsRequest, Collection, QueryRequest, UpsertCollectionRecordsResponse, and related types.

Affected Areas

• rust/chroma/src/types.rs (exports for type re-exports from chroma_types)

This summary was automatically generated by @propel-code-bot

[github-actions]

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)

[propel-code-bot]

[BestPractice]

For improved readability and easier maintenance, consider formatting this long list of re-exported types with one item per line. This follows the official Rust Style Guide which states: "If an import does require multiple lines, then break after the opening brace and before the closing brace, use a trailing comma, and block indent the names." This formatting convention helps in producing cleaner diffs when items are added or removed in the future and makes the code more maintainable.

Suggested Change

Suggested change

	pub use chroma_types::{
	plan::SearchPayload, AddCollectionRecordsRequest, AddCollectionRecordsResponse, Collection,
	DeleteCollectionRecordsRequest, DeleteCollectionRecordsResponse, ForkCollectionRequest,
	GetRequest, GetResponse, IncludeList, InternalSchema, Metadata, QueryRequest, QueryResponse,
	SearchRequest, SearchResponse, UpdateCollectionRecordsRequest, UpdateCollectionRecordsResponse,
	UpdateMetadata, UpsertCollectionRecordsRequest, UpsertCollectionRecordsResponse, Where,
	};
	pub use chroma_types::{
	plan::SearchPayload,
	AddCollectionRecordsRequest,
	AddCollectionRecordsResponse,
	Collection,
	DeleteCollectionRecordsRequest,
	DeleteCollectionRecordsResponse,
	ForkCollectionRequest,
	GetRequest,
	GetResponse,
	IncludeList,
	InternalSchema,
	Metadata,
	QueryRequest,
	QueryResponse,
	SearchRequest,
	SearchResponse,
	UpdateCollectionRecordsRequest,
	UpdateCollectionRecordsResponse,
	UpdateMetadata,
	UpsertCollectionRecordsRequest,
	UpsertCollectionRecordsResponse,
	Where,
	};

⚡ 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**]

For improved readability and easier maintenance, consider formatting this long list of re-exported types with one item per line. This follows the official Rust Style Guide which states: "If an import does require multiple lines, then break after the opening brace and before the closing brace, use a trailing comma, and block indent the names." This formatting convention helps in producing cleaner diffs when items are added or removed in the future and makes the code more maintainable.

<details>
<summary>Suggested Change</summary>

```suggestion
pub use chroma_types::{
    plan::SearchPayload,
    AddCollectionRecordsRequest,
    AddCollectionRecordsResponse,
    Collection,
    DeleteCollectionRecordsRequest,
    DeleteCollectionRecordsResponse,
    ForkCollectionRequest,
    GetRequest,
    GetResponse,
    IncludeList,
    InternalSchema,
    Metadata,
    QueryRequest,
    QueryResponse,
    SearchRequest,
    SearchResponse,
    UpdateCollectionRecordsRequest,
    UpdateCollectionRecordsResponse,
    UpdateMetadata,
    UpsertCollectionRecordsRequest,
    UpsertCollectionRecordsResponse,
    Where,
};
```

⚡ **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.

</details>

File: rust/chroma/src/types.rs
Line: 9

[rescrv]

If Rust people wanted me to do better, they'd not have encoded bad behavior in rustfmt.

[codetheweb]

should we just pub use chroma_types::*? seems easy to forget to add a type here when modifying the client

[rescrv]

I'd rather not. chroma_types::* is everything, which is too much to export. I'd rather miss something and fix it than have people depend on our internals.