[/caption]In the second part of this three part special on the GA release of Drizzle7 I covered the development and testing model we use for Drizzle. In this final part I will cover what you can expect from the future of Drizzle.
What to expect in the future
Whilst we are very proud of the GA release of Drizzle7 there are still features we would like to implement that we could not complete before the release. Whether the next release is Drizzle7.1 or Drizzle8, we haven't quite decided yet. But one thing is for sure, we will not be making you wait 3 years for it, expect the next GA to come later this year! Some of the features I outline here might not make the next GA but we will work our hardest to make sure as much gets in as possible.
Several of the features outlined in this post are planned as possible Google Summer of Code projects, so if you are interested in picking one up please see our GSoC wiki page.
Data Types
We have done a lot of work on data types in Drizzle7 including microsecond precision TIMESTAMP along with new native BOOLEAN and UUID types. We are planning a few additional types including a native IP address type and a TUPLE type which with encapsulate a replacement for the currently missing SET data type.
Catalogs
This is a big one and can be difficult to explain, but I will give it a go. We have already put much of the framework for catalogs into Drizzle7 and hidden away from the user there is a built in 'local' catalog used when starting Drizzle. But what is a catalog?
Think of it as a way of multiple instances of the Drizzle server but running under one daemon. So, inside a catalog you have users, schemas, tables, etc... and each catalog is isolated from each other. If you think about this for a moment it is a huge deal in many ways. For example if you have some kind of shared services (such as cloud) each user to the cloud can have their own catalog, completely isolating their data from everyone else.
On top of this we are planning adding a tunable per-catalog limits system so that you can have some catalogs with higher priority of resources than others.
Stored Procedures
One of the first things we dropped in Drizzle was stored procedures. In many articles it has been written that they are gone and will never return. But in Drizzle if there is demand for something and the developer time to do it, we will bring it in. What people may not realise is part of the framework for this already exists and is used for the slave applier (much like the slave SQL thread in MySQL). We will be doing stored procedures, we will be doing the properly and they will be done as a plugin so that if you don't want them you don't have to have them.
HailDB
Drizzle7 has an optional HailDB plugin. But lets take a step back as many won't know what HailDB is. HailDB is a fork of the Embedded InnoDB source code with many fixes and improvements in it. It can be used completely independently of Drizzle and integrated into your own code. It is the eventual goal to have HailDB take a bigger role in Drizzle, possibly replacing InnoDB as the primary storage engine.
Summary
This is just a small sample of the things we have planned. But the great thing about Drizzle is you, the community, help shape it. If there is something you feel Drizzle needs we may be able to include it. Being able to code helps but contributions come in many forms, from helping in mailing lists and the IRC channel, to documentation, to filing bugs, to raw code. Every contribution is valuable, and every contribution helps to evolve Drizzle.
I hope this three-part blog post has been useful. If you have any questions please direct them the #drizzle Freenode IRC channel, the mailing list or even contact me directly.
Stored procedures is defiinitely coming in. We do have the developer time. :-) Its gonna be awesome! Kickass as pcrews mentioned. :-)
ReplyDelete