The 4th release of the GreenLake series is out. Major changes include:
On a side note, a proof of concept was done for Drizzle as a backend for OpenStack during this release as well.
Here is a piece of code that illustrates how to create a Drizzle object, a connection object, establish a connection, execute a query, buffer its result and do some basic operations on it. The code is pretty straight forward. DRIZZLE_RETURN_OK indicates the successful execution of a function. Make sure that you have libdrizzle installed in your machine.
if ((drizzle= drizzle_create(NULL)) == NULL)
printf(“Error creating drizzle object\n”);
con= drizzle_con_add_tcp(drizzle, NULL, “localhost”, 4427, “root”, “password”, “db”, DRIZZLE_NON_BLOCKING);
drizzle_return_t ret= drizzle_con_connect(con);
if (ret == DRIZZLE_RETURN_OK)
int count= 0;
result= drizzle_query(con, result, “SHOW DATABASES”, strlen(“SHOW DATABASES”), &ret);
To compile this program, one needs to link to libdrizzle. Use the following command to compile the code file. (Assuming that the code file is connect.c and that you installed libdrizzle-1.0 headers at /usr/include)
gcc -o connect connect.c -ldrizzle -I /usr/include/libdrizzle-1.0 -L /usr/lib
Hope this helps. Happy hacking folks!
This year was my third consecutive Google Summer of Code and I’ve done all three of my GSoCs for the Drizzle community. The first time I worked on refactoring the commandline options processing system using boost::program_options. The second time I worked on a stored procedure interface for Drizzle. This year I got a very interesting project to work on. My mentor, Brian Aker, asked me if I could work on adding Drizzle backend support for OpenStack. I was very thrilled since I’ve been long trying to contribute to the OpenStack community and OpenStack is a community that I’ve admired since its infant days. So, I happily said yes. Brian charted out a plan asking me to try adding a plugin for Collectd which could be used to collect the Drizzle server’s statistics from time to time. As part of this I had to work with libdrizzle. There were not many concrete examples of libdrizzle usage. I somehow managed to write a simple “Hello,World” kind of libdrizzle based C program which I had used as a base to start working on the plugin. But, because of all the relocating and stuff that was happening in my personal life I never got to finish the plugin and it is still left in a half baked state. I will add a blog showing the basic program that I had written using libdrizzle so that people could use it as a base to build on.
I then moved on to modifying devstack to script so that it uses Drizzle as a backend instead of MySQL. Monty Taylor had already told me that all the Drizzle support is already built in as a part of SQLAlchemy and I wouldn’t have to do much. Hence I started to remove all the MySQL related code and adding its equivalent Drizzle code. Diving further in I had noticed that I would have to modify some of the SQLAlchemy library code and some of the code in Nova which I did and got working OpenStack with Drizzle. I will add another blog post covering how I had achieved the backend support as well.
All in all, I had fun working on this project this year and the amount of satisfaction that I got on seeing OpenStack run with Drizzle in the backend is priceless. Ultimately I too have contributed to OpenStack in one form. Now, Drizzle is truely “on the cloud”.
The GA of Drizzle is available for public use. You can see our blog post for the new improvements available with this release. I’ve been with Drizzle for two years now and it is good to see Drizzle mature. This release has given more importance to the users as we’ve done a lot of work on improving documentation and fixing a lot of bugs. We’ve also moved forward in the quest of bringing true multi tenancy. The release is right on time for Percona Live MySQL Conference which is scheduled for next week. This release is even more special to me as I have the privilege of being Drizzle’s Release Manager and had the opportunity to announce to the world the GA of Drizzle 7.1. As always I’m proud to be a Drizzle dev
Great news for all Google Summer of Code aspirants. Drizzle has been accepted as a mentoring organization for the 4th time. Students are welcome to look at our wiki page link and find possible projects and mentors. We hangout at #drizzle on IRC Freenode. Feel free to drop by and post your queries. We have devs from across the globe and so you may get your queries solved at the earliest. If you cant find us on the IRC channel then just shoot out a mail to our mailing list Drizzle-Discuss. We have good documentation on how to get started with code contribution. We would love to see you submit patches for low hanging fruit when you try to get a fix on your project proposals. We hope to have good talent at Drizzle this year. Put on those thinking hats and get those ready. Happy hacking fellow students!!!
Its been a while since I ve blogged but I couldn’t think of a better time to resume blogging than when Drizzle was officially became associated to Software in the Public Interest. I ve been a part of Drizzle for almost a year and a half now and my passion for Drizzle seems to grow every day. It is always good to see changes that happen for good and this is one of them I guess. Now that Drizzle is a part of SPI, it has a legal entity behind it which is always good. How can you benefit from this you may ask. If you are a US tax payer, then any donation that you make will be tax deductible and all your valuable contributions will be used towards the betterment of Drizzle. The easiest way to donate is using a credit card at Click & Pledge. The SPI website lists some alternative methods such as using a cheque. So, please do make your valuable contributions towards Drizzle. As always I feel proud to be a part of the Drizzle family and will continue to strive for the betterment of Drizzle.
I ‘ve been doing some reading on Stored Procedures and how they are being defined and executed. These are some of the points which I think should be covered in our Stored Procedure Interface and some of my suggestions. I’m open to suggestions and criticism. According to what we had discussed in the channel we need make the stored procedure interface pluggable. So, a part of the interface will reside within drizzled and the client part of the interface will reside within the plugin itself.
I personally feel we could work on this interface on a series of 5 to 6 iterations.
1) Write grammar for our stored procedures, a lexical analyser and some parser code using flex and bison. I think we could abide to the SQL standards as much as possible from the earlier stages so that we don’t need to refactor much later on. After we write the grammar we need to test thoroughly!!! The earlier we find bugs the better.
2) Update sql_lex and sql_yacc so that the new keywords STORED and PROCEDURE are understood by our SQL grammar. Update the client code so
that we are able to use the STORED and PROCEDURE keywords. Update bison code to CREATE and DROP Stored Procedures. Use EXECUTE_SYM to execute the stored procedures.
3) We need to store our stored procedures on tables so we will have to write protobuffers for the new fragment of code that is going to enable us to store the stored procedures on the tables.
Now, after the third pass we could merge the code into trunk and _technically_ we should be able to run stored procedures that have only SQL statements. Once we get this working we should be able add the rest of the features with patches.
4) Determine a convention for denoting variables. SQL Server uses @ prefixed to names to denote that the given name is a variable. Enable stored procedures to accept input parameters. We will be needing to re write protobuffers because we need to use these variables in our tables and give special meaning to them in the future.( i.e if they are IN, OUT or INOUT). The interface will not support IN, OUT and INOUT in this pass though.
5) Add support for IN, OUT and INOUT. We need to think of a good way to prevent modification of IN variables. I do not know how to make a table
entry readonly. We also need to be able to return values in the case of OUT and INOUT variables. We could have a column that denotes if a variable is IN OUT or INOUT and based on the entry give write permissions on that variable. Just a suggestion.
6) Add SET to the stored procedures grammar. This will enable us to use local variables. The protobuffers need to be re written so that the local variables can be stored in out tables.
I need to do alot of reading on google protobuffers and brush up on flex and bison. The first three iterations are hardest according to me. I hope I made some sense in these notes.
Please do comment on any mistakes that I ‘ve made so that I could work on them. Better ways on approaching this problem are also welcome.