Xuanwo commented on code in PR #5906:
URL: https://github.com/apache/opendal/pull/5906#discussion_r2045911831
##########
core/src/layers/foyer.rs:
##########
@@ -0,0 +1,191 @@
+use crate::raw::*;
+use crate::*;
+use chrono::{DateTime, Utc};
+use foyer::{Code, CodeError, HybridCache};
+use serde::{Deserialize, Serialize};
+use std::sync::Arc;
+
+pub struct FoyerLayer {
+ cache: Arc<HybridCache<CacheKey, CacheValue>>,
+}
+
+impl FoyerLayer {
+ pub async fn new(cache: HybridCache<CacheKey, CacheValue>) -> Result<Self>
{
+ Ok(Self {
+ cache: Arc::new(cache),
+ })
+ }
+}
+
+impl<A: Access> Layer<A> for FoyerLayer {
+ type LayeredAccess = CacheAccessor<A>;
+
+ fn layer(&self, inner: A) -> Self::LayeredAccess {
+ CacheAccessor {
+ inner,
+ cache: Arc::clone(&self.cache),
+ }
+ }
+}
+
+#[derive(Debug, Clone, Hash, Eq, PartialEq, Serialize, Deserialize)]
+pub struct CacheKey {
Review Comment:
Hi, the `CacheKey` is generated solely from the input of each read
operation, specifically the `path` and `OpRead`. Therefore, rather than
creating a new struct and implementing `Serialize` for it, it’s much simpler to
implement a function like `build_cache_key(path, op)`.
Structuring the cache key doesn’t make sense to me, since there’s no need
for us to parse it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@opendal.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
