In-Memory Back-end about riak-dotnet-client HOT 8 CLOSED

I believe the ruby client also has an in memory back end. Of course, this
reminds me of my bad joke that all you need to write your own NoSQL
database is a hash table and a network socket.

Jeremiah Peschka
Founder, Brent Ozar Unlimited

On Fri, Nov 16, 2012 at 5:00 AM, Ethan J. Brown [email protected]:

Background

• Using CorrugatedIron / Riak 1.2 on a new project.
• Developing on Windows, with local Ubuntu VMs hosting Riak
• Using pretty standard fare repository interfaces along with
  dependency injection.
• As we go, we've ended up writing a number of in-memory variants of
  these repo interfaces to speed up unit tests, provide simulated data, etc,
  etc. Basically for any situation where we're testing something business-y
  and not persistence-y.

But I'm starting to think that there's a lot of ceremony that goes along
with building these in-memory repos, and that it would be nice to push this
responsibility off to CorrugatedIron.

Since the Riak datamodel is so simple, it can be pretty closely simulated
with a ConcurrentDictionary<string, object>.

I haven't looked too closely at your code in a while, but I think that
this would involve

• Implementing some new classes on top of the standard client
  interfaces
• Providing a config switch that denotes you're running on a fake Riak.
• Some combination of the two

I think the RavenDB client has a feature like that if I recall correctly.

Thoughts?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/53.

from riak-dotnet-client.

It's something that we'll keep on the "To look at" list. Not sure when we'll get to it as the focus is currently on v1.0 features.

Simulating Riak isn't necessarily as simple as having a ConcurrentDictionary<string, object> given that we need to also emulate Riak search, 2i, links and map/reduce. Emulating the simple KV part is a no-brainer, but if you're looking to mock out Riak completely then I think there's more work here than meets the eye.

from riak-dotnet-client.

2i and links aren't too bad... search and m/r are clearly a little more involved. Probably something I would punt on until there was a greater demand.

But... since this is something that would potentially save my team a ton of time (we're using ElasticSearch so don't care too much about search and m/r is of little use as well), how do you feel on pulls that implement this?

I'm not making any promises on having the time to do this, just putting out a feeler...

from riak-dotnet-client.

If you're willing to write it, we're willing to take a look at a pull
request.

Jeremiah Peschka, Managing Director, Brent Ozar PLF, LLC
Microsoft SQL Server MVP

On Nov 17, 2012, at 1:33 PM, "Ethan J. Brown" [email protected]
wrote:

2i and links aren't too bad... search and m/r are clearly a little more
involved. Probably something I would punt on until there was a greater
demand.

But... since this is something that would potentially save my team a ton of
time (we're using ElasticSearch so don't care too much about search and m/r
is of little use as well), how do you feel on pulls that implement this?

I'm not making any promises on having the time to do this, just putting out
a feeler...

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/53#issuecomment-10479184.

from riak-dotnet-client.

+1. Certainly willing to take a look at it.

from riak-dotnet-client.

Hi @Iristyle, did you ever make any progress on this? We're in the process of cleaning out old issues.

Thanks!

from riak-dotnet-client.

Unfortunately I'm not able to use Riak / CorrugatedIron / ElasticSearch on a daily basis anymore (haven't been for nearly 2 years now).

from riak-dotnet-client.

Thanks you for the update. At this point we'll close the request but may revisit the idea in the future.

from riak-dotnet-client.