Why ravendb

To be fair, I use it with Python not with. Net not even IronPython. Still, this project like many others have been around for a while and are field tested with a big community support and several commiters, sometimes with big names using them. Often they originated from one of those big. My concern here is about real life usage. RavenDB is brand new and doesn't really have this background. Still I understand there is a lack of a.

Net friendly option, but I believe you could have contributed an elegant solution to reduce the amount of friction. Net developers have with the others. There is always a possibility to build on top of the low-level APIs these stores provide. That said, I wish I could work on such a project. There is a lot of great problems to solve here and hours of fun. Is it possible to 'disable' the help pages in the server? I got a crash when using a TransactionScope around a session On top of what was already said, it looks amazingly cheap to do Domain-Driven oriented prototyping using RavenDB.

Also, can't wait to test it paired with NServiceBus. Paul why would that be? If you use sharding, it will split data among the shards, and it can handle add nodes dynamically.

Removing nodes or node failures requires replication to be able to recover that, which is something that Raven does.

Markdown turns plain text formatting into fancy HTML formatting. Get in touch with me: oren ravendb. Richard Lopes puts the question nicely: However as a pragmatic developer, I am wondering what new this project is offering in a saturated market where you have quite mature alternatives like CouchDB, MongoDB, Tokyo, Redis, and many more? The answer is composed of several parts, and cover quite a bit of history.

Why Raven DB from your point of view? But true nonetheless. What does Raven DB has to offer? You can easily trivially embed Raven inside your application. That means ACID, if you put data in it, that data is going to stay there. Transactions and can take part in distributed transactions. I would love to hear your opinions about it, both positive and negative. Tweet Share Share 56 comments Tags: Raven.

I'm currently choosing to use it because: Being able to embed it makes it really easy to write integration tests Create directory, run tests, delete directory Easy Unit of Work implementation Important if you want to keep a tidy system Because I like having to define indexes up front, the idea of just dummy querying against data without indexes defeats the whole point of having a speedy read-store.

Because it's new and offers opportunities to help shape it and talk about it at an early stage. I'd like to download and play with this. Is there an example app built on RavenDB somewhere? You're using Lucene for searching if I recall correctly? At the moment a crash during a lucene index update can corrupt the index : Looking forward to giving this a poke regardless! Demis, I beg to differ. Demis, Raven beeing restfull server side, I don't get the point of Raven not beeing used with non-.

Ayende, Could you gave us a clue about when Raven will get to an "official" Beta status? Henning Anderssen I beg to differ. Guillaume Demis Raven beeing restfull server side, I don't get the point of Raven not beeing used with non-. The same could be said of the parallel framework which I think RavenDb uses. Andrew, Yes, it is. It is able to recover nicely from crashes. Ales, Not at the moment, no. We have some plans to do so, but they are on a backburner for now.

I don't think so, the client uses REST, so can anyone else. It would be trivial to add support to that for any platform that can make HTTP calls. Guillaume, Mongo saves to memory, Raven saves to disk. Raven can do crash recovery, Mongo cannot. Raven is transactional, Mongo is not. That is for writes, for reads, Raven should be just as fast. Raven will be out on the 18th. Demis, one of the areas in which it is not is in high-performance network servers. I wrote a. NET chat server that supported 20, connected clients easily.

It is really not that hard, and yes, I used async IO for pretty much everything. Demis, but most of the advanced features will only be available to. Paul, It means that it is more accessible, it means not letting a new runtime into production env. It means that a. NET dev can figure out what is wrong if he needs to.

It means that extending the server is EASY. Nick, Something similar is planned, yes. Guillaume, What do you mean, Mongo doesn't scale? My reading says that it is very scalable.

Jason, Yes, that is one of the major reasons, but not the only one. By default, no. Raven allows you to customize it, though. And as a distributed database, it also offers ACID guarantees throughout your database cluster.

Your developers are exempt from handling the numerous scenarios of partial data transfers and the intricacies of data storage, and are free to focus on building robust applications and deliver value to the business.

Trading algorithms need to update aggregate figures in real time, processing petabytes of trade data each moment. Health care applications need to rapidly track test results and compare them to millions of similar cases, in order to assist doctors in choosing the best course of action. Point Of Sale POS applications need to update inventory totals, regional sales and purchasing needs on the hour. These requirements call for a database capable of handling massive amounts of data in real time, while guaranteeing its integrity for every transaction.

Instead of manually creating new indices, RavenDB will do it for you. Your development cycle itself will accelerate. Saving you time. With every new data write, if it is something that should be counted as part of the aggregate, RavenDB will include it in the updated total.

How many from America? How many from Asia? The next time you ask, the answer will be waiting for you. There will be no need to recomb the database.

This is great for complex architectures like microservices which seek to minimize complexity and for development teams that want to maximize their productivity by learning just one technology for their database. Our storage engine is built by the same developers who built RavenDB so it all fits perfectly and is geared for superior performance.

Advanced Query Engine Map your documents with indexes, analyze text and spatial data, project your data into new shapes, and more. Multi-Model Architecture A multi-model database for all your services: document store, graph queries and others. High Availability Set up a distributed data cluster in minutes. Ease of Use Easy to install, simple to secure, and quick to learn.