Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

RavenDB 4.0 Features: Document Versioning

DZone's Guide to

RavenDB 4.0 Features: Document Versioning

RavenDB has overhauled its document versioning strategy, trading off a bit of functionality for drastic improvements in ease of use.

· Database Zone
Free Resource

Traditional relational databases weren’t designed for today’s customers. Learn about the world’s first NoSQL Engagement Database purpose-built for the new era of customer experience.

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:

image

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.

image

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.

Learn how the world’s first NoSQL Engagement Database delivers unparalleled performance at any scale for customer experience innovation that never ends.

Topics:
versioning ,database ,document ,ravendb 4.0

Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}