Azure Demo: A Quick Intro to Azure DocumentDB's Server-Side Javascript
0 (0 Likes / 0 Dislikes)
[Microsoft Azure]
[Azure DocumentDB]
[Server-Side Javascript]
[male speaker] Hey there,
my name is Andrew Liu,
and today I'm going to show you
one of my favorite Azure DocumentDB features.
Let's talk about bringing full stack JavaScript
into the database.
DocumentDB's
server-side programming model
allows you
to write integrative JavaScript logic
to be shipped and executed directly
on the database itself.
This is expressed in the form
of stored procedures,
triggers, and user-defined functions.
I have found this particularly useful
for performing
complex sequences of operations
closer to your data.
In other words, you can write
high-performance batching
and sequencing operations
without the need for multiple network requests.
Wait, it gets even better.
[ACID Transactions across multiple documents!]
DocumentDB guarantees
that database operations
performed inside a single store procedure
or trigger are atomic.
That's right—you get
fully ACID-compliant transactions
across multiple documents
inside a collection.
Simply put operations made
with in-store procedures and triggers,
either all succeed or none succeed.
Awesome. So how would you do this?
For this video,
I will use the DocumentDB Node.js SDK
with Q promises to interact
with my database using stored procedures.
Let's take a look
at this Hello World stored procedure.
Check it out. It's plain JavaScript.
There are no crazy new semantics
to learn.
Now, everything begins
with a context object,
which provides access
to all operations
that can be performed
on the DocumentDB collection,
as well as access to the request
and response objects.
This context object can be retrieved
via the getContext method.
In this example, we placed the string
HelloWorld into the response,
which will get passed
back to the application.
Now that we've defined
our stored procedure, how do we use it?
Let's register the stored procedure
onto one of our database collections.
This is accomplished
via the document client's
create stored procedure async method,
which takes two parameters—
a reference to the collection
and the stored procedure we just defined.
Once the stored procedure is registered,
we can execute it
against the collection
and read the results back at the client.
This is accomplished
via the document client's
execute stored procedure async method,
which takes in a reference
to the stored procedure
as a parameter.
Now let's take a look
at a slightly more interesting example.
Let's say we have a game
with two players, Ralph and Heather.
Ralph is a level 40 warrior
and has an iron sword.
Heather is a level 40 druid
and has a diamond pick axe.
Ralph would like to trade
his iron sword
for Heather's diamond pick axe.
Recall that stored procedures
are for atomic transactions
in which all work done
will be treated as a single unit.
Either all of the work is committed,
or none at all.
Stored procedures ensure consistency,
isolation, and durability.
With multi-document transactions,
we don't have to worry
about the player data
getting into some corrupted state.
In other words, we're safeguarded
from having both players
ending up with the same item
or losing any player data.
Here we have a stored procedure
that uses transactions
to trade items between two players
in a single operation.
In this example, the stored procedure
receives two player IDs
passed in as arguments.
The stored procedure will attempt
to read the corresponding player documents.
If both player documents are found,
then the stored procedure
updates the documents
by swapping their items.
If any errors are encountered
along the way—
if there was a JavaScript exception
that implicitly aborts the transaction
so that no work will be committed.
Now, here are some things
to notice.
All operations are asynchronous
and depend on JavaScript function callbacks.
The callback function
has two parameters—
one for the error object
in case the operation fails,
and one for the created object.
Inside the callback,
users can either handle the exception
or throw an error.
It is also important to note
that server side JavaScript
have bounded execution time.
All operations contained
in stored procedures
must complete
within the server-specified timeout duration.
If an operation does not complete
within that time limit,
the transaction is rolled back.
Otherwise, if the stored procedure
completes in time successfully,
the transaction is committed.
In order to simplify development
to handle these time limits,
all functions under the collection object
return a Boolean value
that represent
whether the operation will complete.
If this value is false, it is an indication
that the time limit
is about to expire and that the procedure
must wrap up execution.
In this simple example,
we will throw an exception
to roll back the transaction.
For other scripts, you may choose
to implement a continuation-based model
by gracefully returning
and completing execution.
Let's use a bulk import script
as an example.
You can check the Boolean return value
after creating a document,
and if false, return the countif documents
and asserted
to track and resume progress
across import batches.
After we have run
the stored procedure,
we can see that the players
have swapped items.
Ralph now has Heather's diamond pick axe,
and Heather now has Ralph's iron sword.
You have just seen a glimpse
of DocumentDB's server-side programming model.
To learn more about DocumentDB,
check out their website
at DocumentDB.com.
Also, please feel free to email me
if you need any help,
want to express feedback,
or would like any questions answered.
I'm extremely passionate
for this service,
and am more than happy
to help you in any way I can.
Have fun!