RavenDB 3.0 just announced itself, and its come with a lot of goodies. Its the biggest step forward in the journey since its inception. My 3 year journey with RavenDB so far can be compared to that of a child learning to communicate in a new language. Upto a certain point your main concern is to communicate your basic needs, and I have found RavenDB providing me refreshingly easy options to do so.

But after a certain point if you don't actively learn new vocabulary, new ideas don't come to you. This new vocabulary is what I seek to learn with RavenDB 3.0 given so many new features. Except that this time around now that I feel more invested with the product, I want to show more patience and respect to problems I might face out in the wild when using all these new shiny features.

I believe this goal can be most easily achieved if I familiarize myself with the RavenDB 3.0 codebase. Not so much to debug it, but to know how it's structured, how to navigate it, know where to look if you get curious about a certain feature etc. And more importantly when I look at the code, I want to know the high level abstractions, opinions and different concerns that are at play, in short given its such a complex beast, I don't want to miss the forest for the trees.

So here are a few questions that will help me vastly cover ground towards that end.

1. I am curious about how much Lucene concepts does one need to be aware of to grasp the RavenDB code base? For e.g. will not knowing Lucene concept X limit you from understanding module Y, or is the concept X interviewed in such a manner that you simply won't get why the code is doing what its doing in dribs and drabs over many places.

2. Oren has often referred to RavenDB as an ACID store on top of which is an eventually consistent indexing store built. Is this a mere conceptual separation or is it clearly manifested in code? If so, how tight is the coupling, can you understand and learn one without caring much about the other?

3. Often operational concerns add a lot of complexity (think disaster recovery, optimizations for low end machines). When looking at feature code, will I know constructs a,b,c are intermingled here to satisfy operational feature y, so I can easily separate the wheat from the chaff.

4. Is there a consistent approach to handle side effects, for e.g when x is saved, update y. Pub/sub, task queue, something else? I am hoping if I am made aware of these patterns I will more easily be able to discover/decipher such interactions.

5. Should I expect to see a lot of threading/synchronization code for fulfilling multi core processing concerns, or true to .NET's more recent promises, are these concerns mostly addressed by good usage of Tasks, async await, reactive extensions etc.

Oren speaks highly of code that is easy to read, change and improve. Well.. so does everyone else, but I have found he makes some refreshing choices towards that end that often question conventional wisdom. These are the choices that I am out to discover when I look at the code, ahead of familiarizing myself with exactly how feature x is implemented or how to extend feature y.