Killing munin

[Oren Eini (Ayende Rahien)]

There appears to be another race condition in Munin, and it only happen under some _very_ specific circumstances, which I am not really able to detect and reproduce properly.

The problem does NOT manifest with esent, mind.

Currently, the only use that we have for Munin is to be able to run in memory tests.

Originally, I though about using Munin for porting RavenDB to linux, but it never got to be truly stable enough for production use, and I thing that Mike's approach with BDB is better.

I am currently seriously considering just killing off Munin and creating a pure in memory storage that would be much simpler to work with and manage.

Thoughts?

[Justin A]

:)

[Michael Weber]

Yeah, I think we can drop it.

I think it would also be useful to re-vamp the tests project a little as well.  There seems to be a mix of in memory databases, configurable storage engines and hard-coded storage engines throughout the project (and it's hard to figure out which one is going to be used for the test).  It seems to me like the best thing to do is support running the entire test suite against one of the three storage systems, esent, bdb and the new in-memory system.  That way any future bugs that end up as tests are verified against all the storage engines.

[Oren Eini (Ayende Rahien)]

Michael,
I agree, to some degree, about the tests.
I would love to see a pull request for that

[Michael Weber]

Ok -- I've done the initial conversion and issued a pull request.  There are still problems that I'm not sure how to fix.  For example there are low-level storage access tests that cannot be run on the esent engine since it, at some points, requires that there be an active batch.  I also tried to update the default.ps1 file to run the test against each storage engine, but there seems to be a problem with that script with respect to the StressTests project that is no longer in the 1.2 solution.  So I made my best guess at the change, but I cannot verify that it's functional.

[Oren Eini (Ayende Rahien)]

Okay, great.
Thanks for that, I'll go over this tomorrow and see where we are at.

[Oren Eini (Ayende Rahien)]

I have gone over the test refactoring, and I have one major comment:
There is a reason why we select the storage engine like that for the tests, performance. There are many tests in which storage isn't really a factor, it plays a role, but only a supporting one. As long as the storage works, we don't really care.

I made some modifications, but even so far, it looks really good.
New build coming up.

[Oren Eini (Ayende Rahien)]

Okay, I started doing this:
https://github.com/ayende/ravendb/tree/ram

But I have a course starting up in a few hours, and I can't dedicate the time it needs.
Anyone want to pick it up and see if they can complete it?

On Mon, Aug 20, 2012 at 9:29 PM, Michael Weber <mtw...@gmail.com> wrote:

[Michael Weber]

I completely agree, that in the long run, it's better to have faster tests, and there is no reason to run every test against the storage system.  I just know, right now, trying to bring a storage engine up from scratch that it's hard to know what tests to run to make sure the storage engine is operating properly.

[Itamar Syn-Hershko]

Most of the tests are a no-brainer - if it's storage related it needs to run against all storage engines, otherwise not.

Some general querying tests (Map, Map/Reduce, updating documents etc) need to be there as well as they interact with the storage engine

I think it's a matter of formulating a handful of tests that can cover all the querying functionality that should run against all the storage engines, and the rest of the tests will be run against the fastest of them

[Oren Eini (Ayende Rahien)]

Itamar,
It is actually easier to NOT make that determination.
Just allow to suggest what engine to run on if we are testing a particular scenario, they run all tests in the integration phase against all.
We already have very long release cycle, adding tihs won't change things much for stable / RC releases.

[Ryan Roberts]

Seems reasonable. The only non test use I had for it was app harbour hackery. This is no longer required thanks to ravenhq.

Ryan