Hacker News Reader

Comment by jbellis | Hacker News Reader

The bugs he ran into with lightweight transactions were fixed within days, two weeks ago, and included in the 2.0.1 release shortly afterwards.

View on HN

DataStax still claimed these properties while the bugs were live. It's important they fixed them quickly, but the point still stands—the point of the entire series, I think—that database companies very frequently make big claims that few people go through the process of checking... even at the companies themselves.

It's important to distinguish architecture and design from implementation. The former may be correct, even if the latter is found to have a bug.

If you distinguish between those two, and implementation doesn't match design, then you must concede you have a level of incompetence in your development chain.

When dealing with data, you don't get any points for "well, we meant to do it the right way, but it didn't happen. sorry."

I guess I'll have to settle for joining the crowd of incompetents behind PostgreSQL, Linux, the JVM, et al., who have also been known to release bug fixes on occasion. :)

I guess I'm just quite surprised Aphyr turned that one up. I didn't look at the fix, but it's a pretty severe bug if it completely, silently disables a feature.

It is, and I think the author did.

Have you ever seen a product feature description edited on account of a bug report, particularly one that was resolved within days?

Yes.

Congratulations then.

Seriously, I've seen plenty of bugs found in database transaction mechanisms, and I've never seen a database pull claims of, "transactional integrity". I can't even imagine that getting through the product team in a couple of days.

You mean companies sometimes promote features that still have bugs ? My god that is incredible. I can't believe that has never happened before. Oh wait it has. On nearly every single software project in the history of software projects.

His test amounts to inserting integers without even simulating a network partition. This is about the most basic test of the purported functionality you could come up with, not a fencepost error or some cosmetic problem. This is advertising a fundamental property of your software and not even doing the most minimal checking that it is true.

Databases are and must be held to a higher standard than the software sitting above them in the stack, just as kernels must be held to an even higher standard, because bugs in lower layers cause more damage with higher costs. DBAs and commercial databases are expensive because data is valuable and there are liabilities. If the database developer made a remark like yours, I would run in the opposite direction. A smug reply like that exposes a fundamental disrespect for other people's data--their property. If one has no respect for our property, one shouldn't find it surprising that we have no respect for one's software or services.

I note and appreciate that the Cassandra developer's reply below is even-handed and serious.

Of course, if aphyr hadn't reported the bugs before publishing, they'd be live right now, right?

And who knows how many more are lurking? I think that's the issue exposed by this post -- if these really basic things are broken, why would anyone believe that the actual tricky stuff has been tested?

It's awfully hard to prove a negative, but our test suites are open [1] [2], and so is our bug tracker [3].

[1] https://github.com/apache/cassandra/tree/trunk/test/unit/org... [2] https://github.com/riptano/cassandra-dtest [3] https://issues.apache.org/jira/browse/CASSANDRA

Interesting. Care to comment on why you think the issues brought up in this blog post weren't covered by your test cases? To me they seem to be approximately the first thing you would test with any transaction feature, but I don't work on a mutable datastore, so maybe I have a misapprehension of the situation.

I guess what I'm trying to say is, if I see something I think should obviously be tested not tested, my go-to assumption is that the failure was in bad testing practices. To dispel that belief, I need something to replace it with that explains the observation even better. If you're willing to share your view of the situation, maybe that would do it. (There's no real business case for you to do it, since I'm not in your market. But as a hacker, I'm interested in what I can learn from this.)

No excuses. It's as simple as me dropping the ball on this one.

> I think that's the issue exposed by this post -- if these really basic things are broken, why would anyone believe that the actual tricky stuff has been tested?

So, I think it is relevant that LWT is still a very new feature in Cassandra and not something basic to it at all (arguably counter to a lot of its original design goals).

Personally, I was much more concerned by the server side timestamps only using millisecond granularity (and even that is somewhat understandable given the JVM's limitations).

The fact that these bugs were so trivially reproduced and made it into an initial release at all should be cause for concern.

Conflict of interest disclosure -- I work for FoundationDB, where we put a shockingly high level of effort into testing our software in simulation and the real world. [1][2]

[1] https://foundationdb.com/white-papers/testing

[2] https://foundationdb.com/blog/quicksand-continuous-real-worl...

Please. I have yet to work in any environment that hasn't had a brown bag release or two, regardless of how well tested it is.

Nice marketing attempt though.

advice from someone who's been at this nosql thing for about 6 years now. schadenfreude will always come back to bite you. tread lightly.

Sorry for the offtopic post: just noticed now that three months ago, you mentioned I misrepresented your words. I deeply apologize; that's not at all what I meant. I had found your Ricon talk refreshingly honest and quoted it admiringly to people I know. (I had zero issue with anything you said; but rather with certain institutions.)

I'm sorry for any errors/misrepresentations I made about your words, and will be more careful in the future. (Unfortunately, I can no longer edit, delete nor respond to that post.)

haha no worries my friend :) glad you enjoyed the talk!

> The fact that these bugs were so trivially reproduced and made it into an initial release at all should be cause for concern.

Umm... no. The .0 releases of the project are actually where you'd expect the most bugs. That's where you have the first commit with an implementation of a new design.

You'll note that DataStax's commercial version of DSE is still based on 1.2.x...

If foundation db released and is it open sourced?

I remember others (employees of company) hailing its wonderful qualities for quite a while now (years), then I go to the website and all I could find was a bunch of white papers and a registration form. And here it seems a bit of a "my vaporware's features are better than your shipped product's features".

Now matter how many white papers there are I would still put my data in Cassandra rather than this new thing (last I checked I couldn't even download it, I had to fill out a form of some sort).

FoundationDB isn't open source software, but it is a 1.0 product that's freely available to download right now[1]. (You are right in recalling that during our alpha and beta programs there was a simple registration form, and there's still an account signup for our community site and of course for Enterprise licensing and support).

[1] https://foundationdb.com/get

Reply on news.ycombinator.com