The MySQL Connector/C++ Connector project has successfully reached its first major milestone by releasing its Alpha version.

The Connector provides a C++ implementation modeled after JDBC. This allows developers who have worked with JDBC to quickly take advantage of this Connector minimizing the learning curve.

The current release provides support for many of the methods found in the following JDBC interfaces:

• java.sql.Connection
• java.sql.DatabaseMetaData
• java.sql.Driver
• java.sql.PreparedStatement
• java.sql.ResultSet
• java.sql.ResultsetMetaData
• java.sql.Savepoint
• java.sql.Statement

Examples of using MySQL Connector/C++

Here is an example which connects to a MySQL Server, creates a table and then inserts a row into the table

      sql::mysql::MySQL_Driver *driver; …

Devart company decided to publish roadmap of dbForge for MySQL line to help you understand the future product development. This roadmad encompasses two products: dbForge Studio for MySQL and dbForge Fusion for MySQL.

Below is the chronologically ordered list of features we plan to implement in the near future. Note that the list is not frozen and some items can be subject to change.

Database Diagram
Database diagram is a new type of document that represents visual layout of the database. It will implement online (directly to database) database object creation and modification. Here is a screenshot of this feature (currently under development).

Sample Database Diagram

Data Import
This feature will allow users to import data to database from most used …

We've recently done benchmarks comparing different MySQL versions in terms of their CPU efficiently in TPC-C like Workload. We did it couple of weeks ago so MySQL 5.0.67, MySQL 5.1.29 and Innodb Plugin 1.0.1 were used which are not very recent, though we do not think results will differ a lot with today versions.

Results are as follows:

The system was 2* Quad Core Xeon E5310, CentOS 5, Data stored on ramfs. We controlled number of cores used with /sys/devices/system/cpu/cpuX/online Maximum performance for each number of cores was taken though it was reached with number of sessions matching number of cores. Just 1 "Data warehourse" was used to keep data small.

As you can see there is some gain for MySQL from read-write lock split patch (found in Percona Builds) though it is not very significant for this workload. To isolate effect of this patch …

At the recent OpenSQL Camp in Charlottesville, VA, Tokutek offered a challenge to the MySQL community - who can insert a billion rows into MySQL the fastest?  We will post the results on our website and the winner gets a $100 Starbucks card, along with valuable bragging rights.

Tokutek’s technical founders (Michael A. Bender, Martin Farach-Colton, and I), in our academic roles (at Stony Brook, Rutgers, and MIT, respectively) have been investigating how to maintain indexes for large databases.  Part of the challenge for this kind of research is to figure out what to measure.

Some other benchmarks, such as TPC-H and SSB, measure bulk load time rather than insertions.  We are interested in the case where you must insert a small number of rows at a time at a high rate, and keep the index up-to-date.  Indexed insertions are interesting in situations with high incoming data rates and a desire to concurrently query on …

Title pretty much says it all. Today I uploaded the latest tarball in of the NDB/Bindings project to Launchpad.

NDB/Bindings is a project which provides Java, Python, Perl, Ruby, C# and Lua bindings to the NDB API and the MGM API for talking to MySQL Cluster. 

As the version number indicates, it's not quite ready for full production use yet, although for Java and Python it is mostly functionally complete (unless something has been missed that I'm unawa - also, for those of you hardcore NDB API hackers out there, no we are not providing direct NdbRecord support at this time - but we probably won't for the 1.0 release anyway so there) There are a few projects who have already been working with the code, one of which found a performance bug that I've been considering in the back of my head.

Title pretty much says it all. Today I uploaded the latest tarball in of the NDB/Bindings project to Launchpad.

NDB/Bindings is a project which provides Java, Python, Perl, Ruby, C# and Lua bindings to the NDB API and the MGM API for talking to MySQL Cluster. 

As the version number indicates, it's not quite ready for full production use yet, although for Java and Python it is mostly functionally complete (unless something has been missed that I'm unawa - also, for those of you hardcore NDB API hackers out there, no we are not providing direct NdbRecord support at this time - but we probably won't for the 1.0 release anyway so there) There are a few projects who have already been working with the code, one of which found a performance bug that I've been considering in the back of my head.

As Brian mentioned earlier, I merged in version 1.0.2 of the InnoDB Plugin last night. Took about 2 hours - most of which was compiling and testing on a couple of different machines to make sure I hadn't b0rked anything.

Getting bzr to help me do all of this was actualy quite easy, once I corrected one mistake about how I had merged the code into the tree in the first place. (oops) 

In a move that's sure to shock my former boss, I wrote up a quick wiki page on the process, just in case anyone is interested.

As Brian mentioned earlier, I merged in version 1.0.2 of the InnoDB Plugin last night. Took about 2 hours - most of which was compiling and testing on a couple of different machines to make sure I hadn't b0rked anything.

Getting bzr to help me do all of this was actualy quite easy, once I corrected one mistake about how I had merged the code into the tree in the first place. (oops) 

In a move that's sure to shock my former boss, I wrote up a quick wiki page on the process, just in case anyone is interested.

In MySQL 5.1 related new, Innodb has announced the release of their Innodb Plugin Engine for MySQL.

So why do I blog about it?

Because the Innodb plugin engine is the default engine Drizzle :)

Monty Taylor finished up the work last night to import it into Drizzle, and I just finished my review of the engine and have pushed it into our main branch.

Some of the advantages:

Fast index creation: add or drop indexes without copying the data
Data compression: shrink tables, to significantly reduce storage and i/o
New row format: fully off-page storage of long BLOB, TEXT, and VARCHAR columns
File format management: protects upward and downward compatibility
INFORMATION_SCHEMA tables: information …

Well… there’s:

• database
• table name

(both of these are quite obvious).

But then you have:

• temporary tables

Well… two types of temporary tables:

• those created in the course of query execution, typically in /tmp/
• those created during ALTER TABLE, typically in the database directory

You may have seen these “#sql-foo.frm” etc files around.

but you can also CREATE TABLE `#sql-foo` (you know, because that’s a good string to use in your app). In fact, you can (and shouldn’t) create a table with the exact same name as the temporary #sql table and use it in your app.

So really the primary key for a table is: string database name, string table name, bool is_tmp. Oh, and the /tmp/ temporary tables just to screw with your braiiiinn.

In drizzle, this is what the storage engine API is …