Ulf was pushing me today to file a MySQL bug, which actually doesn't exist anymore, but his programs crash with 5.1.31, where it seems still exists. For a long time we were thinking about the ultimate testing matrix which includes as many as possible MySQL Server instances to check differences in result of the connectors.
I've heard that Paul DuBois have all existing MySQL versions running on a secret box.
Throughout the years MySQL has seen many version suffixes
The MySQL Protocol is a very old thing. Current version is 10, however I have never seen a server which uses anything but version 10. And new features are added without bumping the number. The changes are usually backwards compatible and sometimes you break stuff to be backward compatible.
You know that character set, and most notably Unicode, support was introduced in 4.1 . Other things got added to 4.1 but let's stay with the charsets.
mysqlnd patched for compressed protocol passes almost all tests, but all of the most relevant and those who test with big result sets. I have a few failures due to "Packet out of order" which is due to the crippled packet numbering when com...pressed is turned on-the outter layer has different counter than the inner, compressed one, and it is unknown how the server resets them (for example in the COM_CHANGE_USER tests).
MySQL's compressed protocol is not so widely used, but there are still users that use it. Thus, the need to implement it in mysqlnd.
Unfortunately the compressed protocol is full of landmines, a lot of them, exploding one by one.
No! There is no error in the topic. You can see yourself:
The MySQL UC 2009 is over and I got bored in the evening before I had to leave Santa Clara and decided to play again with query caching in mysqlnd. I have always said that mysqlnd is ready for it, the infrastructure is there and that we need just few changes to make it work. Well, I decided to bite the bullet and do it. Spent about 4h in the evening and on the next day 2h while waiting on the San Jose (SJC) airport and continued on the flight to Denver, where I am having vacation. On the plane I was almost ready and today I made the final changes to the preliminary patch, that seems to work :)
I did a small benchmark, a microbenchmark.
In a few hours I will give my talk on mysqlnd. Well, the talk is not mine but we wrote it together with Ulf Wendel, of the MySQL Connectors Team fame. Although we haven't added much functionality to mysqlnd in the recent months mysqlnd is still pretty advanced and started to mature. I will talk about why mysqlnd is unique, why is it cool, why is it fast, and why you should use it!
Yesterday I gave my talk, in front of not that many people, about Connector/C++ at the MySQL UC 2009. Not too many questions came from the public, but this is a new product which very specific target group. You know, almost nobody writes Web applications in C++. And Java is the server language for the Enterprise. So I should have expected not many people in the room.
If you have missed the talk, don't worry. In May there will be a webinar which you can attend and if you miss it, you can just watch it at later time. The webinars are recorded and offered freely.
Yesterday the Connector/C++ got the GA stamp and we officially support it. Although we are going to make changes, mostly backward compatible, because this GA, 1.0.5, added the basic functionality the people need to use MySQL with C++ without using the weird libmysql API, which makes your life hard, if you don't use boost and start to get exceptions - you are gonna leak big time.
I will give a talk about Connector/C++ (and mysqlnd in another slot) next week at the MySQL UC 2009. We had to fit the presentation in about 20 slides to be able to fit in the small timeframe of 45 mins. So far I have given only presentations of about 90 minutes, incl. the shoot me with your questions part. I rehearsed today, both talks. Everything seems fine and I will fit. So, if you are an ISV that uses MySQL and use C++ come to see my presentation, there is something to learn. If you are open source developer, who uses C++, come to the room and allow me to introduce MySQL Connector/C++ to you. I am sure you will never get back to libmysql and MySQL Connector/C 
Hurry up. Click here to read Giri Mandalika's article on MySQL Connection C++. He is using 1.0.4-beta for his tests and shows how simple it is to use the connector. It is all about developing in C++ for MySQL that became easier!
Since some time I am a dual-head user. I recently bought a 19" Ilyama 1680x1050 (cool resolution for 19") and it served me well. It is much more smaller than the 24" Dell UltraSharp I have. The differences in the resolution is not that big. The Dell is 1920x1200. Yesterday I saw that Ilyama have a Prolite series monitor, the same as the 19", 22" which has 1920x1200. I have followed in the recent times the 23" line of Samsung - the 2343 NW. Which is about 160 Euro and offers not that standard resolution (2048 x 1152 / 16:9). The resolution is strange, right? But gives the possibility to have 2 browsers at 1024 pixel width next to each other. In the last years the monitors got bigger and cheaper, more real estate. And they got wider. Probably driven by the multimedia market, although widescreen is good also for those who use IDEs.
After I yesterday checked the size of wchar_t on range number of platforms I decided to extend this to many more types. Again the same systems were used, a few more were added (MacOSX 10.5 x86 and x86_64 are the ones most used). The information is in pretty raw state bug my blog software is not able to present big tables correctly, thus I am going the raw way.
What is most interesting?
I suppose you have already heard from Ulf what MySQL Connector/C++ is. Today Ulf was looking at the test cases and out of the blue asked whether we support named pipes. Well, it wasn't tested but one can pass OPT_NAMED_PIPE to the connect method of the driver (or the MySQL_Connection constructor).
wchar_t was introduced long ago as wider version of char that should be enough while doing programs that grok Unicode. Unfortunately, as with all other C types the standard doesn't define the length. Thus some platforms have 2 byte others 4 byte wchar_t. I decided to check what are the sizes using an internal build tool at SUN/MySQL. And here are the results.
The topic sounds scary, right? Don't be afraid, we just wanted to mention that we introduced a change in the interface, after we released the beta yesterday. Previous examples which use ConnectionMetaData, ResultSetMetaData and ParameterMetaData won't work anymore. They used to use std::auto_ptr to keep the code from leaking.
MySQL 5.1 was released as GA not long ago (current version 5.1.32). I work at SUN/MySQL as a connector developer. Currently working on Connector/C++, previously I used to develop mysqlnd of the PHP fame, currently I maintain it. Every single day I work with the MySQL Server and like everything in this world, it's imperfect. You know perpetuum mobile doesn't exist.
We are trying to compile Connector/C++ in the OpenOffice.Org environment, however dmake, the OO.Org build too (Ubuntu/Debian has it) can't work currently with CMake. CMake is the meta-make system we use for Connector/C++ to easy the portability. I had a blog entry which platforms are supported, a vast number. Without CMake this wouldn't have been that easy.
We are in the last stages of preparing the next release, which will be the first beta. I expect that Ulf will blog thoroughly on it.
Very strange results when executing CMake on within MySQL Connector/C++ on i5OS.
First MySQL post