We have an ongoing Drizzle milestone called low-hanging-fruit. The idea is that when there’s something that could be done, but we don’t quite have the time to do it immediately, we’ll add a low-hanging-fruit blueprint so that people looking to get a start on the codebase and contributing code to Drizzle have a place to go to find things to do.
Some of my personal favourites are:
Also relatively low hanging fruit can be writing some plugins. Some simple plugin types include:
- Authentication
Got somewhere that you could authenticate against for connecting to a DB? Write a plugin for it! Current auth plugins are auth_http and auth_pam.- Perhaps you want to authenticate against a central DB? checking in memcached first?
- Perhaps a htaccess style method
- Functions
Apply some function to a column. These are pretty simple to write (see md5, compress examples). Perhaps interfaces to encryption/decryption? a hashing function?- ROT13
- 3DES
- AES
Bonus points if you get any of these to use the T2000 crypto accellerator stuff - ID3 tag decoding
- file type detection (well.. BLOB)
So there’s a fair bit you can do to get started. Best of all, you can chat with the Drizzle developers next week at the MySQL Conference and Expo and Drizzle Developer Day.
Hi!
“Convert functions to UDF plugins”
indeed – I always felt that this would be a good idea for MySQL except that:
– the interface does not convey information to the UDF about the SQL datatype of the argument. Only the item type is passed, which makes all kinds of things inconvenient or even impossible
– no characterset and collation information is passed. For drizzle the character set issue would be gone, but you’d still have the collation to deal with
– argument checking and input validation are very much a case or reinventing the wheel over and over, simple checks for data types and argument nullability should IMO be done by the server in case the UDF declares the type and nullability of its arguments
– UDFs can only have one return type and overloading is not possible. If there would be overloading, expressions would have to do a lot less unnecessary conversions to string/blob type because of functions returning the most generic type. Example: IF(a,b,c). To me, if a and b are integer types, the return type should be integer too, if a and b are date type, the return type should be date too, etc.
What do you think? Can drizzle UDFs in their current state really replace built-in functions? For example, how would you implement LOWER() as a UDF? Problem I can’t seem to solve is how to figure out whether the argument is character data or binary. Same goes for INSTR and a few others.
(just asking your opininion – I completely support the idea)
They are nearly exactly the same as built in functions. the old UDF interface is gone.
A drizzle UDF is simply a loadable inbuilt function.
same interface (Item_func classes).
Thanks Stewart! wow – cool ;)
If you want to go over any of it while at the UC, grab me. It would be awesome to get a bunch of useful UDFs ported over and in tree.
Checking memcache first before hitting a central datastore to check authentication credentials is totally pointless. Since memcache it self has no authentication.