LBRYCommunity/ccache
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
ccache/bucket_test.go

85 lines
2 KiB
Go
Raw Normal View History

initial tests
2013-10-19 14:36:33 +02:00
package ccache
import (
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
. "github.com/karlseguin/expect"
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
"testing"
"time"
initial tests
2013-10-19 14:36:33 +02:00
)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
type BucketTests struct {
}
func Tests_Bucket(t *testing.T) {
Expectify(new(BucketTests), t)
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) GetMissFromBucket() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
bucket := testBucket()
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(bucket.get("invalid")).To.Equal(nil)
initial tests
2013-10-19 14:36:33 +02:00
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) GetHitFromBucket() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
bucket := testBucket()
item := bucket.get("power")
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
assertValue(item, "9000")
initial tests
2013-10-19 14:36:33 +02:00
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) DeleteItemFromBucket() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
bucket := testBucket()
bucket.delete("power")
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(bucket.get("power")).To.Equal(nil)
initial tests
2013-10-19 14:36:33 +02:00
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) SetsANewBucketItem() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
bucket := testBucket()
item, new := bucket.set("spice", TestValue("flow"), time.Minute)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
assertValue(item, "flow")
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
item = bucket.get("spice")
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
assertValue(item, "flow")
Expect(new).To.Equal(true)
initial tests
2013-10-19 14:36:33 +02:00
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) SetsAnExistingItem() {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
bucket := testBucket()
item, new := bucket.set("power", TestValue("9002"), time.Minute)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
assertValue(item, "9002")
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
item = bucket.get("power")
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
assertValue(item, "9002")
Expect(new).To.Equal(false)
initial tests
2013-10-19 14:36:33 +02:00
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) ReplaceDoesNothingIfKeyDoesNotExist() {
added replace method
2014-11-13 16:20:12 +01:00
bucket := testBucket()
better tests
2014-11-13 16:26:05 +01:00
Expect(bucket.replace("power", TestValue("9002"))).To.Equal(false)
Expect(bucket.get("power")).To.Equal(nil)
added replace method
2014-11-13 16:20:12 +01:00
}
blank identifier for tests
2014-11-14 01:41:22 +01:00
func (_ *BucketTests) ReplaceReplacesThevalue() {
added replace method
2014-11-13 16:20:12 +01:00
bucket := testBucket()
better tests
2014-11-13 16:26:05 +01:00
item, _ := bucket.set("power", TestValue("9002"), time.Minute)
Expect(bucket.replace("power", TestValue("9004"))).To.Equal(true)
Expect(item.Value().(string)).To.Equal("9004")
Expect(bucket.get("power").Value().(string)).To.Equal("9004")
//not sure how to test that the TTL hasn't changed sort of a sleep..
added replace method
2014-11-13 16:20:12 +01:00
}
Added documentation. Bucket and LayeredBucket are no longer exported.
2014-11-14 01:56:24 +01:00
func testBucket() *bucket {
b := &bucket{lookup: make(map[string]*Item)}
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
b.lookup["power"] = &Item{
key: "power",
value: TestValue("9000"),
}
return b
initial tests
2013-10-19 14:36:33 +02:00
}
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
func assertValue(item *Item, expected string) {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
value := item.value.(TestValue)
switched from gspec -> expect
2014-10-25 02:46:18 +02:00
Expect(value).To.Equal(TestValue(expected))
initial tests
2013-10-19 14:36:33 +02:00
}
clean up TestValue
2013-10-19 14:45:30 +02:00
type TestValue string
initial tests
2013-10-19 14:36:33 +02:00
clean up TestValue
2013-10-19 14:45:30 +02:00
func (v TestValue) Expires() time.Time {
The cache can now do reference counting so that the LRU algorithm is aware of long-lived objects and won't clean them up. Oftentimes, the value returned from a cache hit is short-lived. As a silly example: func GetUser(http.responseWrite) { user := cache.Get("user:1") response.Write(serialize(user)) } It's fine if the cache's GC cleans up "user:1" while the user variable has a reference to the object..the cache's reference is removed and the real GC will clean it up at some point after the user variable falls out of scope. However, what if user is long-lived? Possibly stored as a reference to another cached object? Normally (without this commit) the next time you call cache.Get("user:1"), you'll get a miss and will need to refetch the object; even though the original user object is still somewhere in memory - you just lost your reference to it from the cache. By enabling the Track() configuration flag, and calling TrackingGet() (instead of Get), the cache will track that the object is in-use and won't GC it (even if there's great memory pressure (what's the point? something else is holding on to it anyways). Calling item.Release() will decrement the number of references. When the count is 0, the item can be pruned from the cache. The returned value is a TrackedItem which exposes: - Value() interface{} (to get the actual cached value) - Release() to release the item back in the cache
2014-02-28 13:10:42 +01:00
return time.Now()
initial tests
2013-10-19 14:36:33 +02:00
}
Reference in a new issue Copy permalink