+972 52-548-6969
What is new in RavenDB 3.5–Intro
We have released RavenDB 3.0 about 10 months ago, since then we have a few interim releases with minor fixes and features, but now we are gearing up for RavenDB 3.5 release, and there are a quite a few things that we have there that we are really excited about.
I’ll have detailed posts about each of the major new things that we are doing there, but I wanted to take this post to talk about the general direction that we are going toward in 3.5.
In 3.5 we did a lot of underground work, doing cleanup, performance work and many optimizations. We dealt primarily with smoothing things over, exposing more internal behaviors and configurability and in generally making sure that you have smooth sailing. For example, we have a much more predictable performance due to much better control over threading, fine grained control over replication, additional endpoints that expose the internal state of the server for operations, and a big surprise for the operations team in general.
We have another two weeks before code freeze for 3.5, and I wanted to ask what kind of features you think you would want to still slip into this version, before I show what new stuff we have.
Comments
we're still digging around with 2.5 - we've tried 3.0 several times now but studio and/or server overall still seem quiet unstable. i've written quiet a complex plugin for the database itself to handle our complex directory/authorization requirements (access delegation, access inheritance, complex [more than a tree] group topoligies). porting the plugin and client has been relatively easy so far. but concerning the server our overall impression unfortunately is still that there are many glitches that need to be fixed before we get more trust into the product itself :(
So, no linux? :(
The feature I'm most waiting for is.... Linux!!! :P
I'm definitely waiting for Linux and MacOS support before moving to RavenDB. I'm loving the features so far (better than the competition), but I really need that cross-platform support before RavenDB becomes useful to me.
my list of things: - mono/linux support! please bring a stable voron! really looking forward to it! - i'm also eager to see what you'll offer for operations team (new relic integration would be great!) - simple API to delete a ravendb - simple API to wipe all documents in a db (we use that for testing) - more documentation! - and a more stable raven studio!
edit: possibility to list items in a comment on your blog ;)
just found that there is a DeleteDatabase method: http://ravendb.net/docs/article-page/3.0/csharp/client-api/commands/how-to/create-delete-database, very nice!
A better way to move data from production to development.
Something that helps me with the [bug report --> diagnose --> reproduce --> fix --> deploy ] loop
Full support for CoreCLR, if not already planned :)
Support for CoreCLR would be great :)
Looking forward to it (and a touch nervous)
Stability, in particular memory utilization for multiple tenants - this kills me and honestly I would happily lose new features to make sure that things are reliable from the first release of 3.5, without having to apply multiple unstable builds until things are manageable The ability to use Result Transformers and Raven Authorization on the same query Choose Columns in Raven Studio to show all available properties, at the moment it only shows a few Delete collections from Raven Studio
Raven Authorization for Raven FS so we can control access to the file system using roles / users / operation permissions etc.
Daniel, Do you have concrete issue, because 3.0 has been out close to a year now, with a long beta/RC period. And I don't recall any issues that were raised by you.
We can't fix things that we don't know about
dominique, Linux (actually Mono), turns out to be quite hard. We are working on that, and have a full time person on this, so we will get there, but it is hard to say exactly when.
Mark, CoreCLR is still very young, and it is missing a lot of stuff. We'll support it, when it is actually stable enough to do stuff with.
We currently have a few bugs logged with MS about CoreCLR issues.
Ian, What do you mean, Raven Authorization & Result Transformers in the same query? There shouldn't be any reason you can't do that. Chose columns was improved in 3.5, too
Erick, Just wait a bit, I think that the next post in this series would make you happy:-)
we’ve had the overall impression that many features don’t work that fine. We’re building a quite complex groupware on top of raven – at this point already a soon production ready system. To get up to the issues we had so far. - Management seems to be require still some work This isn’t really important for operation – but when digging into some docs or during development of some specific features it’s quite important Overall we had the impression that the new UI isn’t still complete. Personally i would like a more dense UI –buttons, text and lists are quite larger than in 2.x. But that’s just a personal impression - Creation of databases didn’t really work for quite a while I tried to create a new database several times but i got some errors that creation failed I found a solution on the forum (google) about this and got our database created - We ported our ravendb abstraction + plugin to 3.0 and ran our unit tests We also ported our existing database When restarting the raven service the system ran at 100% cpu load all over the time – but we only had a few docs (a few thousand) => We dropped the database and recreated all stuff => The issue happened again after some time
we did the tests around 2 months ago. We’ve waited a while before trying to port our project to 3.0 - leatest and greatest is not always our primary goal. it's important to trust vital components of our system. at this point we're just afraid that some of the problems we saw so early will occur when the system goes live.
Daniel, Without reporting any of that to the team, there is no way that we can help fix that.
Note that any time that you create an internal plugin, you have to take into account that you could impact how the db operates.
yep - i fully agree. it's just hard to know wheter it's really an issue of the software or ourselfes as user. we're doing quite much administration of medium-sized infrastructures and are quite somehow stuck with many vendors that don't really care about issues on their software (our customers' software). it's propably some trained behaviour to try to work around issues or resolve them ourselfes before explaining first-level-support issues that should be handled by third-level or dev.
of course - we're testing our plugins quite deep so far. our authorization plugin requires integration into the database itself because we're doing some calculation and tree-resolving (inherited ACL) when a document is stored (this is important for us to be able to fix ACLs on the ui without destroying state in the backend). we tried also to start the database without our plugins - the high-load issue occured also (so far the best case for us to expect failure on our plugin when a circular-inheritance occurs and the loop detection fails due some internal changes).
Daniel, We take a lot of pride in being very responsive to our customers. We typically are able to offer a resolution within a few days, often within a few hours.
I am building a stock accounting app, and would like to use ravendb. One of the most important feautures of my app is synchronization. This app will be installed on a distributed system. Many stores and one central server.
My problem is that stores does not have direct accessable ip addresses, so for now, to replicate db, we will have to make vpn connection to the central server. This will add an additional effort to support the system.
And my wish to be able to initiate a two way replication from the client, I mean after client db has sent local changes to the central server, it could ask for new changes made on central server. Or client could be scheduled to connect to the central db and request changes.
Comment preview