RavenDB 4.0 Features: Document Versioning

After focusing for so long on the low level and performance of RavenDB 4.0, you might be forgiven for thinking that we were 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 a complete round of implementing, testing, and wiring for UI and UX, and then beating them with a stick to see what falls apart.

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 it completely. One of the strong points of RavenDB's design from the get-go was that triggers allowed you to build new features into the product without making core changes. That allowed users to quickly add new features, but it 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 they were at various points in time.

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

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

List<Product> revisions = session.Advanced.GetRevisionsFor<Product>("products/77");

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 weren’t interested in them, for example), and we had to special case a lot of stuff that was supposed to work on documents in order to not apply them to attachments. Making them their own unique thing simplifies 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 made was to ensure that versioning is always on, so you don’t have to specify it at 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.