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

Disk Cache does not persist between runs #190

Closed
BaxHugh opened this issue Apr 2, 2024 · 1 comment · Fixed by #194
Closed

Disk Cache does not persist between runs #190

BaxHugh opened this issue Apr 2, 2024 · 1 comment · Fixed by #194

Comments

@BaxHugh
Copy link
Contributor

BaxHugh commented Apr 2, 2024

From the discussion in #20, it looks like the expected behaviour of io_cached with disk=true is that the cache should persist between runs. I'm not sure if persistence functionality has been implemented yet, but is just bugged, or if it just hasn't been implemented yet, but I don't see persistence behaviour.

Info:

Version 0.49.2 (latest)
Also tested with current main

To reproduce

With the example code, run cargo run more than once.
(additionaly adding a time argument to the io_cached macro gives the same behaviour)

Expected:
$: cargo run
Calculating...
4
4
$: cargo run
4
4
Actual:
$: cargo run
Calculating...
4
4
$: cargo run
Calculating...
4
4
Example code
use cached::proc_macro::io_cached;

#[derive(Debug, thiserror::Error)]
pub enum ExampleError {
    #[error("Disk error: {0}")]
    DiskError(String),
}

#[io_cached(
    map_error = r##"|e| ExampleError::DiskError(format!("{:?}", e))"##,
    disk = true
)]
fn times_2(input: i32) -> Result<i32, ExampleError> {
    println!("Calculating..."); // show we're not hitting the cache
    Ok(input * 2)
}

fn main() {
    println!("{}", times_2(2).unwrap()); // this could initialize the cache if it's not already
    println!("{}", times_2(2).unwrap()); // get immediate result from cache
}

Suggestions:

  • Document the lack of persistence.
  • Implement persistence.
  • Add tests for persistence (this would be slightly more involved than a usual lib test as would require spawning separate sub-processes)
@BaxHugh
Copy link
Contributor Author

BaxHugh commented Apr 2, 2024

Ok, I've had a dig, and we're using sled. sled has it's own rules about when it synchronises to disk I think, I don't know if it does it automatically on some timescale, but sled's Db::flush() synchronises to disk.
One solution then would be to call connection.flush() after setting a cache value.

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 a pull request may close this issue.

1 participant