[Refactor] Remove data loader to simplify api #33
Conversation
haochengxia
commented
Aug 5, 2025
- Remove data loader (make it internal) to simplify api
- Add safety check
There was a problem hiding this comment.
Summary of Changes
Hello @haochengxia, I'm Gemini Code Assist1! 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!
I've implemented a significant refactoring to simplify the libcachesim API by making the data loading mechanism internal. Previously, users had to explicitly use a DataLoader class to fetch S3 traces. Now, the TraceReader can directly accept S3 URIs, handling the download, caching, and validation seamlessly behind the scenes. This change streamlines the user experience, making it easier to get started with cache simulations, while also adding robust safety checks for S3 interactions and local file handling.
Highlights
- API Simplification: I have refactored the
DataLoaderclass, making it an internal component (_DataLoader) and removing it from the public API. This simplifies the top-levellibcachesimmodule by reducing the number of exposed classes. - Direct S3 Trace Loading: The
TraceReadernow directly supports S3 URIs (e.g.,s3://bucket/key). When an S3 URI is provided,TraceReaderinternally handles the download and caching of the trace file, eliminating the need for users to explicitly manage data loading. - Enhanced Data Loading Safety: I've introduced comprehensive safety checks for S3 URIs and object keys within the new internal data loader. This includes validation for bucket names, prevention of path traversal, checks for invalid characters, and ensuring sufficient disk space before downloading large files.
- Metric Renaming: The
obj_miss_ratiometric, previously used in examples and documentation, has been consistently renamed toreq_miss_ratioto better reflect that it represents the miss ratio based on individual requests.
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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| 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 issue 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 or fill out our survey to provide feedback.
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
-
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. ↩
There was a problem hiding this comment.
Code Review
This pull request does a good job of simplifying the API by making the DataLoader internal and allowing TraceReader to accept S3 URIs directly. The new _s3_cache.py module includes robust validation and safety checks, such as checking for available disk space before downloading.
However, there are a few issues to address:
- The example code in
README.md,docs/src/en/getting_started/quickstart.md, andexamples/basic_usage.pyhas a bug where the cache is not re-initialized before a second call toprocess_trace, which will lead to incorrect results and user confusion. - The documentation in
docs/src/en/getting_started/quickstart.mdfor trace analysis has not been updated and still refers to the now-internalDataLoaderAPI. - There's an unused import in the new
_s3_cache.pyfile. - There is some redundant validation logic in
trace_reader.pythat should be centralized in_s3_cache.py.
I've added specific comments for these points. Once these are addressed, the PR will be in great shape.
| # Step 3.1: Further process the first 1000 requests again | ||
| req_miss_ratio, byte_miss_ratio = cache.process_trace(reader, start_req=0, max_req=1000) | ||
| print(f"Request miss ratio: {req_miss_ratio:.4f}, Byte miss ratio: {byte_miss_ratio:.4f}") |
There was a problem hiding this comment.
The example is missing the re-initialization of the cache object before the second process_trace call. The process_trace method is stateful and modifies the cache. To correctly process the "first 1000 requests again" from a clean state, the cache should be re-created.
| # Step 3.1: Further process the first 1000 requests again | |
| req_miss_ratio, byte_miss_ratio = cache.process_trace(reader, start_req=0, max_req=1000) | |
| print(f"Request miss ratio: {req_miss_ratio:.4f}, Byte miss ratio: {byte_miss_ratio:.4f}") | |
| # Step 3.1: Further process the first 1000 requests again | |
| cache = lcs.S3FIFO( | |
| cache_size=1024 * 1024, | |
| # Cache specific parameters | |
| small_size_ratio=0.2, | |
| ghost_size_ratio=0.8, | |
| move_to_main_threshold=2, | |
| ) | |
| req_miss_ratio, byte_miss_ratio = cache.process_trace(reader, start_req=0, max_req=1000) | |
| print(f"Request miss ratio: {req_miss_ratio:.4f}, Byte miss ratio: {byte_miss_ratio:.4f}") |
| # Check for path traversal in the key part only | ||
| if ".." in key: | ||
| raise ValueError(f"S3 key contains path traversal patterns: {key}") | ||
|
|
||
| # Check for double slashes in the key part (after s3://) | ||
| if "//" in key: | ||
| raise ValueError(f"S3 key contains double slashes: {key}") |
There was a problem hiding this comment.
There is some redundant validation logic in _validate_s3_uri. The checks for path traversal (..) and double slashes (//) in the S3 key are (or should be) handled within the _DataLoader in _s3_cache.py. Duplicating this logic can lead to inconsistencies and maintenance overhead. The validation of the key should be the responsibility of the _DataLoader, and this method should focus only on parsing the URI.