Paging of a query result is something you normally think about when your application gets really slow. This seldom occurs while developing (you don’t have enough data to feel the pain) therefore the unpleasant surprise wait until your application is in production. And trust me, to add paging as a hotfix while your users can’t work is nothing you want to do.
Just by using a non-relational database your data doesn’t stop to be related. Therefore you must find a way to express a relation even if your database can’t enforce such constraints. What is true for most NoSQL solutions is (for once) also true for RavenDB.
One of the main purposes of continuous integration is to know when your build fails. As soon as a problem is detected you want to be alarmed. But in certain situations you can accept a failed build. Today I will show you how to use a build matrix in Travis CI to allow failures for certain builds – without causing the entire build to be shown as failed.
As experience shows the quality of code degrades slowly and before you know it will be an unmaintainable mess. To prevent this many practices where developed and have proven their usefulness over and over again: test automation, continuous integration and code analysis are just a few of them. Unfortunately those practices still require work and just using them will not automatically keep your project on the happy path. Never less if you don't apply them your chances are even worse.
In a relational database you work most of the time with a set of rows. This fundamental concept gives SQL its power and flexibility. You use this in every SELECT and when you have to update or delete many rows at once. To delete all orders with an id less than 100 you can write this command:
Whenever you search for documents in RavenDB you are using an index. Therefore indexes are a topic you must understand to effectively use RavenDB. The algorithm behind is Map/Reduce and was explained in an earlier post.
Indexes are a very important part of RavenDB. Without them you couldn’t find your documents. But before I can show how they are created and used I have to explain the Map/Reduce algorithm. Map/Reduce is used for processing large amounts of data and was invented at Google. You can find many explanations and even more formulas on Map/Reduce, but I found them always hard to understand and it took me a long time to recognize the benefit of this algorithm. Therefore I try a simple (and most likely not 100% correct) explanation.
If you use RavenDB in your application you may find the one or other bottleneck. In that case the book "RavenDB High Performance" from Brian Ritchie (@brian_ritchie) may be a good read for you. It is full of practical advice about optimizing your application and getting the most out of RavenDB.
Yesterday I was at the Soft-Shake conference in Geneva to speak about RavenDB. Soft-Shake is a multi-disciplinary conference with a wide range of topics. In 9 parallel tracks you could see presentations about agile software development, functional programming, Big Data, Java, Microsoft and many more. The mixture of different technologies and languages was refreshing and I hope more conferences will adapt this pattern.
Documents are the most important part of a document oriented database like RavenDB. Without those documents you can't do anything. To know how to design them is therefore a skill you really must learn to work effectively with RavenDB.
The good news first: Most of the things you know on how to build software and model your classes can be reused. It even gets easier as soon as you no longer try to represent the world as a series of rows.