After focusing for so long on the low level and performance of RavenDB 4.0, you might be forgiven if you think that we are neglecting real meaningful features in 4.0. That couldn’t be further from the truth, the problem is that this it is actually quite hard to talk about some features meaningfully before they have been through complete round of implementing, testing, wiring for UI and UX and then beating them with a stick to see what fall.

Document versioning in RavenDB isn’t new. It has been a feature for several releases now. In RavenDB 4.0 we have decided to reimagine them complete. One of the strong points of RavenDB design from the get go was that triggers allowed you to build new features into the product without making core changes. That allowed quickly adding new features, but could cause issues with feature intersections.

With RavenDB 4.0, versions are now part of the core code. That means that they get special treatment. Here is how it looks like in the UI:

You can switch between versions of the document, and see them as it was at various points in time.

Externally, this is pretty much all there is to it. Here is what this will look like when you are looking at a revision.

In terms of the client API, there is little change:

So what did change?

Revisions are now stored separately from documents. Previously we stored them as special documents, which led to some problems (indexes had to read to see that they aren’t interested in them, for example), and we had to special case a lot of stuff that is supposed to work on documents to not apply to attachments. Making them their own unique thing simplify everything significantly. We have also made sure that revisions can properly flow with replication, and prevent the potential for versioning conflicts which were tricky to solve. The downside of this is that desirable operations on revisions (load a revision with include, for example), will no longer work.

The whole thing is also significantly faster and cheaper to work with.  A major change we also did was to ensure that versioning is always on, so you don’t have to specify it at the DB creation time. Instead, you can configure it whenever you want, without having to add a bundle at runtime and risk unsupported operations.

That means that if at some point you want to start versioning your documents, you can just flip a switch, and it will immediately start versioning all changes for you.