-
Notifications
You must be signed in to change notification settings - Fork 86
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
Cache TTL should be a Duration instead of Time #100
Conversation
@@ -54,11 +54,11 @@ class MemcacheStore(val client: Client, ttl: Time, flag: Int) extends Store[Stri | |||
.mapValues { _.flatten } | |||
} | |||
|
|||
protected def set(k: String, v: ChannelBuffer) = client.set(k, flag, ttl, v) | |||
protected def set(k: String, v: ChannelBuffer) = client.set(k, flag, ttl.fromNow, v) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh boy, this is a huge bug if that's the real meaning of the API. Can you link me to a doc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to be sure about this before merge.
I will ping you in IM as I need to share some internal links. |
Many of the redis interfaces ( initially based on the memcache interface ) also use time I now see how this can be a problem for long lived stores. |
@softprops yep. With current interface we'll have to instantiate a Store instance on every attempt to do set. |
Chatted with the owner of finagle-memcached. Seems like finagle-memcached allows two types of semantics when setting cache TTL and the existing Storehaus code is correct. I'll close this pull request. |
I do still prefer the Duration vs Time switch! I think it makes more sense and is more in line with the rest of the code we're writing. |
I agree with @sritchie |
+1 |
Looks like this req needs a merge. @johnynek, can you take a look at the new TTL trait? |
Not sure is if this is worth nitpicking over, but does WithPutTTL makes more sense? TTL is acronym, like URL. |
I prefer the Ttl style because it is slightly easier to type. There does not seem to be a standard: http://stackoverflow.com/questions/5704737/java-naming-convention-with-acronyms |
* Trait for building mutable store with TTL. | ||
*/ | ||
trait WithPutTtl[K, V, S <: Store[K, V]] { | ||
def withTtl(ttl: Duration): S |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might be safer to make it withPutTtl
in case there are multiple TTLs (note the trait has the Put).
Looks good te me. Let's get a link to the docs about the question Sam asked (ttl.fromNow). |
Renamed to withPutTtl and also added documentation links to Memcached and Redis about setting expiration time. |
@ximyu, can you merge with Develop? Then let's get this in. |
ping! |
Oops, I'll get this merged this week :) |
@ximyu that'd be awesome! Can't wait. |
ping!!!!!!!!!!!!!!!! |
…evelop Conflicts: storehaus-redis/src/main/scala/com/twitter/storehaus/redis/RedisLongStore.scala storehaus-redis/src/main/scala/com/twitter/storehaus/redis/RedisStringStore.scala
Cache TTL should be a Duration instead of Time
No description provided.