Eric Bergen

I was trying to come up something funny|cute that used new features in 5.0 and settled on a quick little bit with a coffee pot and mug:

create table pot (coffee int unsigned);
create table mug (coffee int unsigned);

delimiter |

create trigger pour_cup after delete on pot
        for each row begin
                insert into mug (coffee) values (1);
        end
|

delimiter ;

Try it out:

mysql> insert into pot values (1), (1), (1), (1);
Query OK, 4 rows affected (0.00 sec)
Records: 4  Duplicates: 0  Warnings: 0

mysql> select * from pot;
+--------+
| coffee |
+--------+
|      1 |
|      1 |
|      1 |
|      1 |
+--------+
4 rows in set (0.00 sec)

mysql> select * from mug;
Empty set (0.00 sec)

mysql> delete from pot limit 1;
Query OK, 1 row affected (0.00 sec)

mysql> select * from mug;
+--------+
| coffee |
+--------+
|      1 |
+--------+
1 row in set (0.00 sec)

Whenever someone deletes coffee from the pot it fills the cup. Get it? I’m going to bed.

There has been a lot of buzz going around lately about Oracle’s recent aquizition of Innobase Oy the company that produces the innodb storage engine for MySQL. Most of this buzz is centered around MySQL being doomed or at least being set back to the years before it was considered enterprise quality. None of this is true.

First a bit of background. MySQL is unique (as far as I know) in the relational database industry with the concept of storage engines. This gives users the choice of many different features for storage making MySQL the most flexible database in the world (opinion of course, rebut if you dare ) innodb is only one of several storage engines available to users. Contrary to popular belief it is not the only storage engine that supports transactions. MySQL also supports the bdb storage engine created by Sleepycat software. Innodb is recognized as the better of the two but the choice is still there.

Now back the point. The big question is, “What will MySQL do now?” This is the wrong question. The ball isn’t in MySQL AB’s court anymore. It’s securely in the hands or Oracle. They have a few choices. Since innodb is open source they could have been developing a product to compete against MySQL for some time. They could allow direct importing of innodb data which would be an easier migration path to full blown Oracle. While this is a good point it’s not complete. When migrating databases the hardest part is migrating the application code, not the data. This means that Oracle won’t steal any existing MySQL customers by putting out a competing product, but they might gain some new ones. Since these customers are new anyway Oracle doesn’t gain much benefit in buying innodb vs developing their own lighter weight storage technology. Except of course saving the cost of doing the actual development.

The two big questions now are, “What is Oracle going to do with innodb hot backup?” and, “What is going to happen with the current contact for commercial licenses with MySQL AB?” This is where Oracle loses some of their traction. MySQL can do a few things. They can try to renagotiate the contract with Oracle as soon as possible or they can work under the assumption that Innodb will no long be available after that contract expires. Choice B is the safest. The major sticking point with Oracle buying Innobase is not the storage engine. It’s innodb hot backup. Right now Oracle could choose to make innodb backup licenses very expensive. This again would be a small blow. They can’t make innodb hot backup licenses more expensive that an average MySQL slave server. People would just buy more hardware and run a mysql slave which they could shutdown to do a backup.

They could also have bought innodb as a direct blow against MySQL. This again is a good theory but it doesn’t hold much weight. This could actually end up helping MySQL more than hurting them. Had this buyout occured a few years ago MySQL might be in serious trouble. It didn’t. It happened now. MySQL AB has ~80 developers. Innobase has essentially one good developer. Losing 1/80th of an engineering team usually isn’t enough to collapse a company or a product. The same is true for MySQL. MySQL can rebuild part of the functionality of innodb into the storage engine level gifting that to all the underlying storage engines. I’m talking about hot backup for all storage engines, posting advanced reads and other things that are currently only part of innodb. Hot backup on the storage engine layer would make innodb hot backup worthless. MyISAM is already blazing fast. Imagine how much faster it will be with advanced reads

When traveling to a foreign country always consume the dairy products served. These items contain the bacteria necessary for your body to properly handle the bacteria local to that country.

For years I and several others have been asking for the MySQL online manual to be versioned. It’s very annoying to users to see something in the manual and not have it work in their instance of MySQL. I’ve mentioned this a few times and now it looks like it’s come true. The manual page now has version numbers!

Good job guys. Thanks!

This is one of my favorite images to send to people that say LOL or ROFL in chat rooms.

Love it.

Most people who have had someone look over their shoulder while typing at a prompt have been hit with the question, “How did you do that?” Followed by a quick example of whatever nifty command they just executed. Of all the little bash tricks I know the one that I have explained to more people than any other is brace expansion. It’s a must have in the trick box of any bash user. Consider the following:
firewire@cartman:~> cp /etc/my.cnf /etc/my.cnf.bak
firewire@cartman:~> vim my.cnf
*edit edit edit*

Sometimes, before I knew about brace expanstion I would type my.cfn.bak then get slowed down by having to look for the right file. Other times when copying the bak file over the original I would mis-type my.cnf.

Introducing brace expansion. Brace expansion allows you to create multiple modified command line arguments out of a single argument.
firewire@cartman:~> echo foo{bar,baz}
foo foobar foobaz

How does this help our backup copy? Not all arguments int he brace set have to contain a string.
firewire@cartman:~> echo my.cnf{,.bak}
my.cnf my.cnf.bak

Replace echo with cp and you have just made a fool proof backup file. To restore just flip the arguments.
firewire@cartman:~> echo my.cnf{.bak,}
my.cnf.bak my.cnf

Brace expansion is a minor gain in this situation. Where it really prevails is with long path names such as
firewire@cartman:~> echo /usr/local/apache/conf/httpd.conf{,.bak}
/usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf.bak

[ Update 2006-2-1: Bash 3.0 introduces sequences in braces:

echo {1..3}{foo,bar}
1foo 1bar 2foo 2bar 3foo 3bar

]

All week there have been posters around the Yahoo campus about a naked celebrity photoshoot. Jeremy captured the action.

[update: 10/7/2005 - photoshoot is one word. Jeremy sent me a link to the poster ]