I have always considered MySQL as the best model for open source companies. Their approach to the market, the execution of different business models, their relation with the community or the way their work internally as a virtual organization have shown an innovative and successful example of how an IT company in the 21st century can be managed.

The agreement with Sun, announced last January, was the crowning point of all the efforts put in the company since the beginning, proving the success of their innovative model. Since then I have been trying to put some order in my ideas about their model and summarize them in a few blocks that could serve as a quick guide to emulate their success. I discussed my ideas with Henrik Ingo, a friend of mine …

So, remember last month when there was all that furor over the apparent move by MySQL to start making some bits and pieces of the hugely popular open source database over into close source? (Here, Clarifying the MySQL "Closed-Sourcing" brouhaha, for example.)

Well, er, it turns out that the correct answer is: "Never mind."

Per Kaj Arno, MySQL VP Community, MySQL Server is Open Source, even Backup extensions.

You can get the Slashdot crowd's viewpoint here, MySQL Reverses Decision On Closed Source.

Much as I like to rationalize and "support" open source vendor policies, no matter how ill-conceived, …

Recently I ran into major problems using GNU diff. It would crash with "diff: memory exhausted" after only a few minutes trying to process the differences between a couple 4.5GB files. Even a beefy box with 9GB of RAM would run out of it in minutes.

There is a different solution, however, that is not dependent on file sizes. Enter rdiff – rsync's backbone. You can read about it here: http://en.wikipedia.org/wiki/Rsync (search for rdiff).

The upsides of rdiff are:

• with the same 4.5GB files, rdiff only ate about 66MB of RAM and scaled very well. It never crashed to date.
• it is also MUCH faster than diff.
• rdiff itself combines both diff and patch capabilities, so you can create deltas and apply them using the same program

The downsides of rdiff are:

…

One of my hobbies that has taken a good bit of time lately has been to revamp my photo album. I originally wrote it a few years ago and, while it has served its purpose well, it lacks some features that I would like to see and represents less than ideal design decisions. This time around I have started from the ground up and, as a result, have the opportunity to apply some of the things I have learned n the past two years. For instance, this time around, all my main tables will be using InnoDB (or another transactional engine depending on when I finish the dern thing :) completely with foreign keys and, of course, making use of transactions where possible.

Recently while working on my little project, I discovered the value of TRADITIONAL. I am referring, of course, to to the SQL mode setting in MySQL that makes it behave more like, well, a "traditional" database. I tend to think of that as both somewhat unfair and vague. It might be …

I honestly do not know why somebody would want to export each record from a table in to its’ own files in a csv format. I am sure people have their own reasons. But since I got request from couple people, I figure I would post a solution here. Same script can be used to dump the whole table in to one csv file as well, with little tweaking. I will start with creating database with a table. I then insert three rows with test data into the table just to show three separate files creation.

mysql> CREATE DATABASE testdump;
mysql> USE testdump
mysql> CREATE TABLE `testtable` (
`id` TINYINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`testfield` VARCHAR( 15 ) NOT NULL ,
`testfield2` VARCHAR( 15 ) NOT NULL
) ENGINE = innodb COMMENT = 'test table for dumping each row to file';
mysql> INSERT INTO `testtable` values ('','test1','test2'),('','test3','test4'),('','test5','test6'); …

One of my hobbies that has taken a good bit of time lately has been to revamp my photo album. I originally wrote it a few years ago and, while it has served its purpose well, it lacks some features that I would like to see and represents less than ideal design decisions. This time around I have started from the ground up and, as a result, have the opportunity to apply some of the things I have learned n the past two years. For instance, this time around, all my main tables will be using InnoDB (or another transactional engine depending on when I finish the dern thing :) completely with foreign keys and, of course, making use of transactions where possible.

Recently while working on my little project, I discovered the value of TRADITIONAL. I am referring, of course, to to the SQL mode setting in MySQL that makes it behave more like, well, a "traditional" database. I tend to think of that as both somewhat unfair and vague. It might be …

I have updated the Forge page for the External Language Stored Procedures, adding a PDF for the slides used in the presentation and a link to a video of the presentation for those people who missed it. It was quite unfortunate that at the Conference, there were two presentations occurring at the same time which discussed the topic of UDF/Stored Procedures so I am sure that there are people who

Previously.
As usual, hit up the homepage for the latest and greatest downloads. Or simply 'git pull' and use the tag release-6 if you're cool enough.

I'd like to use this post to explain in a more general fashion about what DPM is and why it's different from the rest of the proxies.

First, milestones since R5:
- BSD licensed. You are now free to roam about the cabin.
- Several C level bugs fixed.
- Many improvements to the lua library dpml.lua
- All of the demos were rewritten using dpml.lua, and are now far easier to use.

Now, what is DPM?
- It's a proxy for MySQL. It is event driven, embeds lua, and is written in C. It allows you to write plugins in lua, and …

Previously.
As usual, hit up the homepage for the latest and greatest downloads. Or simply 'git pull' and use the tag release-6 if you're cool enough.

I'd like to use this post to explain in a more general fashion about what DPM is and why it's different from the rest of the proxies.

First, milestones since R5:
- BSD licensed. You are now free to roam about the cabin.
- Several C level bugs fixed.
- Many improvements to the lua library dpml.lua
- All of the demos were rewritten using dpml.lua, and are now far easier to use.

Now, what is DPM?
- It's a proxy for MySQL. It is event driven, embeds lua, and is written in C. It allows you to write plugins in lua, and …