

Show HN: Concurrency-safe file-backed element store in Go - sebcat
https://github.com/sebcat/store

======
gophernaught
I like it, though I think it's likely to create a lot of garbage, what with
spawning a goroutine on each Put, I suppose that's probably not an issue for
most programs.

I find defer pretty expensive, I don't use them that liberally anymore, only
when they're really called for.

Bug: defer fh.Close() without error checking in put(). This can result in data
loss. It would also be nice to at least have the option of doing synchronous
stores, possibly even with an os.Sync().

~~~
sebcat
> I find defer pretty expensive, I don't use them that liberally anymore, only
> when they're really called for.

I use defer a lot so I decided to test your statement, and you were right. The
testcase is not representative of the functionality in
github.com/sebcat/store. here it is:
[https://pastie.se/e4352d50](https://pastie.se/e4352d50)

BenchmarkNoDefer 10000000 177 ns/op

BenchmarkDefer 2000000 633 ns/op

ok foo 3.874s

------
mmf
What is an element store? An object store?

Unless I'm not understanding the use case, if this is a persistent object
cache, defining an interface on each type you want to store sounds like a lot
of overhead...

Why not implementing a persistent LRU cache map instead?

~~~
sebcat
> Unless I'm not understanding the use case, if this is a persistent object
> cache, defining an interface on each type you want to store sounds like a
> lot of overhead...

It's one of the things I feel I havn't gotten right yet. I've made a couple of
different implementations of this functionality before (stor, elstore on my
github profile). Neither of them "feels" good in the way they handle
serialization and caching of different types. It comes down to the lack of
generics maybe, but at the same time I can't help but thinking that there is a
better, more idiomatic go way.

> Why not implementing a persistent LRU cache map instead?

What would be the difference from the current implementation?

