Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Better patching API for RavenDB: Creating New Documents

time to read 2 min | 329 words

A while ago we introduced the ability to send js scripts to RavenDB for server side execution. And we have just recently completed a nice improvement on that feature, the ability to create new documents from existing ones.

Here is how it works:

                                     new IndexQuery {Query = "Exported:false"},
                                     new ScriptedPatchRequest { Script = script }

Where the script looks like this:

for(var i = 0; i < this.Comments.length; i++ ) {
   PutDocument('comments/', {
    Title: this.Comments[i].Title,
    User: this.Comments[i].User.Name,
    By: this.Comments[i].User.Id

this.Export = true;

This will create a set of documents for each of the embedded documents.


Daniel Lang

This helps a great deal with schema migrations. Btw, what happens when we patch lots of documents this way, create new documents along the way and then there is an error and execution stops... is then entire patch operation transactional, or is there any way to make it transactional?

Daniel Marbach

Daniel, Patching API is not transactional.


It all converges to SQL...

Ayende Rahien

Daniel, Patching is transactional on a single document, yes. That is, if you create a 1000 documents in a patch, and it fails on the 1001 document, it will all go away.

However, it is not transactional over set operations. We pulse the transaction along the way at various points to avoid high memory usage, and that means that stuff that happened for a document in the beginning of the operation will be there if the operation fails for a much later document.

Since documents are independent, and a single document patch operation is transactional, we don't see this as a problem

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats