Pythian Group

This is the 150th edition of Log Buffer, the weekly review of database blogs. Someone accidentally left Dave Edwards’ cage unlocked, and he escaped, thus leaving me with the pleasurable duty of compiling the 150th weekly Log Buffer.

Many people other than Dave are finding release this week. Read the rest of this entry . . .

The “Sesame Street” Version of DBD::Oracle (1.23) has been released.

You can find it at CPAN DBD::Oracle.

DBD::Oracle is the Perl module that works with the DBI module to provide access to Oracle databases. It is maintained by me, John Scoles, under the auspices of The Pythian Group as open source/free software.

This release is largely a maintenance release that fixes a number of bugs.

New stuff includes the ability to fetch Oracle embedded types directly into an oracle object; a big thank you goes out to Tomas Pokorny for that patch.

Also, UTF8 support has been expanded and cleaned up for BLOBs and execute_array and thanks go out to Milo van der Leij, David Mansfield for most of the work on this.

Also a big thanks Alex Buttery, Jim McCullars, Charles Jardine, Eric Simon, and Chris Underhill, who helped out with some clean up of the code, READMEs, and the POD.

I have also now added two private statement functions ora_stmt_type_name and ora_stmt_type which will get the OCI type name and type for the currently prepared statement.

The complete change list

Read the rest of this entry . . .

By now many folks know that MySQL documentation is not changing its license. This is an issue with many sides, but before I go through them, I want to address a comment made by Masood Mortazavi:

People who are interested in forking the server — and potentially interested in creating what is in effect separate communities of their own — should probably develop their own docs for their own forks.

(There is a cost involved here, I know. However, it should be a cost worth paying if developers of forks really believe in their work. MySQL AB certainly paid that cost in developing the docs while it had already made the code itself freely available under GPL. So, the playing ground among all forks, etc., and including MySQL itself, is actually quite level.)

MySQL AB paid the cost in developing the *software* as well. Why is it that the cost of writing documentation from scratch is acceptable, but the cost of writing the *software* from scratch isn’t?

I totally understand the concern that if people have the same rights to fork the documentation as they do to fork the code, confusion may arise. Many do not agree that the risk is high enough to warrant keeping the documentation “closed”. However, even if that is the case, Section 2 of GPLv2 states:
Read the rest of this entry . . .

In a nutshell: What’s New in MySQL 5.1.

Release notes: Changes in release 5.1.x (Production).

And yes, very early on (at about two minutes in), I talk about my take on Monty’s controversial post at Oops, we did it again.

To play the video directly, go to http://www.youtube.com/watch?v=Hs4S7vONGMQ. Or watch it embedded inline here:

Read the rest of this entry . . .

The MySQL 5.1 GA Release will be on or about Dec. 6th, 2008.

How do I know?
Read the rest of this entry . . .

In two words: online operations. In a paragraph: Forget partitioning, row-based replication and events. The big reasons most people are going to salivate over 5.1, and probably start plans to upgrade now, are the online operations:

• online ALTER TABLE for column rename, column default value change, and adding values to the end of an ENUM/SET
• Online, table-based logging. No more need to restart your server to enable or change the general or slow query logs. You can have the standard file-based output or choose a table format…which you can query.

Read the rest of this entry . . .

The MySQL Community version is different in theory from the Enterprise version in relation to the following points:

0) It’s free
1) It has community patches
2) It is released less often
3) It is tested less strictly

In reality, the first two differences are not applicable — the binaries and source code for Enterprise can be freely and legally downloaded at http://mirror.provenscaling.com/mysql/enterprise/. The process for adding community patches to the MySQL source code has not been changed sufficiently to be able to actually add community patches and encourage more community development.

I understand that MySQL (and now Sun) needs to make money. I also understand that development takes a lot of effort, and seeing an ROI is important. The Community/Enterprise split was designed to have tradeoffs on both sides. However, currently there is no benefit to running the Community version.

While I would love to magically make community contributions easy to put into a Community version of MySQL, logistically that’s not possible right now. I do have a solution that is possible right now, that takes very few additional resources, and is something I think will be acceptable to the MySQL community and to Sun — assuming the MySQL executives can admit that the Community version has not been working out.

I propose to make the Community release an older version of an Enterprise release. In this way, Enterprise users still get value in having bugs fixed and features added first, and Community users can choose to upgrade if they want the latest features. There is very little overhead in having Community releases, with no overhead in having to manage two trees/branches/whatever from both a code and build standpoint. Maintaining the promise of immediate security releases, 4 code releases per year and 2 binary releases per year becomes trivial.

The question is, of course, how far back the Community version should go. And should there be a delay (ie, release the January Enterprise version as the June Community version) or not?

I recommend that security releases be immediate (as they currently are) and for all other releases there should be a delay of at least 6 months, perhaps 1 year. Certainly that’s enough of an incentive to get customers to upgrade without having folks feel like the Community ersion is crippleware.

What do folks think of this as a solution to the Enterprise/Community split dilemma?

In http://www.mysqlperformanceblog.com/2008/07/01/should-we-proclaim-mysql-community-edition-dead/, Peter Zaitsev wonders if MySQL’s community edition is dead.

The title of Peter’s inquiry is somewhat misleading, as the database itself works fine. He clarifies a bit with, “there suppose to be 2 yearly binary releases (which are overdue) and 4 predictable yearly source releases, which we have not seen either.” I thought it was clear that “2 per year” doesn’t mean “one every six months”. It’s been eight months, sure. And I don’t actually believe that MySQL is going to have one source release per month until November, to make up for the lack of source releases. However, it’s certainly possible, if not probable.

The fact remains, however, that if you’re just looking for stable, recent, binary MySQL Community release, you might not find it. MySQL offers two out of three — stable and binary Community releases. Not recent, but I think it’s okay to charge for the most up-to-date version. In my experience only about half of the production environments out there have switched to 5.0, and many are running 4.1 and 4.0 still.

At the low end, a license costs just under USD$600. The requirement to buy a license to get the most recent version is a mere inconvenience, not a business-stopper. It’s not like MySQL is forcing everyone to run on version 3.23 unless they pay $10,000 per license. Charging a modest amount for the most up-to-date version is not a bad thing.

It would be nice to have been aware of that ahead of time, but MySQL as a company has not been so great at organizing and having all its ducks in a row. In fact this is where I hope Sun can really help MySQL out, as it has a reputation (a deserved one, in my experience) of being more highly organized.

Have you heard of Hanlon’s razor? “Never attribute to malice that which can be adequately explained by stupidity.”

Read the rest of this entry . . .