What is new in RavenDB 3.0Queries improvements

time to read 4 min | 611 words

RavenDB is an ACID database for documents, and it is a BASE database for queries. That design principle has serve us very well since the start, because it allow us to modify the way we are handling things internally without violating the promises we give to the user.  In particular, the ability to hand out potentially stale information has been crucial for a lot of performance optimizations in RavenDB.

That said, while is has been a core feature of RavenDB from the start, I haven’t found a single user who had a hankering for longer staleness latency. That is a long way to say that we managed to reduce further the number of times RavenDB will return query results marked as stale. We have talked about some of this in the previous posts, with regards to better batching and optimization in the indexing process itself, but we already talked about this.

In RavenDB 3.0, we are using smarter algorithm to detect if an index has potentially changed, in particular, we can detect if the index isn’t covering any of the changed documents that it hasn’t had a chance to index yet. If we know that no document yet to be indexed is going to be indexed by this index, we can short circuit indexing and declare the index as non stale. In practice, this should resolve a common misconception “I changed one document, all indexes became stale” by having a better match between what the user thinks is going on and the externally observed behavior.

Your applications would be a little faster, but that should be the sole difference from your point of view.

Another change that does require you to take active action is nested transformers. The idea is that transformers often encompass some piece of business logic related to how to pull an entity / entities for a particular task. It would be nice not to have to duplicate this logic (and maintain it over time). With RavenDB 3.0, you can now nest transformers and have one transformer call another to do some part of the work.

Here is how this looks:

TransformResults = products =>
from doc in products
select new
Name = doc.Name.Reverse()

// another transformer
TransformResults = products =>
from doc in products
select new
Product = doc,
Transformed = TransformWith("ProductTransformer", doc)

The 2nd transformer calls to the ProductsTransformer by name, allow it to run its own processing (and potentially call yet another transformer, etc). Note that a transformer cannot recurse either directly on indirectly. In other words ,you cannot call yourself, or another transformer that has called you.

There has been a lot of other changes, of course, but a lot of them are too small to merit such a mention. Better support for querying unsigned integers is hardly earth shattering. But there has been a lot of those kind of changes. It means that you’ll have a smoother experience overall.

Next post, replication Smile.

More posts in "What is new in RavenDB 3.0" series:

  1. (24 Sep 2014) Meta discussion
  2. (23 Sep 2014) Operations–Optimizations
  3. (22 Sep 2014) Operations–the nitty gritty details
  4. (22 Sep 2014) Operations–production view
  5. (19 Sep 2014) Operations–the pretty pictures tour
  6. (19 Sep 2014) SQL Replication
  7. (18 Sep 2014) Queries improvements
  8. (17 Sep 2014) Query diagnostics
  9. (17 Sep 2014) Indexing enhancements
  10. (16 Sep 2014) Indexing backend
  11. (15 Sep 2014) Simplicity
  12. (15 Sep 2014) JVM Client API
  13. (12 Sep 2014) Client side
  14. (11 Sep 2014) The studio
  15. (11 Sep 2014) RavenFS
  16. (10 Sep 2014) Voron