Blog | Bugs | Build Farm | Events | Feature Requests | IRC | LCOV | Mailing List | Planet Drizzle | Source Code | User Docs | Twitter
The Drizzle project is planning to take part in the Google Summer of Code 2011 program. This program endeavors to fund students to contribute to an open source project over the summer break.
Submission Template
Project Title
Description: a paragraph describing the project
Suggested background/interests: Provide a brief description of what kind of technologies (such as programming language) the student should be have a bit of knowledge in.
Mentors: Mentors for this project
Students: The students the project has been assigned to
Project Ideas
A template is provided below to use for listing project ideas. Feel free to add more project suggestions.
Project Ideas
Template:
Description:
Suggested background/interests:
Mentors:
Students:
Port additional drizzle-automation functionality to dbqp
Description: Currently, dbqp is designed to be a one-stop shop for Drizzle testing. By defining different test execution and management modules, we can have different 'modes' such as dtr, randgen, sysbench, etc. dtr and randgen are currently implemented, but it would be nice if we could do everything drizzle-automation runs directly from the tree (provided the appropriate additional software is installed). This would include sysbench, dbt2, sqlbench, etc.
Suggested background/interests: benchmarking, qa, python, testing
Mentors: Patrick Crews
Students:
API to index buffer
Description: This is a refactoring project. Currently, the interface to storage engines for index operations is being passed a pointer to a buffer in memory where the engine must interact with the raw format directly - there is not a nice and clean API over it. This project would be to create accessor classes that engines can use to read the index buffer. Ideally, the end of the project would allow an alternate implementation of the index buffer and all the engines to just continue working.
Suggested background/interests: API design, refactoring
Mentors: Stewart Smith
Students:
EXPLAIN for DELETE and UPDATE queries
Description: Currently you can only run EXPLAIN on SELECT queries. This project would be to expand that functionality so that DBAs and developers can check the execution plan for UPDATE and DELETE queries (which can execute differently to the similar SELECT query).
Suggested background/interests: Optimiser
Mentors: Stewart Smith
Students:
Online ADD/DROP index for Innobase and HailDB
Description: Both engines support it internally, this project would be linking up the (new, in development) ALTER TABLE protobuf message to an API asking the engines what operations they can perform. If the whole ALTER TABLE statement can be performed online, then get the engine to do it. This should also include the addition of EXPLAIN ALTER TABLE, which will list what operations can and cannot be performed online.
Suggested background/interests: DDL, server kernel
Mentors: Stewart Smith
Students:
Implement rotating blades benchmark
Description: Implement the rotating blades benchmark http://www.flamingspork.com/blog/2010/04/22/the-rotating-blades-database-benchmark/ - it's designed to be more of a Web 2.0 style benchmark that is really evil on a RDBMs.
Suggested background/interests: Benchmarks/performance, C/C++
Mentors: Stewart Smith
Students:
libdrizzle native sharding
Description: one of the original design goals with libdrizzle was to have native sharding support. Initial ideas on this are similar to to hashing algorithm in libmemcached but we would be interested to see how students would expand on this.
Suggested background/interests: Protocols, C
Mentors: Brian Aker (irc nickname: krow), Patrick "CaptTofu" Galbraith, Andrew Hutchings
Students:
IP address data type
Description: A data type is needed which will add at least IPv6 storage to Drizzle (preferably with some way of dealing with IPv4 too). As a bonus INET_NTOA() and INET_ATON() should be reimplemented.
Suggested background/interests: C++
Mentors: Brian Aker (irc nickname: krow), Mark Atwood, Andrew Hutchings
Students:
SET and TUPLE data type
Description: the SET data type was removed from Drizzle but needs reimplementing and extending to include the TUPLE data type as well. More information can be found at https://blueprints.launchpad.net/drizzle/+spec/set-tuple
Suggested background/interests: C++
Mentors: Brian Aker (irc nickname: krow), Andrew Hutchings
Students:
Stored Procedure Interface
Description: Drizzle does not have a stored procedure interface yet. This project involves writing a stored procedure interface which includes writing a grammar for the new stored procedures, writing protobuffers to store the procedures in tables and executing the procedures using EXECUTE().
Good knowledge on Stored Procedures and the internal working of the Drizzle server are required. Drizzle already has the required framework to support stored procedures. The student will be required to understand the underlying code and use it to execute the stored procedures. The grammar of the procedures will play a vital role and it would be good to see the stored procedure grammar obeying the SQL standards. Support for passing parameters to procedures, returning variables and creating local variables are some the features that the interface must support while creating new procedures.
Suggested background/interests: SQL, Stored Procedures, C++, flex, bison, google protobuffers
Mentors: Brian Aker (irc nickname: krow)
Students:
Port Drizzle functionality to newer python-based dbt2
Description: Drizzle currently uses a modified version of dbt2 which is based on the pre-python code. This project would involve making the necessary changes to allow the new python-based dbt2 to execute against Drizzle. It would be ideal if the student would also create a new mode for dbqp which would allow the test-framework to execute dbt2 directly.
Suggested background/interests: python, benchmarking, dbt2, perl
Mentors: Patrick Crews
Students:
Port Logging Plugins over to new Event interface
Description: there is a specific plugin type used for logging queries and events to a debug log. There is a new plugin type that is a more flexible superset that is called on many different kinds of events inside the Drizzle kernel. This project would involve porting the existing logging plugins to using the new event plugin type, and then deleting the now unused logging plugin handling.
Suggested background/interests: C++
Mentors: Mark Atwood
Students:
Contacting the Mentors
The mailing list is the best way to express interest in a project. The mentors listed next to the above project ideas are also available on IRC most days. Their IRC handle is listed next to their name above.
- Mailing List
- Freenode IRC: visit channel #drizzle
Proposal Guidelines
Students are responsible for writing a proposal and submitting it to Google before the application deadline. A strong proposal will include:
- Benefits to the Drizzle Community - a good project will not just be fun to work on, but also generally useful to others.
- Deliverables - It is very important to list quantifiable results here
- Project Schedule - How long will the project take? When can you begin work?
- Bio - Who are you? What makes you the best person to work on this project?
- Contact - How can we contact if we have questions about your project? Can you supply us with an email/IM/phone method for being contacted, in case of emergency?
We would prefer that development discussion occur on our project mailing lists when possible, with special recognition being given to those students who vet their proposal with community developers before submitting their proposal to Google SoC. This is not required, but can have a large impact on the chances of your proposal being accepted, so please don't be shy. In any case, you will be required to keep open lines of communication with your mentor should you be accepted, so if you have circumstances that may affect this, please explain them up front in your proposal.
Acceptance Criteria
Generally we look for a genuine enthusiasm and initiative from student applications. Some specific criteria that we will be using when going through student proposals are:
- has the student discussed the project with a mentor
- has the student put together a draft application and discussed it with a mentor
- when did the student first express interest in the project
- has the student made any contributions to drizzle (in any form, large or small)
- has the student database internals experience (if applying for an internals project)
- how familiar is the student with the drizzle development process - have they made an effort to learn it
- how good is the student's written English
Frequently Asked Questions
Am I eligible?
Please see the Google Eligibility FAQ for all questions about eligibility.
When is the proposal deadline?
According to the Summer of Code FAQ, the deadline for submitting student proposals is April 8th, 2011 (19:00 UTC). Please remember that proposals must submitted to Google themselves, although we are happy to discuss any proposals with you ahead of time.