+972 52-548-6969
Manual document revisions with RavenDB
We got an interesting question a few times in recent weeks. How can I manually create a document revision with RavenDB? The answer for that is that you can use the ForceRevisionCreationFor() method to do so. Here is how you’ll typically use this API:
This is the typical expected usage for the API. We intended this to make it so users can manually triggers revisions, for example, when moving a document from draft mode to public and the like.
It turns out that there is another reason to want to use this API, when you migrate data to RavenDB and want to create historical revisions. The API we envisioned isn’t suitable for this, but the layered API in RavenDB means that we can still get the desired behavior.
Here is how we can achieve this:
Basically, we manually create the transaction steps that will run on the server, and we can apply the command to the same document multiple times.
Note that RavenDB requires a document to create a revision from it, so we set the document, create a revision and overwrite the document again, as many times as we need to.
Another issue that was brought up is that the @last-modified property on the document is set to the date of the revision creation. In some cases, they want to do this to get the revision to be created at the right time it was originally created during the migration period.
That is not supported by RavenDB, because the @last-modified is tracking the time that RavenDB modified the document or revision. If you need to track the time a document was modified in the domain, you need to keep that as part of your actual domain model.
Comments
Thanks! Thats very useful. Last modified is important to me. Any plan to maybe put session in “migration mode” and this allow developer to pass last modified value? This feature, allows me to migrate from SQLServer + NHibernat with Envers to RavenDB...
Zote,
In this case, why can't you use e model property, instead of using the RavenDB property?
Is just history data for auditing purpose. Model modifying just to bypass this technical limitation is an option. But in this case I’ll need to remember that for some data we have to look for “RavenDB date” for migrated data, we need to look to “model data”. I’m talking about 100s of millions financial records with 10s versions each.
Zote,
Technically speaking, you can emit a ravendbdump file for the revisions. That will allow you to set the @last-modified, but that is the only way we allow that.
Comment preview