61–70 of 70 posts
For new products I always recommend the same thing: name your competitors and use cases. Compare them in a table; don't make the user think. Who should and should not use your product? Being in-memory and distributed, I imagine your competitors include Ignite and Hazelcast? I read the title as CursorDB, which would have made a nice DB name.
'cause "alt1 vs alt2 vs alt3" is what I'm searching
For new products I always recommend the same thing: name your competitors and use cases. Compare them in a table; don't make the user think. Who should and should not use your product? Being in-memory and distributed, I imagine your competitors include Ignite and Hazelcast? I read the title as CursorDB, which would have made a nice DB name.
Also write a blog post titled "YourProduct vs alt1 vs alt2 vs alt3 etc" 'cause "alt1 vs alt2 vs alt3" is what I'm searching
Earlier quoted context omitted.
No not using Jepsen. I've written custom tests in GO running thousands of concurrent client connections on local and remote clusters with multiple nodes and node replicas I test consistency, crisis, recovery, etc. The database hasn't shown me personally any flaws whatsoever. Anyone can go ahead and write their own Jepsen tests if they please.
Maybe down the line if people REALLY want it I'll do it but I think I'll just post my tests instead. The thing is I'd rather make a video as you can't test power outages and so forth with just a script. I've done this using hardware locally and I can't find flaws. I'm not trying to make it seem any which way. I'd rather have more people write their own tests as well, why not!
The only exception I know of is FoundationDB, which was written pretty much test-first, and about which Kyle Kingsbury said that their tests are likely better :-)
Wow.
Wow.
I've read through the documentation and have played with database and I really enjoyed the experience. Good job!
Earlier quoted context omitted.
Maybe down the line if people REALLY want it I'll do it but I think I'll just post my tests instead. The thing is I'd rather make a video as you can't test power outages and so forth with just a script. I've done this using hardware locally and I can't find flaws. I'm not trying to make it seem any which way. I'd rather have more people write their own tests as well, why not!
Well, Jepsen has a reputation for finding problems in pretty much every database they test and has become a sort of a benchmark by now. Many people (including myself) won't consider a distributed database if it hasn't been put through Jepsen. The only exception I know of is FoundationDB, which was written pretty much test-first, and about which Kyle Kingsbury said that their tests are likely better :-)
Thank you for your response.
Earlier quoted context omitted.
Well, Jepsen has a reputation for finding problems in pretty much every database they test and has become a sort of a benchmark by now. Many people (including myself) won't consider a distributed database if it hasn't been put through Jepsen. The only exception I know of is FoundationDB, which was written pretty much test-first, and about which Kyle Kingsbury said that their tests are likely better :-)
Thank you for the information @jwr! I've looked into it. I'm not trying to put money down on anything currently. I've tested, and I mean tested hundreds of hours possibly even thousands from the start to the now, every feature, multiple ways. I wouldn't deploy releases and mention features as an actual feature if I didn't test every single thing beforehand. I am thorough, I do crazy amounts of sanity checks on everyt…
Interesting product. I'm reading through the source and... Woah... it is all in one single file with zero unit tests. Of course there are many ways to skin a cat, this seems like a very odd choice for organizing a database codebase. Some of the methods like cluster.HandleClientConnection() are crazy long for loop + if/else + switch + goto! I know that you've said this is just kind of in your best interests codebase,…
Interesting product. I'm reading through the source and... Woah... it is all in one single file with zero unit tests. Of course there are many ways to skin a cat, this seems like a very odd choice for organizing a database codebase. Some of the methods like cluster.HandleClientConnection() are crazy long for loop + if/else + switch + goto! I know that you've said this is just kind of in your best interests codebase,…
This is spaghetti to you? You must be lucky as this is very clean to what I get to work with daily (and that’s more like millions LoC.
In order to comprehend it, I'm going to have to parse the whole thing into memory and figure out what it does. Not impossible, but if I'm looking to just fix a specific bug or contribute a new feature, I'd much rather go to the specific file that feature/bug is in, parse a page or two of code on my screen and work from there. It is just how I work.
I'm sorry that you have to deal with something that sounds worse. If it was me, I'd spend a lot of extra-curricular time trying to clean up the mess. In return, that would help me get an even better sense of the code.