One of the hardest things we have to do it to get people who aren’t familiar with RavenDB acclimatize to it. This onboarding process is typically done by doing something tangential to RavenDB, which allows the new guys to learn RavenDB while doing something useful.

Past examples of this is the demo website for RavenDB, Python Client for RavenDB, internal tools, etc. In the case of Iftah, this meant going into an Open Source project, and add support for RavenDB.

This serves several purposes:

• It means that Iftah needed to learn how to effectively use RavenDB, and how to do that in the context of a real world problem, instead of dummy invented one.
• We get to have the Quartz.NET integration in the end. We even have a Nuget package for it, to make things easier all around.

If you don't know what Quartz.NET is…

… a full-featured, open source job scheduling system that can be used from smallest apps to large scale enterprise systems.

And was precisely what he did, which means that you can head to Quartz.NET with RavenDB, setup a couple of configuration options, and you'll have this:

This make it much nicer to look at what is going on, understand the various jobs, schedulers and triggers, and work with them. The fact that we can put pretty much all of it in once place means that we can have this:

Instead of this:

It also means that complex jobs, which require non trivial state (JobDataMap) have much easier time, because they don't need to try to shove all of that into the relational model, they can just store the state as is in RavenDB as JSON values.

One of the hardest things we have to do it to get people who aren’t familiar with RavenDB acclimatize to it. This onboarding process is typically done by doing something tangential to RavenDB, which allows the new guys to learn RavenDB while doing something useful.

Past examples of this is the demo website for RavenDB, internal tools, etc. In the case of Idan, since he had an extensive Python background, we decided to give him as the intro task the job of writing a RavenDB client API in Python. This has several advantages:

• Instead of shifting rapidly from the environment he knows and is familiar with, we get a much gentler curve.
• In order to actually implement it, he would have to become very familiar with the guts of RavenDB and how it actually works. Obviously that would be mostly on the client, but you can’t really do that without also understanding what the server is doing.
• We end up with a usable Python client.

So, without further ado, let me show you how this looks like:

And the result is:

Which is pretty nice. The Python client API can handle most CRUD scenarios, including full support for replication, failover, dynamic queries, etc.

It isn’t the complete client, like we have for .NET or JVM, but it should do for most needs, and as usual, pull requests are welcome.

There is still a bit of work remaining (documentation, deployment, etc), but this is ready to take for a spin.